Реляционная модель и отгребание геморроя по сию пору
Я так понял, что когда придумывали реляционную модель данных и строили на ее основе СУБД, мысли о том, что базы развиваются вместе с программами и надо бы описать в теории процессы рефакторинга баз, не было ни у кого из отцов-основателей?
Ибо тупое сравнение двух баз и генерацию на основании этого скрипта перехода, или же написание скрипта вручную при каждом обновлении и реализацию системы обновления на основе этих скриптов никак нельзя назвать теоретически обоснованными решениями - это какая-то самодельщина, эмпирика на коленке склепанная.
PS: По-моему, той же самой болезнью страдают всевозможные OR-мапперы.
Обновили классы, перегенерили скрипты базы - идите вешайтесь при обновлениях у клиентов.
Исправили сначала базу, затем по ней сгенерили объекты - или объекты будут тупые как пробка, или же после каждой генерации их нужно будет править. Или же объекты будут генерится из шаблонов на аццко-птичьих языках, типа как жаба-классы из RelaxNG генерятся.
Если по хорошему, то система должна на основе анализа типов до и после рефакторинга принуждать разработчика делать корректный скрипт перехода или же генерировать его автоматом, если там что-нибудь тривиальное. Что в свою очередь выдвигает требование строгой увязки типов в программе и типов в БД.а там и до Haskell в качестве языка запросов недалеко
Ибо тупое сравнение двух баз и генерацию на основании этого скрипта перехода, или же написание скрипта вручную при каждом обновлении и реализацию системы обновления на основе этих скриптов никак нельзя назвать теоретически обоснованными решениями - это какая-то самодельщина, эмпирика на коленке склепанная.
PS: По-моему, той же самой болезнью страдают всевозможные OR-мапперы.
Обновили классы, перегенерили скрипты базы - идите вешайтесь при обновлениях у клиентов.
Исправили сначала базу, затем по ней сгенерили объекты - или объекты будут тупые как пробка, или же после каждой генерации их нужно будет править. Или же объекты будут генерится из шаблонов на аццко-птичьих языках, типа как жаба-классы из RelaxNG генерятся.
Если по хорошему, то система должна на основе анализа типов до и после рефакторинга принуждать разработчика делать корректный скрипт перехода или же генерировать его автоматом, если там что-нибудь тривиальное. Что в свою очередь выдвигает требование строгой увязки типов в программе и типов в БД.
no subject
Это была совсем другая эпоха, доиндустриальная. Инженера Решали Задачи. Какой ещё "рефакторинг" в банковской КОБОЛ-программе? Слово только через 20 лет придумают, по совсем другому поводу.
Однако операторы изменения таблиц в станадрте SQL уже существуют.
> Ибо тупое сравнение двух баз и генерацию на основании этого скрипта перехода
Есть куча готовых программ для сравнения. Для "скрипта перехода" (эт как у Вас всё просто!) -- есть понятие (и куча реализаций) ETL.
> Обновили классы, перегенерили скрипты базы - идите вешайтесь при обновлениях у клиентов.
А как иначе? Обучать RDBMS рефакторингу во всех фреймворках всех языков?
Это вопрос инструмента. Вон сходите к Ефимову, заявите ему, что Жыдея говно без рефакторинга ORM.
> Что в свою очередь выдвигает требование строгой увязки типов в программе и типов в БД.
Всё-таки хотите обучить RDBMS всем языкам программирования?
> а там и до Haskell в качестве языка запросов
Правильно зачеркнули. Мысль плохая, непродуманная.
no subject
>Всё-таки хотите обучить RDBMS всем языкам программирования?
Нет, окопавшиеся в микрософте психи-хаскелисты перетащат в C# фичи хаскела, и встроят (уже встроили, блин) его в MSSQL. Причем выглядит это именно так, судя по последним фичам C# и тому, что хаскелл курят в исследовательских центрах микрософта:)
no subject
Насчёт умного вездесущего языка, были в начале 90-х т.н. Oracle 4GL, там Oracle Forms, Oracle Reports -- типа, на высокоинтегрированном PL/SQL можно было писать натуральный клиентский UI, в обычном бухгалтерском стиле. Однако рынок не принял монополии ни продавца, ни языка. Хаскеллисты -- это 1% программистов, гетто, и максимум дойдёт до 5%.
no subject
no subject
no subject
no subject
no subject
Недостижимый идеал....