Когда я переходил на Postgres — ощутимых завязок на синтаксис не заметил — фактически все возможности MySQL прекрасно мапятся в Postgres. Есть несколько подводных камней, они обходимы. Во времена, когда пользовался MySQL вся логика была в приложении и сам MySQL действительно был как хранилище. В Postgres'е я развернулся по возможностям, тем более и цель перед собой такую поставил — плотнее изучить возможности баз. Недавно меня пригласили в один проект, где до моего прихода использовался MySQL — ощущение, наверно, сравнимое с тем, как если бы счастливого владельца BMW посадили за руль Таврии и попросили показать класс езды. Чего только стоит некаскадность триггеров в MySQL сводящая их роль к минимальной и грозящая неприятными сюрпризами и в то же время, посмотреть на возможности ORM Zend Framework — там реализована эмуляция триггеров! То есть спрос на эту функциональность есть, если её реализовали на уровне сервера приложений, где ей совсем, казалось бы, не место. Или невозможность одновременно использовать полнотекстовый поиск и транзакции. И так — куда ни копни. Пока не пользуешься — вроде и не нужно, но когда привык — уже никуда без этих возможностей.
Значительно проще, как с точки зрения программиста, так и с точки зрения планировщика, построение запросов, более компактное расположение данных — в отдельной таблице связанные записи могут быть очень разбросаны по дисковым страницам, в одном поле же, они хранятся на минимально необходимом количестве страниц, ещё и хранятся со сжатием, не нужен дополнительный индекс для выборки по ключевому полю и само ключевое поле для связки, меньше памяти нужно для построения плана запроса, меньше размывается кеш за счёт чтения не нужных в данный момент страниц при больших таблицах. Это так, навскидку — возможно ещё что-то не учёл или не знал
Иногда — нужно взять любой ценой — тогда побеждают монстры вроде Oracle, здесь не поспоришь. Иногда — приходится считать сколько «копеек» заплатить за фичу, тогда всё совсем не однозначно.
Например, горизонтально смасштабировать приложение на low-cost оборудовании — это однозначно не про Оракл или MS. При этом возможности Postgres — это не такая уж и наколенная поделка, если разобраться. Ряд интегрируемых в базу языков, таких как Python или R, развитая система типов, делающих Postgres гибридом реляционных и модных нынче NoSQL решений, позволяющая соединить плюсы обоих подходов.
Скажем, по моему субъективному мнению, Postgres на голову выше Firebird и иже с ним коммерческого Interbase по ряду возможностей (по крайней мере так было лет пять назад, когда я интересовался вопросом, и именно нужных мне возможностей).
Причём у них ещё и сроки дают по накопительной системе, что в перспективе с развитием технологий продления жизни и законодательного ограничения рождаемости создаст особый ограниченный кастовый режим существования для значительной части населения, если ничего не поменяется в их правоохранительной системе
Через массив было бы уместно опять же со спец-синтаксисом — как в Python'е или других языках — через ** или ему подобное. Но поскольку всё упирается в шаманство с парсером — вряд ли мы увидим оптимальные варианты…
«криминальное» — определяется не Вашими понятиями о Справедливости, а законами государства, которое не так уж и сложно, как показывает история, однажды превращается в тоталитарное, фашистское, фундаменталистское или какое там ещё и проливает реки крови только за одно подозрение или донос о неполиткорректности.
Вот Вы конечно можете сомневаться, но всё-таки это — действительно killer-feature.
Один только тип hstore стоит хорошей статьи на хабре — тип, превращающий поле в key-value хранилище, с операциями манипуляции над ключами как множествами и полноценной индексацией всего этого добра — из коробки.
Вот не приведу сейчас источник, но мне mysqli_* сватали именно ради большей производительности оного по сравнению с mysql_*. Что творится с производительностью в PDO — увы не в курсе, но PDO рекомендуют уже как серебряную пулю — мол под все базы всё стандартизировано (насколько это возможно) и соответственно «простая миграция, универсальные решения». Если разобраться, то я, например, так или иначе всё равно пользуюсь объектными обёртками. Думаю встроенная в систему «обёртка» должна быть лучше вылизана, чем отдельный код и в реализации на C — более продуктивна.
Если не забиндить — работать не будет. А если не заэскейпить — внешне не заметно, что что-то не так. До одного прекрасного момента (в идеале — до аудита кода, но в жизни обычно бывает очень не идеально).
prepared statements как минимум быстрее работают при прочих равных (эффективней задействуется механизм кеширования) и защищены от разного рода незапланированных внедрений в запрос. В итоге меньше кода (не надо никаких монстров экранирования и конкатенаций), всё чище и логичней, работа идёт быстрей и не будет очень неприятных сюрпризов в будущем (где там у какого поля тип поменялся — перепиши все запросы, где спешили и забыли заэкранировать — слили базу паролей).
С радиокнопками подтверждаю — они то теряются, то устанавливаются на первую. Причём только если клик по самой кнопке или выделение кнопки мышью. А вот клик по связанному лейбелу устанавливает кнопку нормально.
Но какое отношение комментарии имеют к тому, что предлагает система при наведении мыши? Вот если бы как-то это дело совместить — дать пользователям предлагать переводы и исправления
Например, горизонтально смасштабировать приложение на low-cost оборудовании — это однозначно не про Оракл или MS. При этом возможности Postgres — это не такая уж и наколенная поделка, если разобраться. Ряд интегрируемых в базу языков, таких как Python или R, развитая система типов, делающих Postgres гибридом реляционных и модных нынче NoSQL решений, позволяющая соединить плюсы обоих подходов.
Скажем, по моему субъективному мнению, Postgres на голову выше Firebird и иже с ним коммерческого Interbase по ряду возможностей (по крайней мере так было лет пять назад, когда я интересовался вопросом, и именно нужных мне возможностей).
Вот Вы конечно можете сомневаться, но всё-таки это — действительно killer-feature.
Один только тип hstore стоит хорошей статьи на хабре — тип, превращающий поле в key-value хранилище, с операциями манипуляции над ключами как множествами и полноценной индексацией всего этого добра — из коробки.