Нужна ли переносимость, если выбрать postgresql

[ivanov77]

Приветствую.
Всякие цмс-ки и фреймворки прилагают кучу усилий чтобы код, работающий у них с базой, был переносимым между базами - написанным DBMS-agnostic way.
Так и я в своих проектах обычно делал, не использовал специфичных фич, только если уж совсем никак(но специально это документировал), всегда через Query билдеры и AR-ы.
Причина этого то, что работал только с mysql и при этом существовала всегда возможность что потребуется на практике перейти на "более серьезную" PostgreSql.
Но смотрю что в проектах посерьезнее(если смотреть вакансии) там изначально выбрали PostgreSql.
Ее я тоже последнее время изучал и вот думаю, стоит ли напрягаться и писать agnostic код чтобы перейти куда? Итак на постгресе. Не на mysql же с нее переходить.
Можно было бы кучу возможностей использовать, тот же полнотекстовый поиск, типы jsonb , массивов, timestampz, запросы с with, insert ... returning, ограничения CHECK и т.д.
Так что если кто пересекался с большим и серьезным проектом, где юзают postgresql, подскажите как в таких случаях обычно на фирмах поступают.

 

[c0dex]

@ivanov77, посерьезней это оракл, а постгр и муськ - один хрен. Где-то фич больше, где-то меньше.

 

[grigori]

База не меняется, только обновляется версия.
Серьезные проекты строятся по сервисной архитектуре. Это значит, что каждый маленький функционал - это отдельный небольшой проект, и под него выбирается та база данных, которая нужна. У меня сейчас одновременно mysql, постгрес и key-value storage. В другом проекте было штук 50 инстансов mysql, и несколько oracle. Если что-то изменилось - сервис переписывается, и можно написать на новом движке.

 

[fixxxer]

@ivanov77, СУБД в реальных проектах меняется примерно никогда.

 

[Adelf]

@fixxxer, ну меняют. но обычно это перенос некоторых данных на noSQL. так что смысла в DBMS-agnostic мало, действительно.

 

[fixxxer]

@Adelf, я имел ввиду РСУБД, каэш. Не, бывают клинические случаи типа Uber-а, с их переходом на pg и потом обратно на mysql, но это редкое исключение, и, конечно, там в любом случае никакой речи о db agnostic не было.

 

[ivanov77]

@ivanov77, СУБД в реальных проектах меняется примерно никогда.

Ну а если под новые требования не хватает возможностей предыдущей базы чтобы сделать нормально. Например вот эти схемы(как неймспейсы) что в postgres, они сразу решают кучу того что под mysql неудобно делать. Всякое индексирование по jsonb, полнотекстовый поиск, PostGis, очень это все может пригодиться, мало ли как проект станет развиваться.
Или ситуации когда с ростом объема данных выявляются бутылочные горлышки в базе, например из-за джойнов и того что mysql только вложенными циклами умеет джойнить. Проще было бы миграциями поднять структуру в другой базе и перекинуть данные, ничего не меняя в коде.

 

[флоппик]

индексирование по jsonb, полнотекстовый поиск, PostGis ...и ситуации когда с ростом объема данных выявляются бутылочные горлышки в базе, например из-за джойнов и того что mysql только вложенными циклами умеет джойнить

В таких случаях нужно сразу на MongoDB переходить. BECAUSE IT'S WEB SCALABLE.

 

[c0dex]

@ivanov77, есть N проектов, которые очень большие и работают на mysql, ты не находишь свои доводы немного преждевременными?

 

[michelle]

@c0dex, аналогично - есть N+1 проект, достаточно большой работает на постгресе. И что?

Сначала надо разобраться товарищу, какое из решений лучше всего подходит под данный проект. Сравнив все варианты, решить что оптимальнее использовать.

 

[ivanov77]

@ivanov77, есть N проектов, которые очень большие и работают на mysql, ты не находишь свои доводы немного преждевременными?

Да тема вообще не о mysql vs postgresql и я доводы вроде и не приводил особые, говорю же мне например пока - без разницы что за база, код у меня на yii2 и db agnostic, базу можно сменить.
А о том что раньше я не использовал к примеру INSERT ON DUBLICATE KEY UPDATE , не потому что не хотел а потому что такое не заработает на postgre.
Но посмотрев postgre увидел что у них есть INSERT ON CONFLICT.
И прям как совпадение, в самой последней версии yii2 они сейчас это добавили как ->upsert()
Но есть же еще и другие штуки, полезные, но отличные в мелочах, например case mysql и case postgresql

Вот вы в своих больших проектах использующих mysql, код работающий с бд пишете любой под mysql какой захотите?

 

[c0dex]

@michelle, еще раз, для тех кто в танке. Есть спец по PG? - пилите на PG. Нет спеца по PG? пилите на том, под что у вас есть хороший DBA.

Реальный переход с базы на базу требуется никогда.

 

[ivanov77]

Реальный переход с базы на базу требуется никогда.

Если он не нужен, то зачем тогда люди напрягаются, пишут билдеры, обертки?, вон в phptherightway об использовании абстракций над базами также упомянуто.

 

[WMix]

Если он не нужен, то зачем тогда люди напрягаются, пишут билдеры, обертки?, вон в phptherightway об использовании абстракций над базами также упомянуто.

чтоб иметь "абстракцию над базами" с точки зрения программы совершенно не важно как/где хратятся данные

 

[fixxxer]

Билдеры используют не для того, чтобы прыгать с базы на базу. Билдеры используют потому, что это удобно.

Как ты билдером сэмулируешь тот же jsonb с gin/gist-индексом в mysql или sqlite, интересно?

 

[c0dex]

@ivanov77, не надо верить всему, что написано в интернете, хотя вообще сайт тот хороший.

Ну это, обертки это одно, билдеры - немного другое.
Билдеры в частном случае делают построение запросов с условиями (например при фильтрации данных) более простой задачей с точки зрения соблюдения синтаксиса запросов.

Полной же абстракции достичь очень непросто.

 

[grigori]

такое ощущение, что чувак троллит - уже на 3й круг пошла тема, а он все копает

 

[AnrDaemon]

зачем тогда люди напрягаются, пишут билдеры, обертки?

Обрати внимание, абстракции пишут не "для БД", абстракции пишут НАД БД для программы.

Просто так удобнее работать. И, да, ни один билдер не универсален.

 

[ivanov77]

Просто так удобнее работать. И, да, ни один билдер не универсален.

Но все равно билдер выполняет в т.ч. ф-цию по абстракции над БД. Вон в доках к ларавэл:

Laravel's database query builder provides a convenient, fluent interface to creating and running database queries. It can be used to perform most database operations in your application and works on all supported database systems.

Насчет универсальности, то понятно, но например в популярных движках, джумла, друпал и т.д., у них же получилось что их код спокойно работает на разных БД, а функционалы там, учитывая модули, ого го.

 

[fixxxer]

Так мы тут про что говорим? Про

с большим и серьезным проектом, где юзают postgresql, подскажите как в таких случаях обычно на фирмах поступают

или про CMS-ки, для которых изначально стоит требование максимальной совместимости? (Кстати, большинство сторонних модулей drupal нормально работают только с mysql - просто никто не проверял).