Первая вызывает вполне конкретные проблемы. 1) Появлется тяжеловесный OR-маппинг + хранимые процедуры, абстрагирующие нас от таблиц. Это дофига тупого кода, который к тому же еще надо весь править при модификации объектов. Получаем в нагрузку тонну сильносвязного кода. 2) Апгрейд версии Одиссея, изменяющий схему БД - это _пляски_ с _бубном_. Мы должны корректно определить версию схемы БД (которая может быть любой их предыдущих), и накатить серию инкрементальных скриптов для апгрейда базы. Да, эти скрипты также надо править при внесении изменений в бизнес-объекты. 3) Сохраняя состояние на не диск, а черт-знает-куда, мы налетели на замену стандартных контролов сохранения/загрузки на свои собственные. Еще + дурацкая работа на ровном месте. Разумеется, так и будет, если эмулировать сервисы файловой системы на реляционой БД. Это глупость. 4) Система многопользовательская, с единым репозиторием, представьте, что будет, если один из клиентов проапгрейдит клиента. Что ему делать с разделяемой базой? Схему менять? А остальные клиенты, подключенные к БД - как? С ними что делать? 5) И главное - все это - ради чего? Чего хорошего мы получаем от БД в нашем случае - ЗАЧЕМ такой геморрой? Да просто так. :)
Решение - компоненты сериализуются в XML. Ни одной из перечисленных проблем не будет. Ни проблемы с версиями и апгрейдами (XML - тэгированный формат), ни контролов, ни тонны тупого кода.
Третья. VBA изначально вкручивали, чтобы съекономить время. Однако... Усилия по кастомизации дурацкого и плохо документированного ГУЯ VBA оказались чудовищны. Шесть инженеров работали полгода для решения этой задачи. В результате - пришлось просто скрыть все родные компоненты среды VBA, заменив их собственными - оперирующими терминами предметной области. Мелкая нашинковка на COM-классы - возникла оттуда же. Что осталось - так это редактор VBA, в котором автогенерированный код, и разметка в комментариях, которые нельзя править пользователю, смешан с пользоваетльским. От чего трейдеры плевались.
Надо было: сделать свой DSL, воспользовавшись генераторами парсеров, и свою среду разработки с отладчиком собрать на Qt + Scintilla. Трудозатраты были бы меньше в разы, а результат был бы на порядок лучше с точки зрения юзабилити.
Кривой бейсик состоящий их сплошных заплат сделать довольно тяжело. Слишком простая задача - делать DSL, для того чтобы сделать его криво. В этом совершенно ничего сложного нет, если знать, как это делается - с такими задачами наши студенты справляются. Могу описать по шагам, как это делать.
Да, с базой vs. файловая система понятно - ключевой момент, действительно, описан, в пункте 5 :). В текущем проекте мы имеем весь описанный геморрой с базой по полной программе, но понятно заради чего: счёт записям идёт на десятки миллионов.
Мне довелось участвовать в двух родственных коммерческих проектах, где простенький DSL в итоге превращался в монстроидный недо-бейсик. Теоретически этого можно избежать, если с самого начала проектировать правильно. Практически, однако, мне ещё не встречалось ни одного коммерческого проекта, в котором бы хоть что-нибудь с самого начала было спроектировано правильно. Хочется верить, что мне просто не везло :).
В изначальном посте я как-то упустил фразу про среду разработки. VBA, конечно, был бы в вашем случае правильным решением при подходе: "Вот вам, дорогие заказчики, набор COM-серверов, которые вы можете пользовать в своих скриптах. Вот вам подробная документация с примерами на VBA". Если вы должны дать заказчику не только DSL, но и DS-IDE, то расклад получается совсем другой.
Спасибо за комментарии и за наводку на Scintilla. Поставил себе Notepad++, играюсь :)
> Да, с базой vs. файловая система понятно - ключевой момент, действительно, описан, в пункте 5 :). В текущем проекте мы имеем весь описанный геморрой с базой по полной программе, но понятно заради чего: счёт записям идёт на десятки миллионов.
Я не знаю вашего случая, но мне кажется, и в вашем случае жизнь станет немного легче, если не увлекаться нормализацией базы. То есть, хранить информацию, по которой не предвидится поиск, в текстовых полях, в виде XML, штоб нарушала нафиг первую нормальную форму. Индескные поля, по которым идет поиск, можно задавать отдельно параметрами хранимых процедур.
1) Появлется тяжеловесный OR-маппинг + хранимые процедуры, абстрагирующие нас от таблиц. Это дофига тупого кода, который к тому же еще надо весь править при модификации объектов. Получаем в нагрузку тонну сильносвязного кода.
2) Апгрейд версии Одиссея, изменяющий схему БД - это _пляски_ с _бубном_. Мы должны корректно определить версию схемы БД (которая может быть любой их предыдущих), и накатить серию инкрементальных скриптов для апгрейда базы. Да, эти скрипты также надо править при внесении изменений в бизнес-объекты.
3) Сохраняя состояние на не диск, а черт-знает-куда, мы налетели на замену стандартных контролов сохранения/загрузки на свои собственные. Еще + дурацкая работа на ровном месте. Разумеется, так и будет, если эмулировать сервисы файловой системы на реляционой БД. Это глупость.
4) Система многопользовательская, с единым репозиторием, представьте, что будет, если один из клиентов проапгрейдит клиента. Что ему делать с разделяемой базой? Схему менять? А остальные клиенты, подключенные к БД - как? С ними что делать?
5) И главное - все это - ради чего? Чего хорошего мы получаем от БД в нашем случае - ЗАЧЕМ такой геморрой? Да просто так. :)
Решение - компоненты сериализуются в XML. Ни одной из перечисленных проблем не будет. Ни проблемы с версиями и апгрейдами (XML - тэгированный формат), ни контролов, ни тонны тупого кода.
Третья. VBA изначально вкручивали, чтобы съекономить время. Однако... Усилия по кастомизации дурацкого и плохо документированного ГУЯ VBA оказались чудовищны. Шесть инженеров работали полгода для решения этой задачи. В результате - пришлось просто скрыть все родные компоненты среды VBA, заменив их собственными - оперирующими терминами предметной области. Мелкая нашинковка на COM-классы - возникла оттуда же. Что осталось - так это редактор VBA, в котором автогенерированный код, и разметка в комментариях, которые нельзя править пользователю, смешан с пользоваетльским. От чего трейдеры плевались.
Надо было: сделать свой DSL, воспользовавшись генераторами парсеров, и свою среду разработки с отладчиком собрать на Qt + Scintilla. Трудозатраты были бы меньше в разы, а результат был бы на порядок лучше с точки зрения юзабилити.
Кривой бейсик состоящий их сплошных заплат сделать довольно тяжело. Слишком простая задача - делать DSL, для того чтобы сделать его криво. В этом совершенно ничего сложного нет, если знать, как это делается - с такими задачами наши студенты справляются. Могу описать по шагам, как это делать.
Reply
Мне довелось участвовать в двух родственных коммерческих проектах, где простенький DSL в итоге превращался в монстроидный недо-бейсик. Теоретически этого можно избежать, если с самого начала проектировать правильно. Практически, однако, мне ещё не встречалось ни одного коммерческого проекта, в котором бы хоть что-нибудь с самого начала было спроектировано правильно. Хочется верить, что мне просто не везло :).
В изначальном посте я как-то упустил фразу про среду разработки. VBA, конечно, был бы в вашем случае правильным решением при подходе: "Вот вам, дорогие заказчики, набор COM-серверов, которые вы можете пользовать в своих скриптах. Вот вам подробная документация с примерами на VBA". Если вы должны дать заказчику не только DSL, но и DS-IDE, то расклад получается совсем другой.
Спасибо за комментарии и за наводку на Scintilla. Поставил себе Notepad++, играюсь :)
Reply
Я не знаю вашего случая, но мне кажется, и в вашем случае жизнь станет немного легче, если не увлекаться нормализацией базы. То есть, хранить информацию, по которой не предвидится поиск, в текстовых полях, в виде XML, штоб нарушала нафиг первую нормальную форму. Индескные поля, по которым идет поиск, можно задавать отдельно параметрами хранимых процедур.
Reply
Leave a comment