В предыдущей части данной статьи было рассмотрено некоторое количество отличий следующих субд: MySQL, PostgreSQL, FireBird, SQLite. в результате “тестирования” мной было принято героическое решение не использовать FireBird, и дальнейший обзор будет вестись для 3 оставшихся субд.
возможно, в будущем будет прямое продолжение, включающее в себя также субд от Oracle и Microsoft, но пока я не нашёл “zip-нутых” версий данных дистрибутивов, а также способа «заставить» их работать в php.
что ж, осталось более-менее добить SELECT и составить запросы для остальных частей запроса: GROUP BY, ORDER BY и LIMIT.
ORDER BY сюрпризов не приподнёс.
с оператором LIMIT, в принципе, ничего экстраординарного тоже не было:
-- MySQL SELECT * FROM catalog LIMIT 1; SELECT * FROM catalog LIMIT 0, 1; SELECT * FROM catalog LIMIT 1 OFFSET 0; -- PostgreSQL SELECT * FROM catalog LIMIT 1; SELECT * FROM catalog LIMIT 1 OFFSET 0; -- SQLite SELECT * FROM catalog LIMIT 1; SELECT * FROM catalog LIMIT 0, 1; SELECT * FROM catalog LIMIT 1 OFFSET 0;
любители MySQL могут испытать некоторое недоумение, не найдя в PostgreSQL поддрежку конструкции LIMIT x, y. но, с другой стороны, конструкция LIMIT x OFFSET y является универсальной и, при желании, можно использовать её.
а вот GROUP BY приподнесла сюрприз:
SELECT * FROM catalog GROUP BY name;
конструкция прекрасно отработала в MySQL и SQLite, но была «выпленута» PostgreSQL с ошибкой «column “catalog.id” must appear in the GROUP BY clause or be used in an aggregate function». таким образом, чтобы заставить малыми потерями отработать группировку, запрос необходимо привести к такому виду:
SELECT * FROM catalog GROUP BY name, id;
т. е. все поля, участвующие в выборке, должны быть перечислены в GROUP BY. данное поведение меня удивило, но на одном из форумов я нашёл ответ “спеца” постгреса: «поведение является стандартным; MySQL в этом случае пытается возвратить хоть что-то. а для чего вообще здесь нужно использовать группировку?». очевидно, что этому человеку следовало бы познакомиться чуть подробнее с возможностями MySQL. на самом деле, в GROUP BY перечисляются поля, требующие группировки (очевидно, что для остальных полей она не требуется). но привыкнув к сложности постгреса, наверное тяжело себе представить, что какой-то MySQL, долгое время бывший аутсайдером, может предоставить столь потрясные средства для работы и элементарного удобства.
к разговору об удобствах: MySQL позволяет задавать кодировку для базы, таблицы и поля (что иногда бывает удобно). в PostgreSQL нельзя задать не только кодировку поля (что терпимо), но даже кодировку таблицы (что напряжно). в MySQL можно в любой момент изменить любую из кодировок, и ничего не порушится. в случае продвинутого постгреса придётся делать дамп базы, создавать новую базу с требуемой кодировкой и перезалить в новую базу ранее сохранённый дамп. если учесть, что у хостера база “выдаётся из коробки” уже с некоторой кодировкой, пользователю, при желании перевести сайт с CP1251 на UTF-8, придётся столкнуться с некоторыми неприятными моментами, вплоть до смены хостера (кто бы что не говорил, но постоянное перекодирование данных при передаче клиент-сервер-клиент не может не сказаться на % используемых ресурсов).
у кого-то может возникнуть вопрос: нафига вообще было выдавать столько буков? отвечаю: пришла мне в голову мысль изобрести велосипед и написа́ть некоторый “сглаживатель” для универсальной работы с различными субд. конечно, существуют монструазные PEAR DB, ADOdb, PDO etc., но для работы с каждым из этих средств придётся мириться, помимо усиленного напряжения мысли, с большим объёмом кода. в то время, как большинство операций сводится к созданию таблиц и простейших вставках/удалениях/обновлениях данных.
днём интернета
шоколадкой для работы мозга
коробочкой ароматного чая для бодрости
продлением хостинга на +1 месяц
Автор публикации
(Оценок пока нет)
Загрузка...
Классная капча!