Comments 17
Жаль, что Тейлор не подозревает о существовании более «взрослых» БД, нежели MySQL.
Нет, я ничего не имею против конкретно нее, она имеет место быть в жизни разработчиков, начальных разработчиков и тех у кого маленькие проектики, просто в PG реально возможностей больше. Да и прикипел что ли к ней все душой.
Как я Вас понимаю =) Я лет 10 назад после очередного марафона по оптимизации настроек и запросов в MySQL обнаружил что это недоразумение отказывается использовать выделенные ему 16 гигов оперативки и использует HDD (скажем спасибо TEXT типу колонок). В итоге психанул и перевел проект на PostgreSQL с минимальными изменениями в структуре и типах полей. В итоге мало того что все проблемы с нагрузкой испарились, так я еще и не настраивал в PG ничего кроме разрешенного объема памяти. Тогда еще были проблемы с производительностью COUNT(*), но проект все-равно работал намного быстрее чем MySQL. А потом я начал вспоминать универ и стандарт SQL со всеми его возможностями, которыми в MySQL и не пахло. В общем с того момента я зарекся использовать MySQL в проектах более чем сайт-каталог с небольшим количеством данных.
На сколько я понял — проблема с непопулярностью PostgreSQL в те времена была в основном потому что мало кто знал о нем и мало кто был способен адекватно использовать его возможности. Я вот, например, кайфовал от количества типов колонок и строгости типизации данных в сравнении с MySQL. А многие считают это проблемой или не понимают как это правильно использовать.
А еще больше меня удивляет скудность поддержки PostgreSQL в фреймворках и ORM даже сейчас.
В "те времена" — это когда?
PG традиционно считается более сложным в администрировании, одни его файерволы и вакумы чего стоят — неужели не настраивали?
Он вроде и олап кубы поддерживает через экстеншены… это почти уже как oracle, хотя с последним даже не работал никогда, но про кубы в нем слыхивал
Далекие времена PostgreSQL 9.1. Я тогда настройки делал по инструкциям. Магии как с настройками MySQL не припомню. Тем не менее около 2х лет проект работал без нареканий на БД. Что было после — не знаю.
Сейчас настройкой занимается специально обученный человек, так что не совсем в курсе насколько всё изменилось.
Мне казалось наибольшей сложностью перехода с MySQL на PostgreSQL для большинства было незнание стандартного SQL и привычка использовать нестандартные фишки MySQL. В добавок более строгая типизация не позволяла делать всякую фигню как в MySQL без явного приведения типов. А еще в PG foreign key уже тогда нормально работали в отличие от MySQL. Это как из песочницы вылезти в реальный мир.
А еще в PG нет вечного выбора между MyISAM и InnoDB.
Для меня наоборот после перехода на PG всё встало на свои места т.к. в универе был весьма толковый курс по стандартному SQL.
Ну mysql очень расслабляет, если на нем долго сидишь… вообще стандартный SQL со строгой типизацией знать полезно а то миграция проекта с mysql на postgres может вылиться в очень большую головную боль в рефакторинге 100500 запросов процедур и триггеров
Знать мало. Нужно применять активно, включить все настройки строгости, доступные в mysql
```php
$from = date('Y-m-01 00:00:00');
$to = date('Y-m-31 23:59:59');
```
и SQL-запрос в который передавались эти даты:
```SQL
select *
from activities
where timestamp between :from and :to
```
так вот такого г… в проекте было полно и что самое интересно этот код работал идеально, пока я не попытался переложить это на Postgres, там все валилось в тартарары, причем валилось не всегда, рандомно, периодически…
а дело было в том, что когда в месяце был 31 день — все было идеально, а когда в месяце было 28/29/30 дней были Exception-ы на уровне БД, т.к. Postgres валидировал дату и писал, что нет даты 2018-02-31 23:59:59, что она находится за пределами допустимых значений.
Поэтому зная это и другие нюансы БД подобных Postgres-у, ты уже не будешь писать такое, а будешь писать примерно такое:
```php
$from = date('Y-m-01 00:00:00');
$to = date('Y-m-t 23:59:59');
```
с одной стороны, если ты всю жизнь планируешь сидеть на MySQL / MariaDB, то возможно не стоит об этом запариваться об этой строгой типизации, лишняя морока и гемор. Особенно, если ты новичок.
Оно и в mysql бы не работало без включенного ALLOW_INVALID_DATE
Я вообще если честно не понимаю зачем вообще разрешать невалидные даты, какая была задумка у разработчиков MySQL когда они это придумывали? У меня нет идей как это можно использовать в продакшн..
Я понимаю вводить опции ускоряющие чтото за счет чего то другого, или опция которая увеличивает максимальную длину строки для group concat, тут ты сам решаешь что тебе важно или нет, в зависимости от ситуации, но опция разрешающая невалидные значения это высший пилотаж)))
Идея была включить обратную совместимость с предыдущими версиями mysql — на каждый чих не по стандарту(?), который там был, такой флаг сделали/ Апгрейдишь версию — всё падает, включаешь флаги — работает, постепенно убираешь из код странные вещи и отключаешь флаги. Правда, в некоторых дистрах/репах уже многие костыли включены и до изменения кода руки не доходят, если вообще осознаётся, что есть такой техдолг.
Понимаю боль автора. В larevel ядро жестко захардкожено и патчить что-то в нем — лютый ад.
Мало того при обновлении версии патчить нужно все заново.
В свое время патчил authorization когда еще не было socialite для входа через oAuth2.0, патчил логи так как monolog умел нужный мне провайдер а вот laravel нет. Патчил models для graphql. В общем жизнь боль.
Хорошо постепенно в laravel появилась поддержка всего этого из коробки.
Расширяем возможности миграций Laravel за счет Postgres