![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Реляционная модель и отгребание геморроя по сию пору
Я так понял, что когда придумывали реляционную модель данных и строили на ее основе СУБД, мысли о том, что базы развиваются вместе с программами и надо бы описать в теории процессы рефакторинга баз, не было ни у кого из отцов-основателей?
Ибо тупое сравнение двух баз и генерацию на основании этого скрипта перехода, или же написание скрипта вручную при каждом обновлении и реализацию системы обновления на основе этих скриптов никак нельзя назвать теоретически обоснованными решениями - это какая-то самодельщина, эмпирика на коленке склепанная.
PS: По-моему, той же самой болезнью страдают всевозможные OR-мапперы.
Обновили классы, перегенерили скрипты базы - идите вешайтесь при обновлениях у клиентов.
Исправили сначала базу, затем по ней сгенерили объекты - или объекты будут тупые как пробка, или же после каждой генерации их нужно будет править. Или же объекты будут генерится из шаблонов на аццко-птичьих языках, типа как жаба-классы из RelaxNG генерятся.
Если по хорошему, то система должна на основе анализа типов до и после рефакторинга принуждать разработчика делать корректный скрипт перехода или же генерировать его автоматом, если там что-нибудь тривиальное. Что в свою очередь выдвигает требование строгой увязки типов в программе и типов в БД.а там и до Haskell в качестве языка запросов недалеко
Ибо тупое сравнение двух баз и генерацию на основании этого скрипта перехода, или же написание скрипта вручную при каждом обновлении и реализацию системы обновления на основе этих скриптов никак нельзя назвать теоретически обоснованными решениями - это какая-то самодельщина, эмпирика на коленке склепанная.
PS: По-моему, той же самой болезнью страдают всевозможные OR-мапперы.
Обновили классы, перегенерили скрипты базы - идите вешайтесь при обновлениях у клиентов.
Исправили сначала базу, затем по ней сгенерили объекты - или объекты будут тупые как пробка, или же после каждой генерации их нужно будет править. Или же объекты будут генерится из шаблонов на аццко-птичьих языках, типа как жаба-классы из RelaxNG генерятся.
Если по хорошему, то система должна на основе анализа типов до и после рефакторинга принуждать разработчика делать корректный скрипт перехода или же генерировать его автоматом, если там что-нибудь тривиальное. Что в свою очередь выдвигает требование строгой увязки типов в программе и типов в БД.
no subject
no subject
no subject
no subject