metaclass: (Default)
metaclass ([personal profile] metaclass) wrote2008-01-25 03:05 pm

Реляционная модель и отгребание геморроя по сию пору

Я так понял, что когда придумывали реляционную модель данных и строили на ее основе СУБД, мысли о том, что базы развиваются вместе с программами и надо бы описать в теории процессы рефакторинга баз, не было ни у кого из отцов-основателей?

Ибо тупое сравнение двух баз и генерацию на основании этого скрипта перехода, или же написание скрипта вручную при каждом обновлении и реализацию системы обновления на основе этих скриптов никак нельзя назвать теоретически обоснованными решениями - это какая-то самодельщина, эмпирика на коленке склепанная.

PS: По-моему, той же самой болезнью страдают всевозможные OR-мапперы.
Обновили классы, перегенерили скрипты базы - идите вешайтесь при обновлениях у клиентов.
Исправили сначала базу, затем по ней сгенерили объекты - или объекты будут тупые как пробка, или же после каждой генерации их нужно будет править. Или же объекты будут генерится из шаблонов на аццко-птичьих языках, типа как жаба-классы из RelaxNG генерятся.

Если по хорошему, то система должна на основе анализа типов до и после рефакторинга принуждать разработчика делать корректный скрипт перехода или же генерировать его автоматом, если там что-нибудь тривиальное. Что в свою очередь выдвигает требование строгой увязки типов в программе и типов в БД. а там и до Haskell в качестве языка запросов недалеко

[identity profile] volodymir-k.livejournal.com 2008-01-25 01:35 pm (UTC)(link)
> когда придумывали реляционную модель данных и строили на ее основе СУБД,

Это была совсем другая эпоха, доиндустриальная. Инженера Решали Задачи. Какой ещё "рефакторинг" в банковской КОБОЛ-программе? Слово только через 20 лет придумают, по совсем другому поводу.

Однако операторы изменения таблиц в станадрте SQL уже существуют.

> Ибо тупое сравнение двух баз и генерацию на основании этого скрипта перехода

Есть куча готовых программ для сравнения. Для "скрипта перехода" (эт как у Вас всё просто!) -- есть понятие (и куча реализаций) ETL.

> Обновили классы, перегенерили скрипты базы - идите вешайтесь при обновлениях у клиентов.

А как иначе? Обучать RDBMS рефакторингу во всех фреймворках всех языков?
Это вопрос инструмента. Вон сходите к Ефимову, заявите ему, что Жыдея говно без рефакторинга ORM.

> Что в свою очередь выдвигает требование строгой увязки типов в программе и типов в БД.

Всё-таки хотите обучить RDBMS всем языкам программирования?

> а там и до Haskell в качестве языка запросов

Правильно зачеркнули. Мысль плохая, непродуманная.

[identity profile] metaclass.livejournal.com 2008-01-25 01:47 pm (UTC)(link)
Вот готовые программы для перехода все таки голову отъедают. На данный момент проще всего ручное ведение скриптов для обычных обновлений, а при глобальных идеологических изменениях наверно проще базу с нуля создать и данные перелить. Если там не 100 Гб данных, конечно, но тут уже ничего, кроме консилиума садистов-СУБД-проктологов не поможет.

>Всё-таки хотите обучить RDBMS всем языкам программирования?

Нет, окопавшиеся в микрософте психи-хаскелисты перетащат в C# фичи хаскела, и встроят (уже встроили, блин) его в MSSQL. Причем выглядит это именно так, судя по последним фичам C# и тому, что хаскелл курят в исследовательских центрах микрософта:)

[identity profile] volodymir-k.livejournal.com 2008-01-25 04:56 pm (UTC)(link)
- Какие реализации ETL Вы пробовали и почему они Вам не понравились?

Насчёт умного вездесущего языка, были в начале 90-х т.н. Oracle 4GL, там Oracle Forms, Oracle Reports -- типа, на высокоинтегрированном PL/SQL можно было писать натуральный клиентский UI, в обычном бухгалтерском стиле. Однако рынок не принял монополии ни продавца, ни языка. Хаскеллисты -- это 1% программистов, гетто, и максимум дойдёт до 5%.

[identity profile] alexdjachenko.livejournal.com 2008-01-25 05:08 pm (UTC)(link)
В My-Site-Framework, который я разрабатываю скорее для удовольствия и немножко для личных нужд, такое предусмотрено: по описанию формата данных в ORM, система может сгенерить скрипт для создания таблиц, а если для каждого поля указывать версию, с которой оно появилось, то будут создаваться и скрипты обновления. В принципе, до удаления и изменения формата полей здесь уже недалеко.

[identity profile] vp.livejournal.com 2008-01-25 09:54 pm (UTC)(link)
Поле.. Скрипты по полям - это середина 80х годов. Шизанутая база данных еще имеет цепочки триггеров, индексов, констреинов, хранимых процедур. Вопрос в том, как и чем автоматически модифицировать их, если каждый клиент находится на разном уровне развития базы данных. Тут кроме совершенно безумной помиси метаданных с информацией о структуре БД и еще фиг знает каких пауков и жаб никак не обойтись. И то будет вероятность, что скрипт на чем-то упадет и все придется отлаживать и применять руками, по кусочкам

[identity profile] alexdjachenko.livejournal.com 2008-01-28 12:27 pm (UTC)(link)
Каждый выбирает себе решение по вкусу. Индексы, тригеры и прочую лабуду так же можно обновлять сходным образом. Все неудобство всех этих рюшечек на стороне БД как раз в том, что они ухудшают совместимость с различными БД и усложняют параллельное отслеживание версий и обновлению БД.

[identity profile] vp.livejournal.com 2008-01-28 01:12 pm (UTC)(link)
Дык это ж жизнь. Понятное дело, что совместимости между БД становится 0. Ну а что ж делать?.. Иначе базами данных можно решать только самые-самые простейшие задачи, типа "по имени найти пароль" и все.

[identity profile] metaclass.livejournal.com 2008-01-28 01:22 pm (UTC)(link)
Не, сейчас модно делать по другому: в базе оставляется действительно минимальное хранилище данных, без особой логики. А вся логика запихивается на сервер приложений или соответствующий слой в программе-клиенте.

Недостижимый идеал....

[identity profile] dorogoj.livejournal.com 2008-01-25 05:34 pm (UTC)(link)
А если бы еще галушки прежде чем в рот лететь сами в сметану обмакивались... :-)