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