Ну это уже какие-то психологические проблемы.
Если у человека «Oracle головного мозга» — то тут и «code first» не поможет, он все равно сможет делать всякие штуки на стороне БД (только еще более костыльнее).
«Архитектура — база наше всё и от неё и пляшем» — я тоже против такой архитектуры.
Статья (насколько я ее понимаю) немного о другом — изолировать использование конкретной СУБД в каком-нибудь изолированном слое или микросервисе и использовать все ее ништяки, которые она предоставляет.
Ну тут из крайности в крайность получается ) В статье про бизнес-логику на стороне БД ничего не сказано, только про эффективную схему (констрейнты, ключи, параметры хранения). В том же самом Oracle сухое описание оператора CREATE TABLE занимает 20 стр., другие БД тоже не сильно отстают. Так почему этим не пользоваться.
На счет распределенных баз без схемы — например те же самые популярные (или только набирающие популярность) Cassandra, ClickHouse и Cockroach вполне себе поддерживают настоящие схемы.
А микросервисная архитектура наоборот позволяет использовать каждую СУБД на всю катушку в изолированных сервисах.
Согласен, с автоматизацией такого решения есть проблемы. Существует много всяких отдельных экстракторов кода из БД (DDL/DML), миграторов, дифферов, VCS, CI (чтобы была уверенность, что БД успешно собирается из исходников), но вот чтобы все это вместе заработало, чтобы можно было гибко настроить под свой конкретный flow — такого инструмента я пока не встречал.
Как я понял, это решение для нужд разработки, а можно было бы ее решить именно со стороны разработки?
Сделать baseline существующих метаданных с продовой базы (+ нужные данные, например справочники, т.к. для нужд разработки редко требуется весь объем данных прода), положить это все под контроль версий. Затем заставить научить разработчиков изменять базу миграциями (если этого до сих пор нет, или есть но не во всех командах). Т.о. можно будет быстро развернуть любое кол-во баз любой нужной версии.
Если будет интересно как у нас организована структура, SVN, выпуск версий, обновление клиентов и т.д. с учетом того что мы пишем фактически только на SQL и PL/SQL, то могу попробовать написать на эту тему статью
Сам раньше подумывал о неком «db specific ORM», где можно было бы создавать слой работы с данными посредством хранимых процедур, представлений и прочих специфичных для той или иной СУБД конструкций (воспользоваться преимуществами каждой из них), а затем этот слой (точнее объектную надстройку над ним) использовать в объектной модели, в бизнесс логики. И (как было замечено) когда мы сохраняем данные о клиенте в БД — это совершенно не значит, что все они будут вставлены в одну плоскую таблицу Clients, но сам бизнесс слой об этом ничего не знает, и логику хранения можно изменять как угодно без его ведома.
Но хочу добавить, что плюс бизнес логики на стороне приложении (а не в БД) это возможность более легкого и простого масштабирования (распараллеливания). И думаю многие разработчики и команды сознательно идут на шаг полного игнорирования всех фич выбранной СУБД, и забивают ее каким-либо ORM'ом. Да, можно потерять в скорости, но никто не мешает поставить еще одну (две, три ...) машины рядом в помощь. Проще и быстрее.
Как и было сказано в этой статье, все зависит от конкретного приложения (и только от него) и условий его разработки.
Если у человека «Oracle головного мозга» — то тут и «code first» не поможет, он все равно сможет делать всякие штуки на стороне БД (только еще более костыльнее).
Т.е. поддерживается только какая-та общая функциональность всех этих СУБД? (Без специфичных опций каждой СУБД)
А как же архитектура, code review и все такое?
Статья (насколько я ее понимаю) немного о другом — изолировать использование конкретной СУБД в каком-нибудь изолированном слое или микросервисе и использовать все ее ништяки, которые она предоставляет.
А микросервисная архитектура наоборот позволяет использовать каждую СУБД на всю катушку в изолированных сервисах.
Похоже на неудавшийся вброс :)
+1, судя по описанию работы, похоже как раз на кассандру
Думаю хранить конфиги норм, spring cloud config например тоже поддерживает github
Думаю этой логики не наберется и на 0.1% от общего объема
Сделать baseline существующих метаданных с продовой базы (+ нужные данные, например справочники, т.к. для нужд разработки редко требуется весь объем данных прода), положить это все под контроль версий. Затем
заставитьнаучить разработчиков изменять базу миграциями (если этого до сих пор нет, или есть но не во всех командах). Т.о. можно будет быстро развернуть любое кол-во баз любой нужной версии.Сам раньше подумывал о неком «db specific ORM», где можно было бы создавать слой работы с данными посредством хранимых процедур, представлений и прочих специфичных для той или иной СУБД конструкций (воспользоваться преимуществами каждой из них), а затем этот слой (точнее объектную надстройку над ним) использовать в объектной модели, в бизнесс логики. И (как было замечено) когда мы сохраняем данные о клиенте в БД — это совершенно не значит, что все они будут вставлены в одну плоскую таблицу Clients, но сам бизнесс слой об этом ничего не знает, и логику хранения можно изменять как угодно без его ведома.
Но хочу добавить, что плюс бизнес логики на стороне приложении (а не в БД) это возможность более легкого и простого масштабирования (распараллеливания). И думаю многие разработчики и команды сознательно идут на шаг полного игнорирования всех фич выбранной СУБД, и забивают ее каким-либо ORM'ом. Да, можно потерять в скорости, но никто не мешает поставить еще одну (две, три ...) машины рядом в помощь. Проще и быстрее.
Как и было сказано в этой статье, все зависит от конкретного приложения (и только от него) и условий его разработки.