История изменений
Исправление resurtm, (текущая версия) :
Для опенсорсного/коробочного софта это очень критично.
Почему-же?
Ты писал когда-нибудь middleware, который нужно поддерживать годами? Нельзя ломать обратную совместимость, нельзя вообще ничего ломать.
Предположим мы пишем такой крупный проект, который поддерживает Oracle, PgSQL, MySQL и SQLite3. У нас есть 1000 клиентов по всему миру: 250 юзает наш продукт с Oracle, 250 с PgSQL, 250 с MySQL, 250 с SQLite3.
Я понимаю, что ты сейчас предложишь писать миграционные SQL для каждого типа СУБД (т.е. на каждое изменение в БД у нас будет 4 файла), но ты не понимаешь, что эту задачу можно намного упростить: можно писать только один класс миграции и сразу под все типы БД.
Хинт в том, что этот класс будет использовать методы абстрактного интерфейса для доступа к БД из нашего фреймворка/проекта/платформы. Дальше пояснять? :-)
Исходная версия resurtm, :
Для опенсорсного/коробочного софта это очень критично.
Почему-же?
Ты писал когда-нибудь middleware, который нужно поддерживать годами? Нельзя ломать обратную совместимость, нельзя вообще ничего ломать.
Предположим мы пишем такой крупный проект, который поддерживает Oracle, PgSQL, MySQL и SQLite3. У нас есть 1000 клиентов по всему миру: 250 юзает наш продукт с Oracle, 250 с PgSQL, 250 с MySQL, 250 с SQLite3.
Я понимаю, что ты сейчас предложишь писать миграционные SQL для каждого типа СУБД (т.е. на каждое изменение в БД у нас будет 4 файла), но ты не понимаешь, что эту задачу можно намного упростить: можно писать только один класс миграции и сразу под все типы БД.
Хинт в том, что этот класс будет использовать методы абстрактного интерфейс для доступа к БД. Дальше пояснять? :-)