Понедельник , 27 Март 2017
Как новичку заработать в интернете?
ДомойПубликациикраткое сравнение баз данных: MySQL, PostgreSQL, SQLite. Part 2

краткое сравнение баз данных: MySQL, PostgreSQL, SQLite. Part 2

СУБД: MySQL, PostgreSQL, SQLite

В предыдущей части данной статьи было рассмотрено некоторое количество отличий следующих субд: 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., но для работы с каждым из этих средств придётся мириться, помимо усиленного напряжения мысли, с большим объёмом кода. в то время, как большинство операций сводится к созданию таблиц и простейших вставках/удалениях/обновлениях данных.



Рейтинг: 0

Автор публикации

1 432
не в сети 5 часов

x64 (aka andi)

Комментарии: 2042Публикации: 308Регистрация: 02-04-2009
Так себеНеплохоХорошоЗамечательноСупер! (Оценок пока нет)
Загрузка...

Один комментарий

  1. Классная капча!

    Рейтинг: 0

Оставить комментарий

Ваш email не будет опубликован.Необходимы поля отмечены *

*

Добавьте изображение (jpg/gif/png)

Авторизация

Регистрация

Пароль не введен

Генерация пароля