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