Comments 183
«Да и не потянуть мне 1С или SAP...»
в первом варианте можно натянуть бизнес процессы на платформу, и если руки откуда надо весьма благополучно, во втором варианте необходимо перестраивать бизнес процессы под эту систему и еще она адски дорога…
по поводу выхода из проблема, волшебных языков вы вряд ли найдете… есть способ подойти к этому чисто как проектировщик БД, условно предположим есть клиент который использует максимум функционала вашего приложения… для него расписать всю структуру таблиц, произвести нормализацию… удалить избыточные данные… принять это за эталон и не трогать.
Судя по тому что вы пишите «Первый такой подсад — долбаные поля в БД сами по себе.» нет какой-то определенной основы в работе всей системы, а это не есть хорошо… вы видите что она разрастается но контролировать ее не можете… не надо добавлять по полю в день…
собирайте объем изменений… и вносите ее в новую версии конфигурации… так вы избавитесь от хаоса.
А вообще проблему вижу исключительно вне продуманности системы… возможно все-таки стоит взглянуть на какое-то готовое продуманное решение(тот же 1с)… правда зависит от направления бизнеса…
в первом варианте можно натянуть бизнес процессы на платформу, и если руки откуда надо весьма благополучно, во втором варианте необходимо перестраивать бизнес процессы под эту систему и еще она адски дорога…
по поводу выхода из проблема, волшебных языков вы вряд ли найдете… есть способ подойти к этому чисто как проектировщик БД, условно предположим есть клиент который использует максимум функционала вашего приложения… для него расписать всю структуру таблиц, произвести нормализацию… удалить избыточные данные… принять это за эталон и не трогать.
Судя по тому что вы пишите «Первый такой подсад — долбаные поля в БД сами по себе.» нет какой-то определенной основы в работе всей системы, а это не есть хорошо… вы видите что она разрастается но контролировать ее не можете… не надо добавлять по полю в день…
собирайте объем изменений… и вносите ее в новую версии конфигурации… так вы избавитесь от хаоса.
А вообще проблему вижу исключительно вне продуманности системы… возможно все-таки стоит взглянуть на какое-то готовое продуманное решение(тот же 1с)… правда зависит от направления бизнеса…
+3
>> перестраивать бизнес процессы
Если так, то сразу в лес их :) Я знаком с SAP (мы их партнер и потенциальный конкурент; правда, в другой ценовой нише)
>> принять это за эталон и не трогать.
>> не надо добавлять по полю в день…
Ну, положим, не в день, а реже. Но все равно наши аналитики рассмеются в лицо, если я скажу, что нужно умерить аппетит и вообще перестать трогать систему.
Как проектировщик БД я лучше не буду подходить — мне хватает того, что я вижу сейчас; система крайне неохотно принимает изменения; аццки неохотно.
И вопрос не столько в хаосе, сколько в технической организации, начинке :) Но все равно спасибо за советы
Если так, то сразу в лес их :) Я знаком с SAP (мы их партнер и потенциальный конкурент; правда, в другой ценовой нише)
>> принять это за эталон и не трогать.
>> не надо добавлять по полю в день…
Ну, положим, не в день, а реже. Но все равно наши аналитики рассмеются в лицо, если я скажу, что нужно умерить аппетит и вообще перестать трогать систему.
Как проектировщик БД я лучше не буду подходить — мне хватает того, что я вижу сейчас; система крайне неохотно принимает изменения; аццки неохотно.
И вопрос не столько в хаосе, сколько в технической организации, начинке :) Но все равно спасибо за советы
0
что делать? что делать? брать книгу Чернышевского «Что делать ?» и искать что делать :)
Переписывать надо это приложение с нуля. Оно не сопровождаемо никак. Это ад в чистом виде. Понимаю, что переписать такое, это решимость надо иметь. Однако вам стОит уговорить руководителя переписать систему. Вы сэкономите очень много денег в будущем на поддержке и сопровождении.
Переписывать надо это приложение с нуля. Оно не сопровождаемо никак. Это ад в чистом виде. Понимаю, что переписать такое, это решимость надо иметь. Однако вам стОит уговорить руководителя переписать систему. Вы сэкономите очень много денег в будущем на поддержке и сопровождении.
-2
Я и переписал на ORM-вариант :) Получилось куда лучше, но все равно проблемы есть.
У меня вопрос стоит по-другому — как не написать монстра еще раз; или это у всех такие проблемы? :)
У меня вопрос стоит по-другому — как не написать монстра еще раз; или это у всех такие проблемы? :)
+3
Ну дак все нормально по-моему. Вы же это приложение написали «монстром» не сразу. И новое сразу монстром тоже не будет. Дилемма то в чем?
При внесении изменений без вмешательства в архитектуру будет щит. Поэтому нужно рефакторить (в том числе и базу данных тоже, насколько я понимаю в этом направлении есть какие-то подвижки, судя по заголовкам книг).
Связь данные, логика, интерфейс это проблема (дублирование действий при добавлении новых функций, те самые «в 5 раз больше работы»). Что можно сделать? Высокоуровневые инструменты (ORM etc.), скаффолдинг который уменьшает количество работы и(!!!) ошибок в разы. Ну и, как вариант, оставить в базе только данные, всю логику убрать в код.
Вряд ли кто-то сможет дать вам подробное решение. Все будет похоже на мой «набор общих рекомендаций», как мне кажется.
При внесении изменений без вмешательства в архитектуру будет щит. Поэтому нужно рефакторить (в том числе и базу данных тоже, насколько я понимаю в этом направлении есть какие-то подвижки, судя по заголовкам книг).
Связь данные, логика, интерфейс это проблема (дублирование действий при добавлении новых функций, те самые «в 5 раз больше работы»). Что можно сделать? Высокоуровневые инструменты (ORM etc.), скаффолдинг который уменьшает количество работы и(!!!) ошибок в разы. Ну и, как вариант, оставить в базе только данные, всю логику убрать в код.
Вряд ли кто-то сможет дать вам подробное решение. Все будет похоже на мой «набор общих рекомендаций», как мне кажется.
0
>>И новое сразу монстром тоже не будет. Дилемма то в чем?
Дилемма вот в чем. Если предположить, что то, что вы написали истинно, то приходится предположить еще и вот что — я нехилый архитектор, бвахаха. В отличие от предыдущих товарисчей по клавиатуре.
А мне что-то стремно так думать. Даже больше — я думаю, что нифига не так, и среднестатистически я такой же. А это означает что однажды в 12 часов система превратится в тыкву, но всем будет пох, и больше всего мне, потому что с улыбкой идиота я буду купаться в баксах и безмятежно пускать слюни. Образно говоря.
А после выйдет, как у Успенского в «Змеином молоке»:
— Это преамбула?
— Это пи%дец!
Также дилемма в том, что супер мега объектный подход тоже имеет свой pitfalls. Не превратится ли в тыкву и он? Интересует мнение общественности
Дилемма вот в чем. Если предположить, что то, что вы написали истинно, то приходится предположить еще и вот что — я нехилый архитектор, бвахаха. В отличие от предыдущих товарисчей по клавиатуре.
А мне что-то стремно так думать. Даже больше — я думаю, что нифига не так, и среднестатистически я такой же. А это означает что однажды в 12 часов система превратится в тыкву, но всем будет пох, и больше всего мне, потому что с улыбкой идиота я буду купаться в баксах и безмятежно пускать слюни. Образно говоря.
А после выйдет, как у Успенского в «Змеином молоке»:
— Это преамбула?
— Это пи%дец!
Также дилемма в том, что супер мега объектный подход тоже имеет свой pitfalls. Не превратится ли в тыкву и он? Интересует мнение общественности
+9
Несколько переписываний — и получится конфетка (а Вы получите тонны experience) :)
0
В смысле, я же изложил проблемы всех подходов; самый лучший, который я вижу, тоже не без греха… Получилось так: «Эти подходы кончились, несите следующие!» :)
0
«Вклад в управленческое эго», так Питер Друкер называл решения, когда руководитель после объективного понимания провала проекта пытается его тянуть, только потому что потрачено уже время и деньги…
нужно находить в себе силы для дейтсвий…
нужно находить в себе силы для дейтсвий…
0
все правильно говоришь — но по бизнесу никто не разрешит
0
В определенный момент переписал похожую систему процентов на 70-80. Доволен необычайно.
Может и вам стоит попробовать?
Вообще, главная проблема всех таких БД — абсолютная неформализуемость российского бизнеса и русских людей (а чую чем-то задним, что не только у нас такая беда). Посему нужно просто искать другой подход к построению таких приложений, классический — выявили условия, написали алгоритм, реализовали в коде — падает на третьей итерации изменения условий, которые пришлось добавлять.
Может и вам стоит попробовать?
Вообще, главная проблема всех таких БД — абсолютная неформализуемость российского бизнеса и русских людей (а чую чем-то задним, что не только у нас такая беда). Посему нужно просто искать другой подход к построению таких приложений, классический — выявили условия, написали алгоритм, реализовали в коде — падает на третьей итерации изменения условий, которые пришлось добавлять.
+1
Супер, я тоже так хочу:)
Контрольный вопрос — на что переписали? Что поменяли? Изюминки? Поделитесь, пожалуйста, в пределах NDA (ну или совести там, кому что ближе) )
Контрольный вопрос — на что переписали? Что поменяли? Изюминки? Поделитесь, пожалуйста, в пределах NDA (ну или совести там, кому что ближе) )
+1
habrahabr.ru/blogs/java/67920/
тут про ошибки и ORM было)))
тут про ошибки и ORM было)))
0
Про ORM — у нас был не ORM в прямом смысле этого слова: просто нет доступного RM, позволяющего хранить метаинформацию в самой БД и мапить данные на данные (датасет на датасет). Ну или есть, но разработчики о нем не знали.
В любом случае, виновные уже были торжественно расстреляны :)
В любом случае, виновные уже были торжественно расстреляны :)
+1
на самом деле очень обидно, когда оказываешься в такой ситуации, просто переписывание всей системы может влететь в копеечку, нужно на само проектирование будет потратить много времени… но на самом деле выхода из проблемы 3:
1.перейти на другую систему;
2.переписать самому систему;
3.сделать рефакторинг существующей системы;
Не думаю, что кто-то сможет вам подсказать 100%-ый выход из положения, но хотя бы направить…
1.перейти на другую систему;
2.переписать самому систему;
3.сделать рефакторинг существующей системы;
Не думаю, что кто-то сможет вам подсказать 100%-ый выход из положения, но хотя бы направить…
0
Все было на ПХП самописном, переписано было на Zend Framework. Самые замечательные изменения были связаны с моделью и видом. Модель стало гораздо легче контролировать как с ORM, так и с SQL стороны. А вид… Разный вид страниц для разных пользователей, и прочие мелкие радости (спасибо отказу от шаблонизаторов и хелперам).
0
Для этого есть готовые платформы аля 1с, MS Axapta,Dynamics и прочие, которые предотвращают от огромного количества проблем… а наши хотят сразу сэкономить, зато проблем впоследствии получают выше крыши… менталитет, блин…
0
Axapta и Dynamics не одно и то же, случайно?
Нет, это мощные продукты, я не спорю, но
а) «Блин, их же кто-то написал. Так неспортивно»
б) там своих косяков выше крыши — что в Sharepoint, что в Axapta.
Нет, это мощные продукты, я не спорю, но
а) «Блин, их же кто-то написал. Так неспортивно»
б) там своих косяков выше крыши — что в Sharepoint, что в Axapta.
0
платформа общая… просто Axapta — ERP, Dynamics — CRM
а)дело не в спорте, а в личной выгоде… это большая проблема всех ИТ-шников слишком большой спортивный интерес, сам страдаю))
б) имел дело с Sharepoint, все баги умело решаются среднячковым знанием ASP.NET и прямыми руками… хотя и там все безрадостно
но главная суть вот в чем, кто напишет и оттестирует лучше… команда из 20-30 разработчиков\тестеров или вы с несколькими коллегами...? согласитесь, они свой хлеб не даром получаю… выгода и минимальные личные затраты лучший выход… иногда проще раскрутить начальство(правильно), чем просиживать ночами… непонятно за чем, но это из личного опыта…
а)дело не в спорте, а в личной выгоде… это большая проблема всех ИТ-шников слишком большой спортивный интерес, сам страдаю))
б) имел дело с Sharepoint, все баги умело решаются среднячковым знанием ASP.NET и прямыми руками… хотя и там все безрадостно
но главная суть вот в чем, кто напишет и оттестирует лучше… команда из 20-30 разработчиков\тестеров или вы с несколькими коллегами...? согласитесь, они свой хлеб не даром получаю… выгода и минимальные личные затраты лучший выход… иногда проще раскрутить начальство(правильно), чем просиживать ночами… непонятно за чем, но это из личного опыта…
+2
Dynamics — это не продукт — это общее название для семейства бизнес продуктов Miсrosoft. Axapta теперь называется Dynamics Ax, есть также Dynamics Nav — бывший Navision, Dyncmics CRM, Dynamics GP (бывший Great Plains)
+2
вот — очень круто сказал:) 20-30 разработчиков и тестеров, но в РФ никто в ИТ не понимает необходимость такого подхода. Минимизация такова, что пусть напишут говно, которое тестируется уже в проме на клиентах, чем будут держать штат из кучи разработчиков.
Такое делают только те люди, которые сами проработали в Штатах\Лондоне и все на своей шкуре почувствовали. Яркий пример — Parallels — ребята жгут напалмом, софт один из лучших.
Не знаю, что надо сделать, чтобы у нас были такие команды разработчиков? Разве что самому бизнес организовывать.
Такое делают только те люди, которые сами проработали в Штатах\Лондоне и все на своей шкуре почувствовали. Яркий пример — Parallels — ребята жгут напалмом, софт один из лучших.
Не знаю, что надо сделать, чтобы у нас были такие команды разработчиков? Разве что самому бизнес организовывать.
0
Имхо, вам надо увольняться и становиться прямым конкурентом ваших выбших работодателей.
+4
Это хороший ответ на вопрос, который я постеснялся задавать :) Но архитектуру нужно делать — править эту или верстать новую, и я не знаю, как сделать все шоколадно.
Увольняюсь через две недели, конкурентом вряд ли:
а) подписано соглашение о неконкуренции сроком на 1 год;
б) по результатам небольшого приватного исследования стало ясно, что -компания, в которой я работаю, за 2008г получила прибыль 1.8млрд рублей
Самая грустная правда состоит в том, что это больше репутационный бизнес, чем сервисный или продуктовый. Чтобы убедиться в этом, достаточно посмотреть на SAP и поговорить с внедренцами.
Увольняюсь через две недели, конкурентом вряд ли:
а) подписано соглашение о неконкуренции сроком на 1 год;
б) по результатам небольшого приватного исследования стало ясно, что -компания, в которой я работаю, за 2008г получила прибыль 1.8млрд рублей
Самая грустная правда состоит в том, что это больше репутационный бизнес, чем сервисный или продуктовый. Чтобы убедиться в этом, достаточно посмотреть на SAP и поговорить с внедренцами.
0
да SAP-вцы умеют щеки надувать…
+1
Ну, один год можно и подождать — съездить на юг позагорать например. А что касается большой страшной компании — я сейчас примерно в такой же ситуации — у меня маленькая фирма которую никто не знает. Это не значит что мы чем-то хуже других, скорее наоборот, у нас пока еще не так много «разрухи в головах». Но доказать это внешнему миру конечно же не просто.
+1
Соглашение о неконкуренции можно быстро убрать через хорошего адвоката.
0
нужно писать продукт подпольно 1 год, а потом выкатить на публику и будет профит!
0
Сочувствую, но волшебных языков нет и видимо не будет. Сейчас я далек, слава богу, от БД и предложить то-то новое современное не смогу. Но в юности с восторгом юзал FoxPro. И в те ранние годы я как раз использовал подход с метаданными, но они не были интегрированы в систему, а использовались только для генерации кода приложения. С этой целью мной был перелопачен код стандартного генератора экранов и подпилен в нужных местах напильником. С использованием метаданных у меня генерировался код обновления БД на новую версию с переносом данных, код переноса данных из одной БД в другую с сохранением уникальности ключей, а так же частично код построения экранов. В частности автоматически строились контролы для выпадающих полей с данными из справочников для редактируемой записи, ну и прочие мелочи.
Помню, особый восторг у меня вызвал момент когда по метаданным у меня автоматически сгенерировался код переноса данных из одной БД в другую с сохранением уникальности ключей для связанных таблиц с подчинением в 3 уровня и когда этот код без ошибок заработал с первой попытки. Взглянув на него я понял, что никогда бы не написал подобный код вручную без ошибок с первого раза…
Нужно отметить что в то время я успешно закончил проект и именно благодаря автоматической генерации кода у меня практически не было ошибок при показе готового проекта заказчику.
Не знаю насколько это применимо к Вашему случаю, но мне такой подход в свое время сильно сэкономил время и нервы.
Помню, особый восторг у меня вызвал момент когда по метаданным у меня автоматически сгенерировался код переноса данных из одной БД в другую с сохранением уникальности ключей для связанных таблиц с подчинением в 3 уровня и когда этот код без ошибок заработал с первой попытки. Взглянув на него я понял, что никогда бы не написал подобный код вручную без ошибок с первого раза…
Нужно отметить что в то время я успешно закончил проект и именно благодаря автоматической генерации кода у меня практически не было ошибок при показе готового проекта заказчику.
Не знаю насколько это применимо к Вашему случаю, но мне такой подход в свое время сильно сэкономил время и нервы.
+1
поддержка FoxPro будет адски дорого стоить… именно сопровождение
+1
Огроменное спасибо; видимо, я копаю в нужном направлении — у меня счас код обновления БД тоже генерится автоматически.
Все же, любой подход неидеален, и нам счас приходится расплачиваться за то, что мы реляционные данные засунули в объектные. Отсюда и танцы с кодогенераторами, компиляцией на лету и NHibernate.
Самый большой страх — что 50GB данных однажды сольются в /dev/null из-за неверного скрипта )
Все же, любой подход неидеален, и нам счас приходится расплачиваться за то, что мы реляционные данные засунули в объектные. Отсюда и танцы с кодогенераторами, компиляцией на лету и NHibernate.
Самый большой страх — что 50GB данных однажды сольются в /dev/null из-за неверного скрипта )
0
> Самый большой страх — что 50GB данных однажды сольются в /dev/null из-за неверного скрипта )
Бекап?
Бекап?
0
Конечно да )
— сделали бэкап;
— поставили обновление, оно похерило _некоторые_ данные. искать их среди 50G — сложно )
— ???
— где профит?
Понятно, что делаем и инкреметные, и полные бэкапы, но это уже тупой аварийный вариант, не дающий полезной информации, почему все похерилось.
— сделали бэкап;
— поставили обновление, оно похерило _некоторые_ данные. искать их среди 50G — сложно )
— ???
— где профит?
Понятно, что делаем и инкреметные, и полные бэкапы, но это уже тупой аварийный вариант, не дающий полезной информации, почему все похерилось.
0
может перенести в «учись работать» или «разработка»?
0
В крупных проектых сказывается проблема подхода реляционных БД.
В таких системах очень сильно помогла бы Объектно-ориентированная СУБД, например Intersystems Cashe. Хотя это палка о двух концах.
В таких системах очень сильно помогла бы Объектно-ориентированная СУБД, например Intersystems Cashe. Хотя это палка о двух концах.
0
У нас данные сами по себе крайне реляционны. Ну и не мне рассказывать, как счас руководство относится к немейнстрим-продуктам, да еще и бюджет под это выделять.
Хотя, я думаю, что всякие такие специфические штуки в общем случае только усложняют дело. Да и легаси данные так просто не скинуть — их оооочень много.
Хотя, я думаю, что всякие такие специфические штуки в общем случае только усложняют дело. Да и легаси данные так просто не скинуть — их оооочень много.
0
UFO just landed and posted this here
Согласен с вами.
Никому НЕ СОВЕТУЮ CACHE — это попа и жёсткая привязка к спецам, которые просто тянут бабки! Приходилось самому разбираться с этим Cache и вникать, как и чего…
В результате (обхитрил спецов) экспортировал все данные и переписал ВСЮ логику работы на нормальный язык и прицепил к MSSQL
Никому НЕ СОВЕТУЮ CACHE — это попа и жёсткая привязка к спецам, которые просто тянут бабки! Приходилось самому разбираться с этим Cache и вникать, как и чего…
В результате (обхитрил спецов) экспортировал все данные и переписал ВСЮ логику работы на нормальный язык и прицепил к MSSQL
0
Ничего плохого в Cache нет, хорошая вещь и код нормальный, говнокодом он становится благодаря говнописателям не более.
Привязка к спецам, да возможно, но ведь в разных продуктах в свое время была нехватка специалистов и ничего все движется и развивается.
Проблема Cache' в том, что InterSystems устраивает текущее положение вещей, количество партнеров и клиентов для существования компании, и в связи с этим нет активной популяризации продуктов компании.
Хотя для нас как специалистов в данной области, думаю было бы лучше если бы спецов было больше.
а на счет стоимости специалистов, не думаю что цены на нас сильно отличаются от других специалистов.
Привязка к спецам, да возможно, но ведь в разных продуктах в свое время была нехватка специалистов и ничего все движется и развивается.
Проблема Cache' в том, что InterSystems устраивает текущее положение вещей, количество партнеров и клиентов для существования компании, и в связи с этим нет активной популяризации продуктов компании.
Хотя для нас как специалистов в данной области, думаю было бы лучше если бы спецов было больше.
а на счет стоимости специалистов, не думаю что цены на нас сильно отличаются от других специалистов.
0
А у вас был опыт с большими проектами на caché?
0
UFO just landed and posted this here
Понимаете, я бы с вами полностью согласился, по обоим пунктам, если бы не следующее наблюдение (по обоим пунктам, соответственно):
— бизнес-требования тоже не с потолка берутся; если наша система не предвидела их изменения, то это наша (конструкторов системы) проблема и только наша; потому что любое управление начинается с управления рисками, в том числе и рисками по требованиям;
— когда я вижу, как на фикс надписи и окна about выделяют 4 человеко-дня (sic!), а в остаток люди смотрят статистику по футболам и играют на бирже, руки опускаются что-то делать вообще.
Так что единственная невозможность на месте работы — это мы сами. Программисты такие слабые, а обстоятельства — такие сильные, требования — такие непредсказуемые. Так что искренне надеюсь, вы не восприняли ваших старших разработчиков всерьез.
И я не случайно написал про репутацию в бизнесе — это тот случай, когда правило «нет потенции — на%уй с рынка» не действует, и мы имеем то, что имеем — террабайтные зарплаты и полную некомпетентность.
Эх, ладно.
Тут кагбе не в этом вопрос — вопрос исключительно архитектурный: есть ли действующие, проверенные сообществом средства забороть БД без monkey-coding? Я это спрашиваю на Хабре, потому что думаю, что имею хороший шанс услышать ответ на этот вопрос.
— бизнес-требования тоже не с потолка берутся; если наша система не предвидела их изменения, то это наша (конструкторов системы) проблема и только наша; потому что любое управление начинается с управления рисками, в том числе и рисками по требованиям;
— когда я вижу, как на фикс надписи и окна about выделяют 4 человеко-дня (sic!), а в остаток люди смотрят статистику по футболам и играют на бирже, руки опускаются что-то делать вообще.
Так что единственная невозможность на месте работы — это мы сами. Программисты такие слабые, а обстоятельства — такие сильные, требования — такие непредсказуемые. Так что искренне надеюсь, вы не восприняли ваших старших разработчиков всерьез.
И я не случайно написал про репутацию в бизнесе — это тот случай, когда правило «нет потенции — на%уй с рынка» не действует, и мы имеем то, что имеем — террабайтные зарплаты и полную некомпетентность.
Эх, ладно.
Тут кагбе не в этом вопрос — вопрос исключительно архитектурный: есть ли действующие, проверенные сообществом средства забороть БД без monkey-coding? Я это спрашиваю на Хабре, потому что думаю, что имею хороший шанс услышать ответ на этот вопрос.
+8
я так понимаю проект на Net? Вот мне подсказывают, что ADO.NET Entity Framework вроде как неплохая вещь, но не знаю как для вашего проекта подойдет
0
UFO just landed and posted this here
идеальных вещей не бывает, сами понимаете… если данный пример не повальный по всей системе, то это не такая уж и большая проблема.
Насколько я понял автора, то он хочет избавится от всей той лапши, что есть в проекте на данный момент и грамотно его поддерживать к сожалению я с ORM системами работал поверхностно, но коллеги советуют… в подробности не вдавался…
возможно есть пример, какого -то совсем уж глобального недостатка, автору думаю тоже будет интересно…
Насколько я понял автора, то он хочет избавится от всей той лапши, что есть в проекте на данный момент и грамотно его поддерживать к сожалению я с ORM системами работал поверхностно, но коллеги советуют… в подробности не вдавался…
возможно есть пример, какого -то совсем уж глобального недостатка, автору думаю тоже будет интересно…
0
Да у него много засад. Конечно, к версии 4 его хорошо поправили, но тем не менее.
И еще один пункт, по которому он полностью не подходит — в текущей системе все генерируется при ее старте. Т.е. чисто теоретически, чтобы изменить структуру БД, не нужно ничего перекомпилировать.
EF же не поддерживает динамический маппинг — чтобы изменить структуру хранилища, нужно перекомпилировать приложение. По большому счету, EF — это не ORM, это фреймворк для построения собственного ORM.
А городить поверх не хочется )
И еще один пункт, по которому он полностью не подходит — в текущей системе все генерируется при ее старте. Т.е. чисто теоретически, чтобы изменить структуру БД, не нужно ничего перекомпилировать.
EF же не поддерживает динамический маппинг — чтобы изменить структуру хранилища, нужно перекомпилировать приложение. По большому счету, EF — это не ORM, это фреймворк для построения собственного ORM.
А городить поверх не хочется )
0
UFO just landed and posted this here
Модель меняется, в том-то и дело. Добавляются поля, добавляются таблицы/entity, меняются отношения.
0
UFO just landed and posted this here
Счас сделано на основе NHibernate + Boo: при старте сервера приложений в Boo генерится AST для объектов и DTOшки, все безобразие компилируется в отдельную сборку, куда прикручиваются маппинги. Дальше это дело отдается на съедение в допиленную фабрику сессий NHibernate, который делает неразрушающий update. В случае, если update отвалился, в дело включается самописный comparer, который производит анализ изменений и корректно обновляет БД (или ругается, если изменения невозможны и вырубает сервер).
Короче, еще долго рассказывать, но основное я показал )
Короче, еще долго рассказывать, но основное я показал )
+1
UFO just landed and posted this here
Это я вам еще не рассказал про разогрев кеша второго уровня ) И про оптимизатор на основе статистики запросов — у нас структура репозитория описывается как некоторая модель без физической привязки к БД: есть информационные объекты, у них есть свойства — простые или справочные, или деревья, или медиаконтент, или [...]. И их же нужно как-то раскидать по таблицам в БД.
Сначала используется простейшая схема, а оптимизатор собирает информацию по произведенным запросам и потом выдает рекомендации, как лучше физически организовать репозиторий с данными — одна таблица или join, куда поместить поля :)
Пока что мы не дали ему возможности самостоятельно перестроить репозиторий (от греха подальше), и он только рекомендует, но все впереди )
Сначала используется простейшая схема, а оптимизатор собирает информацию по произведенным запросам и потом выдает рекомендации, как лучше физически организовать репозиторий с данными — одна таблица или join, куда поместить поля :)
Пока что мы не дали ему возможности самостоятельно перестроить репозиторий (от греха подальше), и он только рекомендует, но все впереди )
+3
что там, про суровых парней…
0
UFO just landed and posted this here
Адекватность заказчика не обязательная причина. У меня в разработке с 2000-го года система. Что мы делаем, более-менее в подробностях узнали в 2005, сейчас каждый год что-то новое, и переделывать кучу кода некому. Все вышеописанные болезни есть, что делать непонятно. Начали новый проект, прискакали тёти-программисты на оракле, всё знают как надо правильно. Новые костыли будем для интеграции с ними делать, система усложняется…
Переписывать с нуля — идея хорошая, но надо очень много подготовительной работы сделать, причём начальство не понимает, что один или два человека — мало для поддержки старой и написания новой. Я не вижу реального выхода, кроме катастрофы.
Переписывать с нуля — идея хорошая, но надо очень много подготовительной работы сделать, причём начальство не понимает, что один или два человека — мало для поддержки старой и написания новой. Я не вижу реального выхода, кроме катастрофы.
0
Вообще-то это заказчика не должно волновать как-бы.
Просто выкатывайте такие бюджеты, за которые эти изменения можно сделать по-человечески, а не левой пяткой в пятницу вечером, а на все оставшиеся деньги купить третий лексус ;)
Просто выкатывайте такие бюджеты, за которые эти изменения можно сделать по-человечески, а не левой пяткой в пятницу вечером, а на все оставшиеся деньги купить третий лексус ;)
0
>Тут кагбе не в этом вопрос — вопрос исключительно архитектурный: есть ли действующие, проверенные сообществом средства забороть БД без monkey-coding?
Нет:) не в.нете.
Нет:) не в.нете.
0
Честно — мне вас жалко, как когда-то было жалко себя %) собственно уже озвучили вроде выше, но повторюсь. Продумать заново, переделать полностью. На счет модели сущностей, кстати, это вы зря — применялась, работала хорошо. Вопрос с нагрузкой на базу часто решается кластером, но этот уже не совсем к самой базе относится :)
0
Приведу свой пример как я выпутывался из данной ситуации. Для сайтов предпочитаю PHP, для работы с графикой C++, а вот клиентские приложения пишу на Delphi и Firebird. Бизнес логику разбиваю на блоки, каждому блоку соответствует определённая таблица в базе данных, в таблице имеются неизменные поля и одно поле для XML — в нём в виде XML храним все изменяемые дополнительные поля и их данные. Firebird умеет искать в базе по изменяемому полю в XML (хоть и немного медленнее чем по обычному полю). На страницах добавления / просмотра — использую промежуточный слой для удобной работы с изменяемыми полями XML. С виду громоздко, но очень удобно, особенно после того как написал свой редактор для визуального создания бизнес логики и генерации на основе неё базы данных. Статья на данную тему — Применение XML в реляционных БД для хранения объектов сложной структуры (http://www.ibase.ru/devinfo/xmldb.htm).
+4
Т.е. у нас получается Schemaless DB, верно? Вернее, с external schema. Мы пробовали такое внедрять, получалось слишком медленно.
В любом случае, за идею спасибо, попробую присмотреться повнимательнее.
Простите за вопросы, а как устроена загрузка данных из таких полей — если поле добавлено, надо ли где-то еще писать код, который будет выгружать/загружать это поле? Есть ли у вас lookup-поля и справочники?
В любом случае, за идею спасибо, попробую присмотреться повнимательнее.
Простите за вопросы, а как устроена загрузка данных из таких полей — если поле добавлено, надо ли где-то еще писать код, который будет выгружать/загружать это поле? Есть ли у вас lookup-поля и справочники?
0
Например: Программа органайзер, таблица — задания. Обязательные поля — ID, название задания, дата начала, дата окончания, процент завершённости, BLOB поле в котором хранится XML с изменяемыми полями и их данными. XML — поле 1 и его данные, поле 2 и его данные и т.д. В XML храню только текст, или ID BLOB полей из например: таблицы — фото сотрудников задействованных в проекте. Правда при поиске по полю (например: поле 1) из XML — читается и парсится весь XML, но учитывая что это автоматически делается в БД Firebird — то у меня это производится относительно быстро.
Загрузку из полей делаю нетривиально, XML читаю в память, дальше в Delphi есть компонент позволяющий отображать XML — как обычную таблицу из базы данных (и работать как с обычной таблицой, т.е. например на форме будет 2 DBGRID — одна с названием заданий, по нажатию на неё грузится XML с доп полями описывающими данное задание). Отдельно на диске храню описание какие поля в XML в данной таблице есть и их ограничение по вводу символов и их количеству, при создании формы добавления — автоматически генерируется на базе этого описания компоненты и располагаются на форме. Ну а само сохранение — это сохранение части данных в БД и генерация XML на основе другой части данных, с последующим сохранением в БД.
Lookup-поля реализуйте в коде — выборка из определённой таблицы, заполнение комбобокса, вывод комбобокса на форме добавления данных в БД и сохранение выбранного значения в комбобоксе в БД. Т.е. часть логики и связей переносится из БД в приложение — это несколько сложновато.
Загрузку из полей делаю нетривиально, XML читаю в память, дальше в Delphi есть компонент позволяющий отображать XML — как обычную таблицу из базы данных (и работать как с обычной таблицой, т.е. например на форме будет 2 DBGRID — одна с названием заданий, по нажатию на неё грузится XML с доп полями описывающими данное задание). Отдельно на диске храню описание какие поля в XML в данной таблице есть и их ограничение по вводу символов и их количеству, при создании формы добавления — автоматически генерируется на базе этого описания компоненты и располагаются на форме. Ну а само сохранение — это сохранение части данных в БД и генерация XML на основе другой части данных, с последующим сохранением в БД.
Lookup-поля реализуйте в коде — выборка из определённой таблицы, заполнение комбобокса, вывод комбобокса на форме добавления данных в БД и сохранение выбранного значения в комбобоксе в БД. Т.е. часть логики и связей переносится из БД в приложение — это несколько сложновато.
0
Помните XML — для нечасто изменяемых и просматриваемых полей, иначе проще реализовать процедуру которая по описанию будет генерировать таблицу в БД и по этому же описанию создавать формы просмотра и добавления данных в БД.
И уточню — эти 2 варианта, если Вам нужно что бы клиент из своей программы менял бизнес — логику программы. Иначе если у Вас есть возможность перекомпилировать программу — используйте дизайнеры, например в Delphi есть встроенный дизайнер UML схем который на базе созданной вами схемы генерирует и классы формы и скрипт для создания базы данных, только методы не прописывает :). Работать с таким дизайнером дольше — но он очень гибко, в случае необходимости изменений они делаются наиболее удобно.
И уточню — эти 2 варианта, если Вам нужно что бы клиент из своей программы менял бизнес — логику программы. Иначе если у Вас есть возможность перекомпилировать программу — используйте дизайнеры, например в Delphi есть встроенный дизайнер UML схем который на базе созданной вами схемы генерирует и классы формы и скрипт для создания базы данных, только методы не прописывает :). Работать с таким дизайнером дольше — но он очень гибко, в случае необходимости изменений они делаются наиболее удобно.
0
Спасибо большое. Боюсь, что вариант не для нас — одновременно работают несколько сотен клиентов (в среднем 800-1000) и цимес как раз в совместной работе над данными.
Все равно спасибо, интересный вариант
Все равно спасибо, интересный вариант
0
Одновременно работают несколько сотен клиентов — тогда мои 2 варианта неподходят, так как программа большая. Тогда Вам поможет только разбивка программы на DLL — как на логические блоки + дизайнер (3 предложенный мной вариант). Нужно что-то изменить — поменяли в дизайнере, перекомпилировали соответствующую DLL и DLL загрузчик — всех DLL в программе, обновили. Это очень масштабируемо и гибко, но очень трудоёмко в человеко-часах.
0
Я когда вижу эту картинку про интерфейсы, на месте последней у меня в воображении рисуется типичное окошко 1С: Предприятия. Брр…
0
это вы 7-ку видели наверное… дааа там полное бррр…
0
UFO just landed and posted this here
еще как,+ возможно вы видели не типовую конфигурацию… а в среде 1с нет понятия разработчик интерфейсов, программист он же тебе и разработчик интерфейсов.Кстати, последняя тестовая версия выглядит вполне неплохо v8.1c.ru/beta_ma/interface_conc.htm
p.s: отвращение наблюдается даж у самих 1с-ников, но как это не странно при правильном подходе и нормальной команде, она может творить чудеса… другой вопрос, что это не у всех получается…
p.s: отвращение наблюдается даж у самих 1с-ников, но как это не странно при правильном подходе и нормальной команде, она может творить чудеса… другой вопрос, что это не у всех получается…
0
Блин, как хорошо что я дизайнер…
Хотя завидую программистам иногда, особенно когда сталкиваюсь со скриптами (речь про сайты).
Хотя завидую программистам иногда, особенно когда сталкиваюсь со скриптами (речь про сайты).
-2
С точки зрения программиста, есть такая новая штука — Jetbrains MPS.
Это современная, открытая и бесплатная DSL IDE.
Суть проста — создаёшь в ней свою предметную область («бывают счета, бывают менеджеры»), натягиваешь прямо там бизнес-правила («золотой счёт может закрыть только супер-менеджер»), и пишешь отображение всего этого в код («счёт отражается в таблицу реляционной БД, признак супер-менеджера это булев флаг в ActiveDirectory, а окно закрытия — web-страница») на всяких языках и… внимание… компилируешь!
Т.е. там абсолютно везде ненавязчивый и непробиваемый strict type check с правилами вывода, а в редакторе автокомплит (на базе лучшей на планете IDE от Jetbrains). Хоть в SQL, хоть в HTML хоть в выходном Java-коде. Причём, семантическое пространство единое для всего.
Как результат, если где-то в html ты захочешь отпечататься в названии булева атрибута, это в принципе не позволит редактор.
Все фанаты РубиОнРейлс идут нервно курить и рвать волосы за бесцельно прожитые годы.
«Отчёт», опять же, является сущностью в предметной области. «Годовой отчёт» — конкретный экземпляр сущности (всё редактируется прямо в IDE, никакой редактор не сравнится). Годовой отчёт в системе это смесь java-sql-чтохочешь, а на экране человека это уже html страница, например.
зы. Нет, я у них не работаю, к сожалению
Это современная, открытая и бесплатная DSL IDE.
Суть проста — создаёшь в ней свою предметную область («бывают счета, бывают менеджеры»), натягиваешь прямо там бизнес-правила («золотой счёт может закрыть только супер-менеджер»), и пишешь отображение всего этого в код («счёт отражается в таблицу реляционной БД, признак супер-менеджера это булев флаг в ActiveDirectory, а окно закрытия — web-страница») на всяких языках и… внимание… компилируешь!
Т.е. там абсолютно везде ненавязчивый и непробиваемый strict type check с правилами вывода, а в редакторе автокомплит (на базе лучшей на планете IDE от Jetbrains). Хоть в SQL, хоть в HTML хоть в выходном Java-коде. Причём, семантическое пространство единое для всего.
Как результат, если где-то в html ты захочешь отпечататься в названии булева атрибута, это в принципе не позволит редактор.
Все фанаты РубиОнРейлс идут нервно курить и рвать волосы за бесцельно прожитые годы.
«Отчёт», опять же, является сущностью в предметной области. «Годовой отчёт» — конкретный экземпляр сущности (всё редактируется прямо в IDE, никакой редактор не сравнится). Годовой отчёт в системе это смесь java-sql-чтохочешь, а на экране человека это уже html страница, например.
зы. Нет, я у них не работаю, к сожалению
+2
Кстати, Bytexpert (http://habrahabr.ru/blogs/development/68337/#comment_1938478) описывает как раз такую систему, которую он сделал на основе FoxPro.
Сейчас напильник не нужен — подобная кодогенерация в MPS это основа системы.
Сейчас напильник не нужен — подобная кодогенерация в MPS это основа системы.
0
а примеры реального применения, при котором с помощью этой MPS укрощаются монстры описанные в топике есть?
0
Конечно, нет. Иначе бы они захватили мир уже =)
я думаю, хабрачеловек konstantinsolomatov, ведущий разработчик этой системы может поправить, если я где перегнул в диферамбах (наоборот скорее) и подскажет где искать примеры в жизни.
Однако, по моим данным сейчас публично доступна лишь Харизма. И то без исходников.
я думаю, хабрачеловек konstantinsolomatov, ведущий разработчик этой системы может поправить, если я где перегнул в диферамбах (наоборот скорее) и подскажет где искать примеры в жизни.
Однако, по моим данным сейчас публично доступна лишь Харизма. И то без исходников.
0
Именно так:
— нет real-wolrd приложений.
— нет reverse engineering.
— нет отладки.
— нет buildartfacts, чтобы встроить это в CI-сервер.
Так что работы там — непочатый край :) А тянуть это в production сейчас — надо вообще долбануться.
Ну и еще — спецов по ней нет, тем более нет понимания, как писать инфраструктуру для нее — без обвязки ни одни скрипт не взлетит.
— нет real-wolrd приложений.
— нет reverse engineering.
— нет отладки.
— нет buildartfacts, чтобы встроить это в CI-сервер.
Так что работы там — непочатый край :) А тянуть это в production сейчас — надо вообще долбануться.
Ну и еще — спецов по ней нет, тем более нет понимания, как писать инфраструктуру для нее — без обвязки ни одни скрипт не взлетит.
0
Безусловно, я немного опередил время =)
язык для работы с sql, html, js, css и прочими вкусностями у них есть (на MPS написана Charisma), но пока не опубликован.
Наверняка будет очень здорово, если опубликуют.
Ну и фундаментальных проблем там тоже хватает.
Например, программист, который создаёт язык для предметной области («бывают счета, бывают менеджеры») должен быть сразу и Очень Опытным программистом и иметь полное знание предметной области (например, через армию аналитиков).
Зато после этого (фактически, после первой реализации первой ERP-CRM-etc для первой компании на основе MPS) остальные заказы становятся на поток. Т.е. ответственность на архитекторе значительно больше чем обычно.
язык для работы с sql, html, js, css и прочими вкусностями у них есть (на MPS написана Charisma), но пока не опубликован.
Наверняка будет очень здорово, если опубликуют.
Ну и фундаментальных проблем там тоже хватает.
Например, программист, который создаёт язык для предметной области («бывают счета, бывают менеджеры») должен быть сразу и Очень Опытным программистом и иметь полное знание предметной области (например, через армию аналитиков).
Зато после этого (фактически, после первой реализации первой ERP-CRM-etc для первой компании на основе MPS) остальные заказы становятся на поток. Т.е. ответственность на архитекторе значительно больше чем обычно.
-1
С точки зрения менеджера-аналитика, вся ценность SAP именно в предлагаемой модели предметной области.
Там уже есть все отчёты по GAAP и т.п. штуки, которые в своей системе в принципе не реализовать просто из-за колоссального объёма работы.
Хоть на Java, хоть на SQL хоть на MPS.
И покупают Baan, SAP, 1с вовсе не для удобства программирования, а потому что там нужно добавить одно-два-десять полей, а не всю сущность целиком, потратив на анализ предприятия полгода.
Как там поля добавляются в БД — дело стопятьсотое.
Там уже есть все отчёты по GAAP и т.п. штуки, которые в своей системе в принципе не реализовать просто из-за колоссального объёма работы.
Хоть на Java, хоть на SQL хоть на MPS.
И покупают Baan, SAP, 1с вовсе не для удобства программирования, а потому что там нужно добавить одно-два-десять полей, а не всю сущность целиком, потратив на анализ предприятия полгода.
Как там поля добавляются в БД — дело стопятьсотое.
+2
Нихрена непонятно, кроме того, что все плохо, и выхода нет. В чем проблема то? Свойства записей специфичны для различных клиентов + есть общая аналитика?
0
UFO just landed and posted this here
Я для себя проблему решил так
Была сделана унифицированная форма с тегированием (выбором значения по первым символам) и двумя полями
Name:Value
Никаких обязательных полей ввода и соответственно — ввод данных без мышки
Потом была генерация отчетов и показывался процент содержимого который не участвует в отчете — допустим 17%
И руководство в лице совета директоров мне сказало — ты гений, потому что затраты на ресурсы, необходимые на ввод информации для генерации оставшихся 17% не принесут никакого профита, и уж по тем данным что сгенерированы и так понятно что делать
И сотрудники, операторы, которые вводили — тоже сказали, спасибо что так облегчил ввод данных
Вобщем все были довольны
Была сделана унифицированная форма с тегированием (выбором значения по первым символам) и двумя полями
Name:Value
Никаких обязательных полей ввода и соответственно — ввод данных без мышки
Потом была генерация отчетов и показывался процент содержимого который не участвует в отчете — допустим 17%
И руководство в лице совета директоров мне сказало — ты гений, потому что затраты на ресурсы, необходимые на ввод информации для генерации оставшихся 17% не принесут никакого профита, и уж по тем данным что сгенерированы и так понятно что делать
И сотрудники, операторы, которые вводили — тоже сказали, спасибо что так облегчил ввод данных
Вобщем все были довольны
+1
Столкнувшись со сложной проблемой такого рода, я написал кодогенератор. Главная его особенность — расширяемость. Как только мне нужно что-то унифицировать — я могу парой строк проапгрейдить всю систему уеликом.
Кодогенерация — достойный ответ абстрации.
Кодогенерация — достойный ответ абстрации.
+1
у кодогенератора есть одна, а может быть и не одна :) проблема, когда нужно сделать какую нибудь специальную штуковину то
либо нужно дописать кодогенератор, это не всегда просто
либо ты правишь код, но тогда уже его заново сгенерировать(в случаи каких либо изменений в генераторе) не так то и просто
либо нужно дописать кодогенератор, это не всегда просто
либо ты правишь код, но тогда уже его заново сгенерировать(в случаи каких либо изменений в генераторе) не так то и просто
0
«Различные требования» означает еще и то, что им всем (клиентам) нужны отличающиеся данные. В здравом уме никто не будет использовать разные БД под разные клиенты, потому что это brain damage, поэтому все данные так или иначе лежат в одной БД. Кроме различающихся данных, нужен также и различающийся UI — определяется клиентом, ролями, еще десятком параметров логики и фазы луны.
Эх-эх. Любой достаточно большой комплекс ПО требует такого. Это называется представление данных для клиента. Прежде чем рубать шашкой и писать кучу кода, в таком случае лучше спокойно и тихо взять UML или любое другое средство построения диаграмм и проанализировать сколько у вас таких представлений и по каким данным они пересекаются. Все малосвязное уносится в отдельные схемы, специфичные для каждого представления. Любая момальски нормальная СУБД поддерживает схемы внутри базы позволяя разделить базу данных на логические части.
С моей точки зрения проблема не в том какое средство выборано, а в том что небыл проведен анализ того что имеем и куда и как оно будет развиваться. Как результат внесение любых достаточно крупных изменений стал приводить к возможной поломке.
+4
Не очень я люблю это слово, но единственное спасение — «рефакторинг», или начать все с начала.
+1
Я Вас понимаю…
+1
ох ;) жесть ;) прям эволюция ;) неповоротливого монстра сменяет молодой и шустрый ;) и сам со временем превращается в монстра ;) и так по кругу пока крутится колесо сансары ;)
+2
UFO just landed and posted this here
UFO just landed and posted this here
Спасибо за совет, но вы опоздали: — я уже могу цитировать эту книгу наизусть, будучи разбуженным в 3 часа ночи :) Горькая правда состоит в том, что а) в случае «толстого» клиента Фаулер говорит, что умывает руки «разбирайся, сцуко, сам» б) модель предметной области хороша для OLTP; у нас слишком много сырых данных и OLAP.
Насчет анемичной («худой» в вашей терминологии) в applied comuter science сломано копий больше, чем было сделано :) EF, например, признает в основном анемичную модель (по крайней мере, в первой версии).
В любом случае сенкс, я пользовался именно этой книгой, когда проектировал последний вариант, с ORM )
Насчет анемичной («худой» в вашей терминологии) в applied comuter science сломано копий больше, чем было сделано :) EF, например, признает в основном анемичную модель (по крайней мере, в первой версии).
В любом случае сенкс, я пользовался именно этой книгой, когда проектировал последний вариант, с ORM )
+2
О! Как сказал один умный человек: Чем дальше слушаю, тем больше понимаю, что люди начинают изобретать то, что в Zope изобрели 100 лет назад.
Короче если, то Zope использует объектную БД. Объект лучше сконструировать так, чтобы он содержал в себе данные и представление.
Архитектура Python поддерживает интроспекцию, это значит, что все свойства можно перечислить в рантайм и получить их значение. А это значит в свою очередь, что вы можете сделать снимок объекта и сохранить его в поток. А потом восстановить (Помоему objective C еще так умеет, ну и смоллток).
Что это значит? А то, что вся логика записи, чтения из/в БД ушла. Вы создали объект и он живет. Тот факт что вы выключали сервер и заменили винты объект не заметил.
Кроме того, вы добавили 10 полей в платежку. Что делать со старыми платежками? Оставить поля пустыми? Заполнить информацией которой небыло в то время?
В случае с ZODB у вас просто будут старые объекты с старым UI. Да по подмножеству данных можно будет производить запросы и получать в том числе и старые объекты.
Кстати очень хочется это все сделать с помощью FramerD
Короче если, то Zope использует объектную БД. Объект лучше сконструировать так, чтобы он содержал в себе данные и представление.
Архитектура Python поддерживает интроспекцию, это значит, что все свойства можно перечислить в рантайм и получить их значение. А это значит в свою очередь, что вы можете сделать снимок объекта и сохранить его в поток. А потом восстановить (Помоему objective C еще так умеет, ну и смоллток).
Что это значит? А то, что вся логика записи, чтения из/в БД ушла. Вы создали объект и он живет. Тот факт что вы выключали сервер и заменили винты объект не заметил.
Кроме того, вы добавили 10 полей в платежку. Что делать со старыми платежками? Оставить поля пустыми? Заполнить информацией которой небыло в то время?
В случае с ZODB у вас просто будут старые объекты с старым UI. Да по подмножеству данных можно будет производить запросы и получать в том числе и старые объекты.
Кстати очень хочется это все сделать с помощью FramerD
+4
Странные вы какие-то… Или я… а почему бы не делать основную таблицу чего либо, например продукт. У нас имеются поля id, name, все! Дальше есть у нас таблица с полями которые могут быть в продуктах и таблица со значениями полей для продуктов.
Теперь нам добавлять новое поле в таблицу не надо… Все работает на лету… Да тут надо правильно ставить индексы и если продуктов много, то у нас одна таблица будет очень большая, но это с лихвой решает проблему добавления поля в таблицу.
Теперь нам добавлять новое поле в таблицу не надо… Все работает на лету… Да тут надо правильно ставить индексы и если продуктов много, то у нас одна таблица будет очень большая, но это с лихвой решает проблему добавления поля в таблицу.
0
Наверное, это мы странные.
Хочу разобраться. Предположим, у продукта было 10 каких-то полей. Вы добавили в таблицу еще 10 разных полей. Вопросы:
— как у вас выглядит sql-запрос на извлечение продукта с id=42, можете написать?
— что делать, если нужны relations/constraints между такими, добавленными, полями?
Есть ощущение, что вы в основном занимаетесь электронными магазинами с БД на 10MB. Не обижайтесь, если что.
Хочу разобраться. Предположим, у продукта было 10 каких-то полей. Вы добавили в таблицу еще 10 разных полей. Вопросы:
— как у вас выглядит sql-запрос на извлечение продукта с id=42, можете написать?
— что делать, если нужны relations/constraints между такими, добавленными, полями?
Есть ощущение, что вы в основном занимаетесь электронными магазинами с БД на 10MB. Не обижайтесь, если что.
0
Эта тривиальная модель организации данных — абсолютно не пригодна в системах с большими объемами данных, хотя может и на бумаге она покажется суперуниверсальной и в ней можно хранить все объекты мира. Но как автор топика уже перечислил в своих проблемах —
При такой структуре таблиц база просто умрет в join'ax.
Не будет работать.
При такой структуре таблиц база просто умрет в join'ax.
Не будет работать.
+1
Ну почему-то PostgreSQL не умирает. База разрослась до 120 гигов плюс еще гигов 30-40 индексы.
+1
Ну учитывая, что у вас в интересах написано «кластеры», я думаю, что знаю ответ на вопрос, почему она не умирает :)
0
ну я занимаюсь другими кластерами…
База живет на одной машинке, правда хорошей:
4 x AMD Opteron 64 X2, 16Gb RAM и HP Smart Array 1000 с 14-тью винтами в RAID-10 :) Файловая система JFS.
База живет на одной машинке, правда хорошей:
4 x AMD Opteron 64 X2, 16Gb RAM и HP Smart Array 1000 с 14-тью винтами в RAID-10 :) Файловая система JFS.
+1
Ясно. Насчет магазинов я поторопился, не обессудьте :)
А БД у вас сильная, у нас под SAPом такие машины; а наша система — она много дешевле, и требует меньше: с2d 2GHz и 2G RAM для БД и такой же под сервер приложений, только памяти 1G.
А БД у вас сильная, у нас под SAPом такие машины; а наша система — она много дешевле, и требует меньше: с2d 2GHz и 2G RAM для БД и такой же под сервер приложений, только памяти 1G.
0
ну а как тут не ставить сильную машину, если транзакционные вставки примерно 1000 в секунду :)
А когда идет принятие ставок в онлайн на идущие матчи — то тут вообще… LA сразу поднимается до 20-ти…
С начала у нас и была Зопа… Кстати полностью оправдывается название… Потом переписали на Erlang :) Заместь кластера для Зопы осталась одна машинка порядка AMD Athlon64 3200+/1Gb :)
А когда идет принятие ставок в онлайн на идущие матчи — то тут вообще… LA сразу поднимается до 20-ти…
С начала у нас и была Зопа… Кстати полностью оправдывается название… Потом переписали на Erlang :) Заместь кластера для Зопы осталась одна машинка порядка AMD Athlon64 3200+/1Gb :)
+1
Кстати я бы вам посоветовал смотреть в сторону Erlang/OTP и Mnesia.
0
Автор топика уже написал об этом:
По моему опыту, в некоторых ситуациях это может быть хорошим частным решением, но универсальным рецептом не является.
Если попытаться красиво разнести модель, например, в Entity Attribute Value, то выходит полная задница с запросами:
— писать вручную их еще хуже, чем просто понять, что происходит.
— производительность вылетает в трубу: сервер СУБД увлеченно занят join-ами, а остальное безобразно простаивает.
По моему опыту, в некоторых ситуациях это может быть хорошим частным решением, но универсальным рецептом не является.
+1
Наверное ид_объекта, ид_свойства, значение_свойства, не? При генерации отчета с различном наборе полей в условии ограничения по ид_свойства. Или я чего-то не понимаю?
0
А я вот очень люблю такие проекты. Формализовать заложенную логику, вырисовывать UMLки сущностей-отношений, писать тесты и проводить редизайн-рефакторинг. И все это при почти упавшем флажке таймера. Как по черной трассе нестись на борде, тока без риска травм — ну уволят в крайнем случае. Но ведь покатушки — это не для травм, а для удовольствия, да.
0
Очевидно текст написан в момент душевного кризиса. :) Это бывает. На самом деле такое «вычерпывание кружками» — это нормальный рабочий процесс, который работает повсеместно. Проекты ведутся десятки лет, пять раз сменившимся коллективом. Делается просто — все что можно — инкапсулируется (селект во вьюшку, вьюшка в функцию, функция в функцию) и всегда есть возможность поставить костыль на любом уровне. Добавление полей требует обычно только немного поменять вызов одной функции. Переписывать же общие отчеты периодически тоже приходится, но в этом нет ничего фатального. Главное вбить в головы разработчиков идею, что «все что вы пишете может быть использовано не только вами и в самых извратских целях». Это учит писать вполне модификабельный код который патчить другим поколениям вовсе не так сложно как может показаться.
+3
>>который работает повсеместно
Это очень похоже на принцип «миллионы мух не могут ошибаться» )
Дело в том, что не хочется придти к нормальному продукту только к восьмой версии, как в 1С :) Я просто не доживу до этого счастливого момента — уволюсь, остыну и все такое :) Хочется как лучше.
И да — кризиса душевный уже полгода как позади, а счас — анализ результатов кипучей пост-кризисной деятельности по приведению в порядок :)
Спасибо.
Это очень похоже на принцип «миллионы мух не могут ошибаться» )
Дело в том, что не хочется придти к нормальному продукту только к восьмой версии, как в 1С :) Я просто не доживу до этого счастливого момента — уволюсь, остыну и все такое :) Хочется как лучше.
И да — кризиса душевный уже полгода как позади, а счас — анализ результатов кипучей пост-кризисной деятельности по приведению в порядок :)
Спасибо.
+1
прочувствованно :)
могу лишь покивать и посоветовать объектные бд или хмл
могу лишь покивать и посоветовать объектные бд или хмл
0
Последний предложенный вопрос\метод — это создание всемирного управлятора. Собственно, было опробовано у нас, спасибо, хватит:)
По-моему, чем толще система, тем разнесеннее нужно делать уровни. Слои, черные ящики и т.п. — конкретно что и как должно быть не скажу, не знаю какая у вас там должна быть кухня. Я у себя сделал слой данных, слой бизнес-логики, которая по факту оборачивает методы слоя данных и т.п.:) получается кошерно, жалко нет времени все добротно доделать.
С аттрибутами знаю точно, должны спасти DTO. Если все интерфейсы между слоями определить через dto то доработки по добавлению\удалению полей будут идти в несколько раз легче. Но что-то мне говорит, что никто тебе\вам этого сделать не даст:)
По-моему, чем толще система, тем разнесеннее нужно делать уровни. Слои, черные ящики и т.п. — конкретно что и как должно быть не скажу, не знаю какая у вас там должна быть кухня. Я у себя сделал слой данных, слой бизнес-логики, которая по факту оборачивает методы слоя данных и т.п.:) получается кошерно, жалко нет времени все добротно доделать.
С аттрибутами знаю точно, должны спасти DTO. Если все интерфейсы между слоями определить через dto то доработки по добавлению\удалению полей будут идти в несколько раз легче. Но что-то мне говорит, что никто тебе\вам этого сделать не даст:)
0
Проблема в том, что разнести на этой системе уже не удастся :/ Пепел SQL, прописанного в контролах на форме, стучит в мое сердце и подсказывает мне это.
Народ еще до меня решил сделать IDataProvider, который работает через web-service (http). Ну, как решил, даже что-то сделали. Но тока не до конца — с транзакциями обоср%лись, ниасилели. Оно и понятно — без ws-* очень сложно сделать ws-session. Конечно, сдаваться в arch group никто и не собирался — в обход транзакций сделали командный механизм, а куски транзакций запихали в хранимки, чтобы с клиента комбинировать их в одной БД-транзакции. Ну, ты себе представляешь, наверное, во что это вылилось :)
Cдается мне, что это самая главная беда — дырявые абстракции, когда объекты ведут себя _почти_ правильно, но в некоторых, внене логичных сценариях, отваливаются нахер (вот как транзакции, например). Это и не дает сделать по-настоящему черные ящики — все время надо ковырять им кишки.
>> никто тебе\вам этого сделать не даст:)
Эта проблема элементарно решается увольнением :))
Народ еще до меня решил сделать IDataProvider, который работает через web-service (http). Ну, как решил, даже что-то сделали. Но тока не до конца — с транзакциями обоср%лись, ниасилели. Оно и понятно — без ws-* очень сложно сделать ws-session. Конечно, сдаваться в arch group никто и не собирался — в обход транзакций сделали командный механизм, а куски транзакций запихали в хранимки, чтобы с клиента комбинировать их в одной БД-транзакции. Ну, ты себе представляешь, наверное, во что это вылилось :)
Cдается мне, что это самая главная беда — дырявые абстракции, когда объекты ведут себя _почти_ правильно, но в некоторых, внене логичных сценариях, отваливаются нахер (вот как транзакции, например). Это и не дает сделать по-настоящему черные ящики — все время надо ковырять им кишки.
>> никто тебе\вам этого сделать не даст:)
Эта проблема элементарно решается увольнением :))
0
да проще быть надо.
Таблица есть? пиши круд в хранимках.
Добавилось поле? Пиши поле в хранимке.
Трудно проводить регресс? Сделай юнит-тест.
Трудно сделать юнит-тест? Сделай легкий апи, который позволит написать автотест.
Сложно с ОЛАП-ом? Сделай БД для олтп, сделай бд для datawarehouse через ssis, сделай куб через datawarehouse, а не через изначальную БД — будет гораздо логичнее.
Ну и т.п. Критерий — проще. Макконел писал про нагрузку на интеллект. Чем проще нагрузка, тем круче жить. Чем более понятнее и тупее аспект приложения, тем выше шанс, что результирующий бизнес-функционал получится полнее и более восприимчивым к изменениям. Чем проще базовые методы и инварианты, тем круче и проще строить логику на уровне выше. И т.п.
Архитектор должен все это понимать. У вас похоже чувак (чуваки) грезят всемирной славой.
Таблица есть? пиши круд в хранимках.
Добавилось поле? Пиши поле в хранимке.
Трудно проводить регресс? Сделай юнит-тест.
Трудно сделать юнит-тест? Сделай легкий апи, который позволит написать автотест.
Сложно с ОЛАП-ом? Сделай БД для олтп, сделай бд для datawarehouse через ssis, сделай куб через datawarehouse, а не через изначальную БД — будет гораздо логичнее.
Ну и т.п. Критерий — проще. Макконел писал про нагрузку на интеллект. Чем проще нагрузка, тем круче жить. Чем более понятнее и тупее аспект приложения, тем выше шанс, что результирующий бизнес-функционал получится полнее и более восприимчивым к изменениям. Чем проще базовые методы и инварианты, тем круче и проще строить логику на уровне выше. И т.п.
Архитектор должен все это понимать. У вас похоже чувак (чуваки) грезят всемирной славой.
+1
Чувак, ты вогнал их в краску ) Просто — это не круто, это же ынтырпрайз :)
Тут нахерачено всего, что можно, даже отдельный редактор для управления метаданными. Но как я писал про абстракции, и тут с ними %опа — их уже over 900...000, и редактором можно подредактировать метаданные, но затем обязательно надо написать код, который будет тольковать эти метаданные, и действовать соответственно. И что самое обидное, теперь логику в коде не видно — он становится «if Metadata#42 exists & hardcoded_id = 42 then do some strange ops».
В общем, будем думать. 10x.
Тут нахерачено всего, что можно, даже отдельный редактор для управления метаданными. Но как я писал про абстракции, и тут с ними %опа — их уже over 900...000, и редактором можно подредактировать метаданные, но затем обязательно надо написать код, который будет тольковать эти метаданные, и действовать соответственно. И что самое обидное, теперь логику в коде не видно — он становится «if Metadata#42 exists & hardcoded_id = 42 then do some strange ops».
В общем, будем думать. 10x.
+1
Кстати, Илья, ты там писал когдато про CAB и use-case девелопмент) Развилось ли сие во что-нибудь на практике?
0
Может попробовать для каждого изменения БД генерировать события и сделать возможность легко вешать обработчики на события? Плюс: одна таблица в БД — один класс, только с помощью него можно менять эту таблицу. Все взаимосвязи запихнуть в обработчики событий и все? Никакой код не может менять данные в БД без генерации события, либо без обработчика события. Тогда можно относительно легко найти все взаимосвязи (чуть ли не автоматически) в коде.
PS: Не могли бы вы описать конкретный пример, типа «делали делали, а тут новое требование и все переделывать»?
PS: Не могли бы вы описать конкретный пример, типа «делали делали, а тут новое требование и все переделывать»?
+1
а что вы думаете про SOA, REST и тонкий клиент?
0
Много чего разного. А о чем конкретно вы бы хотели услышать? :)
Счас у нас в разработке — толстый клиент на Сильверлайт, который через REST тягает данные в виде вышеупомянутых DTO. По приборам все выглядит ок, посмотрим, как на самом деле выйдет.
Счас у нас в разработке — толстый клиент на Сильверлайт, который через REST тягает данные в виде вышеупомянутых DTO. По приборам все выглядит ок, посмотрим, как на самом деле выйдет.
0
почему бы не воспользоваться SOA (Service Oriented Architecture) для управления сложностью системы, REST для CRUD данных и тонкий клиент для быстрой передачи логики клиенту?
0
Да действительно, я не догадался. Крибле-крабле-бумс! Должно помочь, побежал настраивать.
Но есть проблема — нужна ваша помощь: что такое «быстрая передача логики клиенту»? Гугл не знает, я тоже.
Но есть проблема — нужна ваша помощь: что такое «быстрая передача логики клиенту»? Гугл не знает, я тоже.
0
ну вот вы тягаете постоянно логику от сервера клиенту, насколько я понял. тонкий клиент, можно генерить на сервере, а клиент его будет забирать из браузера.
0
*пользователь будет забирать клиент, через браузер
0
Мм… видимо, неправильно поняли. Логика никуда не ездит постоянно, только с сервера на клиент 1раз — в момент, когда клиент коннектится.
0
сколько раз у вас клиент конектится к серверу во время работы с данными?
0
Эмм. Давайте так определимся: есть две системы — продакшн и ресерч. Продакшн — старая быдлотрехзвенка (Толстый клиент и почти бесполезный сервер приложений — потому что обгадились писать транзакции в 2х звенке). Ресерч — это новая и прогрессивная, спроектированная мной (поддерживает толстый клиент на WPF/Silverligth и тонкий web). Соответственно,
Первая. Коннектится часто — работа через веб-сервис (_типа_ SOA, на самом деле — гуанокод на asmx в чистом виде). Но в процессер работы забирает только данные, никакой логики.
Вторая. Коннектится часто через REST и true SOA, аналогично, после старта передает только данные.
Первая. Коннектится часто — работа через веб-сервис (_типа_ SOA, на самом деле — гуанокод на asmx в чистом виде). Но в процессер работы забирает только данные, никакой логики.
Вторая. Коннектится часто через REST и true SOA, аналогично, после старта передает только данные.
0
silverlight, flex — это хорошо, конечно. но javascript мне кажется лучше, можно воспользоваться extjs для UI или подобными библиотеками и тогда будет возможно менять логику на ходу без перекомпиляции клиента или вообще в процессе работы, но последнее, конечно без правильного подхода приведет в тупик.
очень интересно, что вы всетаки определились с дальнейшим путем развития, но почему-то нигде не присутствует его описание.
я правильно понял, что вы увольняетесь с работы и собираетесь разрабатывать свою систему, а возможно и платформу?
очень интересно, что вы всетаки определились с дальнейшим путем развития, но почему-то нигде не присутствует его описание.
я правильно понял, что вы увольняетесь с работы и собираетесь разрабатывать свою систему, а возможно и платформу?
0
Мы обдумали и решили не брать javascript.
Во-первых, он достаточно ограничен. Во-вторых, нет желания заиметь гетерогенную среду, в то время как Silverlight — это подмножество «большого» .net фреймворка. И в-третьих, нет желания героически бороться с багами верстки и работы по-разному в разных браузерах. Мы не можем себе это позволить.
Нет, думаю, что не собираюсь развивать свою версию после увольнения — малоперспективно. Как я уже писал, это репутационный бизнес, и вклиниться туда со своей версией будет очень сложно. И что также грустно, программа — это полдела. В компании с полсотни человек заняты подготовкой данных для бизнеспроцесса: анализ предметной области, синтез процессов, выезд на места для изучения и т.п. Это гигабайты информации, собранные за много лет работы. Они уникальны сами по себе. Без них ничего не взлетит, или взлетит, но на малую высоту :) — так, карманная ERP для маленького еврейского свечного заводика.
Во-первых, он достаточно ограничен. Во-вторых, нет желания заиметь гетерогенную среду, в то время как Silverlight — это подмножество «большого» .net фреймворка. И в-третьих, нет желания героически бороться с багами верстки и работы по-разному в разных браузерах. Мы не можем себе это позволить.
Нет, думаю, что не собираюсь развивать свою версию после увольнения — малоперспективно. Как я уже писал, это репутационный бизнес, и вклиниться туда со своей версией будет очень сложно. И что также грустно, программа — это полдела. В компании с полсотни человек заняты подготовкой данных для бизнеспроцесса: анализ предметной области, синтез процессов, выезд на места для изучения и т.п. Это гигабайты информации, собранные за много лет работы. Они уникальны сами по себе. Без них ничего не взлетит, или взлетит, но на малую высоту :) — так, карманная ERP для маленького еврейского свечного заводика.
0
если вы не будете писать на нем редактор 3d или векторной графики, то вполне хороший язык. так же на нем есть хорошие библиотеки для создания UI, в том числе и промышленные для .net. проблемы верстки исчезают, при использовании правильных библиотек.
а что вы думаете по поводу рынка платформ для более узких задач, бизнес-процессы, которых почти везде одинаковы, за исключением небольших различий?
и еще один вопрос, вы с ФАВТа?
а что вы думаете по поводу рынка платформ для более узких задач, бизнес-процессы, которых почти везде одинаковы, за исключением небольших различий?
и еще один вопрос, вы с ФАВТа?
0
>> если вы не будете писать редактор
Он не многопоточный, он не умеет работать локально с файлами, он жрет память и тормозит. Для анимации и простых табличек — подойдет, дальше — никак. Silverlight в этом плане всяко лучше. Опять же, у меня есть жгучее желание остаться в одном и том же технологическом стеке — code reuse рулит.
>>проблемы верстки исчезают
Лучше их не иметь вовсе, чем иметь и потом забАрывать «правильными» библиотеками :)
>> а что вы думаете по поводу рынка платформ для более узких задач
Тут я вас огорчу. Я технический лидер, а не пресейл-инженер, и мало думаю по поводу рынка — повода не было, в основном :)
>>вы с ФАВТа?
Нет, я с РТФ. Давно известно, что на ФАВТе нет разработчиков, тем более архитекторов )
Он не многопоточный, он не умеет работать локально с файлами, он жрет память и тормозит. Для анимации и простых табличек — подойдет, дальше — никак. Silverlight в этом плане всяко лучше. Опять же, у меня есть жгучее желание остаться в одном и том же технологическом стеке — code reuse рулит.
>>проблемы верстки исчезают
Лучше их не иметь вовсе, чем иметь и потом забАрывать «правильными» библиотеками :)
>> а что вы думаете по поводу рынка платформ для более узких задач
Тут я вас огорчу. Я технический лидер, а не пресейл-инженер, и мало думаю по поводу рынка — повода не было, в основном :)
>>вы с ФАВТа?
Нет, я с РТФ. Давно известно, что на ФАВТе нет разработчиков, тем более архитекторов )
0
если вы знаете, о чем я, то очень интересно ваше мнение по поводу использования такого подхода
0
Ну я могу ответить «оправданно» или «не катит», но вы же мне не поверите без аргументов? :)
У нас а) нет культуры проектирования настоящих сервисов б) пока еще не догнали насчет того, что нужен orchestration. У нас — это как минимум, в компании, как максимум — в отрасли (конечно, встречаются и приятные исключения). Если из компании уйду я и еще кто-то, кто умеет вышеперечисленное, то такой проект загнется.
У нас а) нет культуры проектирования настоящих сервисов б) пока еще не догнали насчет того, что нужен orchestration. У нас — это как минимум, в компании, как максимум — в отрасли (конечно, встречаются и приятные исключения). Если из компании уйду я и еще кто-то, кто умеет вышеперечисленное, то такой проект загнется.
0
poprobyjte EMF (Eclipse Modelling Framework). reshaet kuchu problem
0
Microsoft codename «Oslo»
Microsoft codename «M»
Microsoft codename «Quadrant»
Microsoft codename «M»
Microsoft codename «Quadrant»
-1
1. Не готов в продакшн
2. Не готов в продакшн
3. Вы бы еще фотошоп присоветовали
2. Не готов в продакшн
3. Вы бы еще фотошоп присоветовали
0
а, так вам надо чтобы к послезавтра было всё готово?
тогда да, лучше воспользоваться классическими механизмами 40-летней давности
например проектированием информационных потоков, репликации и синхронизации независимых баз
тогда да, лучше воспользоваться классическими механизмами 40-летней давности
например проектированием информационных потоков, репликации и синхронизации независимых баз
-1
Нет, мне надо просто бюджет попилить, а там, глядишь, кто-нибудь сдохнет, как в притче про Ходжу Насреддина.
Вы на этих инструментах, которые написали, сами-то много проектов сделали? Или так, чисто за жизнь поп%здеть, написали?
Вы на этих инструментах, которые написали, сами-то много проектов сделали? Или так, чисто за жизнь поп%здеть, написали?
0
да не, это же инструменты будущего, а мы родом из прошлого :)
у нас всё проще…
«просто» не делаем бардак — вот и всё
а корни разработки восходят к такому продукту, как Centura Team Developer
у нас всё проще…
«просто» не делаем бардак — вот и всё
а корни разработки восходят к такому продукту, как Centura Team Developer
-1
:) Ok.
Бардак — это одно, и от него избавляться надо однозначно. Но даже если нет бардака, вот в чем суть: если разбивать приложение на слои, то все получается ок; но только это добавление/управление полями выходит типичным кросс-катом — распределено по всем слоям и плохо управляется из одной точки.
В АОП кросс-каты забарываются на ура, а вот существует ли аналог AOP для данных, непонятно. Приходится каждый раз писать свой аналог, причем какой-то кривой частный случай.
Бардак — это одно, и от него избавляться надо однозначно. Но даже если нет бардака, вот в чем суть: если разбивать приложение на слои, то все получается ок; но только это добавление/управление полями выходит типичным кросс-катом — распределено по всем слоям и плохо управляется из одной точки.
В АОП кросс-каты забарываются на ура, а вот существует ли аналог AOP для данных, непонятно. Приходится каждый раз писать свой аналог, причем какой-то кривой частный случай.
0
Sign up to leave a comment.
Ползучая гадость, или о проблемах с отдельно взятой БД отдельно взятого приложения