Сравнение СУБД

Итак, буду равнять MySQL 5.1 PostgreSQL 8.3(4) M$SQL 2000, Linter 6.1 и ORACLE 10.
Собственно, всё, что знаю по возможностям.
Параметы по группам:
0)Типы данных
1)Базовое: ключи и ограничения по схемам
2) Индексы и специальные фичи для скорости -кластеры, бит-индексы и т. п.
3)Полнотекстовый поиск
4)Доступ
5)Вьюхипростые , материальные, временные таблицы
6)Процедуры/функции
7)Транзакции
8)Распределённые запросы, логика и репликация

9)Безопасность и шифрование
10)Работа с иерархиями,WITH ,арегаты
11)Логическое разделение структуры(пакеты, схемы, бд, области видимости и
пр)
12) Аналитические функции на запросах
13) Поддержка разных ОС
14)Поддержка основных кодировок
15)Возможности настройки и доработки под свои нужды, написание своего
функционала
16)Прочие возможности

0) Сравнение СУБД по типам данных

MySQL M$SQL Linter ORACLE
Тип данных PostgreSQL8.3(4)
5.1 200х 6.1 10
INT 5 5 5 5 5
FLOAT 5 5 5 5 5
DECIMAL 5 5 5 4 5
SIGNED/ UNSIGNED 5 1 1 0 5
BIT 5 5 3 5 5
BOOLEAN 5 5 5 5 5
ENUM 4 5 0 0 4
SET 5 0 0 0 3
CHAR 5 5 5 5 5
VARCHAR 5 5 5 5 5
TEXT 5 5 5 5 5
BINARY 5 5 5 5 5
DATE&TIME 3 5 5 5 5
TIMESTAMP 3 5 5 5 5
DATE|TIME 3 5 5 5 3
IP 0 4 0 0 3
UUID 0 4 5 0 5
GEOMETRY 1 4 5 5 3
GEOGRAPHY 1 4 5 5 3
XML 0 4 5 0 5
Возможность встроить в
0 5 0 2 4
систему свой тип(не домен)
Структуры 0 5 3 1 5
Массивы 0 5 1 1 5

настроение: В спешке

Метки: сравнениеСУБД

1)Базовое: ключи и ограничения по

схемам
1)Внешние ключи - ограничения- ссылки на первичные ключи других таблиц.
2)Правила - запрос-реакция, который выполняется в перед анализом запроса
ещё до его выполнения.
3)Проверки - задаваемые для таблиц условия вставки или модификации значений.
Если вставляемая запись не подошла под условия - возвращается ошибка и
запись не вставляется.
4)Домены - псевдотипы, основанные на существующих типах, но со своими
ограничениями.
5)Триггеры - Хранимые на сервере последовательности команд, выполняющиеся по
типу
реакции на раздражение перед или после операции на вставку, удаление,
модификацию,
или срабатывающие по таймеру.

Ограничения целостности MySQL PostgreSQL8.3(4) M$SQL Linter ORACLE

5.1 200х 6.1 10
5 5 5 5 5
Первичные ключи
Внешние ключи 3 5 5 5 5
Индексы уникальности 5 5 5 5 5
Правила 0 5 5 5 5
Проверки 0 5 5 5 5
Домены 0 5 5 5 5
Триггеры 3 5 5 5 5
Последовательности и
4 5 2 5 5
автоинкремент

Метки: сравнениеСУБД

2) Индексы и специальные фичи для

скорости -кластеры, бит-индекс
Итак, сперва пояснения
1)BTREE - индекс, использующий алгоритм бинарного дерева поиска.
Используют все мало мальски СУБД. Оптимален, когда записей много, выборка
небольшая,
а индексируемые значения редко совпадают.
2)HASH - индексы используют для определения адреса данных их хэш. Оптимален
для средних
таблиц, к которым поступает очень много запросов на выборку и очень редко
на
модификацию.Неоптимальны для больших таблиц(хэш будет повторяться), и
особенно
таблиц с частым обновлением(запись должна быть строго в определённой
позиции)
3) BITMAP - Индекс по бит-картам. Используется для столбцов, имеющих
небольшое
количество часто повторяющихся значений когда выборка затрагивает
значительную
часть таблицы. (например, выбор всех мужчин или женщин)
4)GiST - конструктор индексов для произвольных типов данных. Например, XML
или сложных
геометрических объектов, для которых нет других аналогов индексирования.
Производительность сильно зависит от реализации и от запросов.
5)GIN - обратный индекс, хранит ключи и список ссылок на значения, в которых
ключи
встречаются. Используется для полнотекстовго поиска и сходных задач.
6) Функциональные индексы используются, когда надо выбирать записи,
сравнивая не по значениям, а по функциям от этих значений.
7) Кластерные индексы - индексы по которым упорядочиваются данные в таблице,

используются при частых выборках из больших нечасто обновляемых таблиц.

При наличии кластерного индекса строки таблицы физически
хранятся в заданном порядке и непосредственно связаны с элементами
индекса, благодаря
чему значительно ускоряется доступ к данным при использовании запросов,
использующих
данный индекс.
8)Частичный индекс - индекс, позволяющий задавать условия для индексации вида
WHERE.
 Позволяет строить оптимизирующий индекс для часто выполняющегося одного
конкретного
запроса с незначительными вариациями. Плюс имеется экономия места. Записи,
не
попадающие в условие - не индексируются.
9) Задание порядка индекса позволяет оптимизировать выполнение запросов,
которые зависят
от порядка индексируемого значения. Например, если выбираем несколько
максимальных
значений в определённом порядке.

MySQL M$SQL Linter ORACLE

Возможности PostgreSQL8.3(4)
5.1 200х 6.1 10
Обычный индекс BTREE 5 5 5 5 5
HASH 5 5 0 * 5
BITMAP 0 2 0 * 5
GIS 0 4 0 * 3
GIN 2 5 0 * 4
Функциональные индексы 1 5 * * 5
Кластеризация индексов * 5 4 * 5
Частичные индексы 1 4 4 * 5
Прямой и обратный порядок
5 5 5 * 4
индексов

Метки: сравнениеСУБД

3)Полнотекстовый поиск
1) Поддержка юникода
2) Простота применения. Поддержка другой функциональности, одновременно с
полнотекстовым поиском
3) Поиск по фразе
4) Учёт расстояния. Поиск с учётом расстояния между словами
5) Мультисловарики.Использования нескольких словарей
6) Типы индексирования чем больше типов индексов, пригодных для полнотекста, тем
лучше.
7) Поиск в LOB, распознавание различных документов pdf/exel/doc и т.п.

MySQL M$SQL Linter ORACLE

функциональность PostgreSQL8.3(4)
5.1 200х 6.1 10
1) Поддержка юникода 4 5 5 3 5
2) Простота
0 5 4 5 5
применения.
3) Поиск по фразе 0 1 3 5 5
4) Учёт расстояния. 0 0 * 5 *
5) Мультисловарики. * 5 * 5 5
6) Типы
3 5 3 3 4
индексирования
7) Поиск в LOB 0 0 * 5 5

Метки: сравнениеСУБД

4) Доступ
Пояснения, куда же без них
0) Мандатные политики уровня доступа, когда каждому пользователю
присваивается балл,
выше которого доступ к данным закрыт. Удобно не всегда, особенно, когда
надо хранить
информацию сильно разграниченную по группам доступа. Мне такая модель не
нравится.
1) Возможность задать привилегии на уровне пользователя, баллом отмечается
широта возможностей, например, подключение с определённых машин и т.п.
2) Система ролей позволяет единожды назначить набор привилегий для роли и
в дальнейшем уже назначать одну роль, а не кучу привилегий. Резко
упрощает администрирование, особеннно, когда много пользователей
3) Политики безопасности - более гибкая штука, чем механизм привилегий,
например, можно разрешить пользователю обновлять строго 2 столбца в
определённой таблице одновременно. Может быть, это кому-то и нужно.
Пока не применял.
4) Ограничения по данным жизненно необходимы. Степени тут такие:
0 - смотри чего хочешь, защитить данные нельзя
1 - Регулируется доступ к таблицам
2 - Регулируется доступ к таблицам до уровня столбцов
3 - 2+ есть вьюхи и процедуры
4 - 3+ к ним тоже регулируется доступ+ можно полностью запретить
смотреть таблицы
5 - Полноценный доступ на уровне строки
5) Ограничения по структуре
0 - можно всё смотреть,выполнять и т. п, ничего сделать нельзя
1 - Пользователю можно запретить менять структуру, но он её видит
2 - 1+ на свой страх и риск можно доработать напильником, но ограничено
3 - Пользователю можно закрыть структуру, но путём доработки напильником
4 - Структура закрывается, но виден список объектов
5 - 4+ он и списка объектов не видит

MySQL M$SQL Linter ORACLE

Возможности PostgreSQL8.3(4)
5.1 200х 6.1 10
Мандатные политики 0 0 3 5 5
Пользователи 5 4 5 5 5
Роли 0 4 5 5 5
Политики безопасности 3 1 5 5
Ограничения по данным 4 4 4 5 5
Ограничения по
5 3 5 5 5
структуре

Метки: сравнениеСУБД

5) Сравнение СУБД Средства упрощения

запросов (вьюхи, SQL фичи)
Пояснения
1) Типы таблиц по назначению, по идее, неплохая технология. Позволяет
максимально быстро выполнять
определённый тип операций. Не подходит в том случае, когда нужно выполнять
ОДНОВРЕМЕННО
эти операции над одними и теми же таблицами.
2) Временные таблицы позволяют ускорять выполнение особо тяжёлых запросов в
случае, если надо
многократно применять их результат в сеансе.
3) Временные таблицы с хранимой структурой + к пункту 2 позволяют не
создавать каждый раз временную
таблицу для каждого сеанса. Таблица уже есть, а вот данных нет. Данные
удаляются с завершением
сеанса .
4) Представление - оттранслированный запрос, хранящийся на СУБД. Пользователь
видит его как
таблицу. Ускоряет запросы за счёт предварительного разбора. Позволяет
скрыть реальную
структуру БД.
5) Матпредставления полезны в случае очень тяжёлых запросов к большим очень
редкообновляемым
таблицам. Использовать с осторожностью. Самописные таблицы функционалов
намного гибче.
6)Табличные функции - функции к которым можно обращаться как к таблицам.
Помогает, если нужна
особо изощрённая выборка данных, где SQL не помогает или неимоверно
тормозит.
7)Условные приспособления в запросах. Гибкость языка предполагает наличие
всяких вкусностей и
конструкций. Жизненно необходимо.
8)Без подзапросов не решается целый класс задач. Если этого нет - меняйте
СУБД.
9)UPDATE FROM Обновление таблицы из нескольких таблиц одним запросом.
10) Кластер из нескольких таблиц - сомнительная технология, легко заменяемая
денормализованной
таблицой с упорядочиванием по индексу. Делается в случае очень частых
выполнений строго
определённых запросов к нескольким таблицам. При этом замедляются ВСЕ
остальные операции.
11)UPSERT/MERGE необходимо если стоит задача запихнуть результат выборки в
другую таблицу с
заменой НЕКОТОРЫХ предыдущих значений, УЖЕ имеющихся в этой другой
таблице.
12) Временные объекты позволяют в рамках сессии значительно помочь
планировщику
при ОЧЕНЬ сложных выборках. Подсказки планировщику становятся как
правило ненужными.
13) Подсказки планировщику - сомнительная технология, позволяющая
разработчикам СУБД
забить болт на оптимизацию планировщика. Иногда в самых крайних случаях
позволяет
пользователям СУБД обойти ошибки разработчиков СУБД.
14) Партицирование таблиц - иногда очень нужная штука для очень больших
таблиц.
Бывают ситуации, что разделение таблиц ускоряют запросы на несколько
порядков

MySQL M$SQL Linter ORACLE

Возможности PostgreSQL8.3(4)
5.1 200х 6.1 10
Типы таблиц по назначению 3 0 0 * 0
Временные таблицы(базовые) 5 5 5 * 5
Временные таблицы с
2 0 5 * 5
хранимой структурой
Представления 1 3 5 5 5
Матпредставления 1 1 5 1 5
Табличные функции 0 5 3 4 5
Условные приспособления в
запросах (CASE,IFNULL и 5 3 5 3 5
т.п.)
Подзапросы 5 5 5 5 5
UPDATE FROM 5 5 5 5 5
Кластер из нескольких таблиц 2 2 2 2 5
UPSERT/MERGE 5 0 5 5 5
Временные представления,
0 5 0 * *
последовательности
Подсказки планировщику 0 0 0 4 5
Партицирование таблиц 4 3 4 * 5

Метки: сравнениеСУБД

6)Процедуры/функции
1)Процедуры хранимые - для сложной обработки данных с полным управлением
транзакциями внутри процедуры, например, бухгалтерские проводки
2)Функции хранимые - Для сложных отчётов, например, аналитических
3)Поддержка разных языков для процедур и функций
4)UDF на одном языке
5)UDF на разных языках
6)Добавление, переопределение любых операторов и функций
7)Параметры-программы - например, я передал исходник, в качестве параметра ХП
и он выполняется на
стороне сервера. Никогда не использовал.
8)Подготовленные выражения - ускоряют многократное выполнение похожих
запросов
9)Переменные в пределах сессии. Нужная для пыхеров вещь если логика
достаточно сложная.

MySQL M$SQL Linter ORACLE

Возможности PostgreSQL8.3(4)
5.1 200х 6.1 10
Процедуры хранимые 5 0 5 5 5
Функции хранимые 3 5 4 4 5
Языки ХП 0 5 0 0 3
UDF 5 5 5 5 5
UDF на разных языках 5 5 5 * 5
Переопределяемые
0 5 0 * *
операторы, функции
Параметры-программы 0 5 0 0 0
Подготовленные выражения 4 3 5 5 5
Переменные сессии 4 3 5 * 4

Метки: сравнениеСУБД

7) Транзакции и блокировки
1)Версионный механизм позволяет увеличить производительность на высоких
нагрузках,
для каждой транзакции создаётся свой снимок базы данных
2)Табличные блокировки - позволяет гарантировать, что таблицу не меняют.
Избегать использования.
3)Блокировки на уровне строк Ползволяет гарантировать, что строку не меняют.
4)Отсутствие эскалации блокировок. Эскалация увеличивает область блокировки,
и вероятность взаимоблокировок.
5)Механизм отлова взаимоблокировок. Без этого механизма можно считать, что
транзакциями лучше не пользоваться, иначе БД может встать.
6)DDL внутри транзакций - Очень полезно при тестировании, восстановления и
т.п.
7)Транзакция в рамках процедуры - иногда очень необходимая вещь
8)Автономная транзакция используется например для независимой обработки
данных
или для логгирования.
9)Точки сохранения используется для тяжёлых транзакций, чтоб не откатываться
целиком.
10) Протокол блокировок уровня колонки - не использовал, т.к. этот механизм
часто
требует установки модулей и не контролируется СУБД до конца. Зато
позволяет
ОЧЕНЬ эффективно строить очереди/стеки обслуживания

MySQL M$SQL Linter ORACLE

Возможности PostgreSQL8.3
5.1 200х 6.1 10
Версионный механизм 3 5 3 5 5
Табличные блокировки 5 5 5 5 5
Блокировки на уровне строк 3 5 2 5 5
Без эскалации блокировок 1 5 4 5 5
отлов взаимоблокировок 5 5 5 5 5
DDL внутри транзакций 0 5 0 0 0
Транзакция в рамках
3 5 5 5 5
процедуры
Автономная транзакция 0 0 * * 5
Точки сохранения 0 4 5 5 5
Протокол блокировок уровня
0 5 0 0 5
колонки

Метки: сравнениеСУБД

8)Распределённые запросы, логика и

репликация
1)dblink Возможность выполнения запросов на другом сервере этой же СУБД
2)Гетерогенные запросы. Возможность связываться с другими СУБД а не только с родной.
3)Лог транзакций - возможность асинхронной репликации ведущий - много ведомых из
коробки
4)Сервер горячего резерва - очень нужная штука.
Очень важная вещь мультимастер репликация. Это когда есть несколько баз, при
изменении
любой из которых изменения синхронизируются автоматически.
5)Синхронный мультимастер - режим реального времени
6)Асинхронный мультимастер- возможность переноса изменений на дискетках и
проигрывания
скриптов на других серверах с очень плохой связью
7)Распределённые транзакции - полезная вещь, когда у вас несколько серверов и ваши
транзакции
должны или выполниться на всех серверах, или не выполниться ни на одном.
 MySQL M$SQL Linter ORACLE
функциональность PostgreSQL8.3(4)
5.1 200х 6.1 10
1)dblink 2 5 5 5 5
2)Гетерогенные запросы. 0 3 4 5 5
3)Лог транзакций 1 4 5 5 5
4)Сервер горячего резерва 1 4 5 5 5
5)Синхронный
* 2 3 5 5
мультимастер
6)Асинхронный
1 1 4 5 5
мультимастер
7)Распределённые
* 3 3 4 5
транзакции

Метки: сравнениеСУБД

10)Работа с иерархиями,WITH ,арегаты,

табличные плагины
Итак, небольшое пояснение.
На моей практике мне приходилось бодаться со следующими вещами
1) Работа с иерархиями типа id, parent_id. Поверьте, если в базе есть
встроенные
фичи для работы с такими штуками - это хорошо. И у постгре и у mssql есть
аналоги ltree, что тоже
хорошо. А вот у мускуля нет ничего - это плохо.
2) with - конструктор табличных выражений,каждое из которых выполняется в
пределах SQL выборки,
не более одного раза, помогающее упростить и ускорить некоторые запросы.

3) Агрегатные функции типа SUM, COUNT и прочее. Чем их больше - тем лучше.
4) Самописные агрегаты - пользоваться не приходилось, но в трудной ситуации
не лишнее.
5) Встроенные табличные полезняшки, например CROSSTAB или PIVOT бывают
совсем нелишние,
когда надо например придать результатам определённую форму.

MySQL M$SQL Linter ORACLE

Функция PostgreSQL8.3(4)
5.1 200х 6.1 10
Работа с иерархиями 0 5 4 5 5
with 0 4 4 4 4
Агрегатные функции 5 5 5 5 5
Самописные агрегаты 0 4 3 * 5
Встроенные табличные 0 4 4 * 5
полезняшки

настроение: Продуктивное

Метки: сравнениеСУБД

11)Логическое разделение
структуры(пакеты, схемы, бд, и т.п.)
1) БД - возможность держать несколько баз на одном сервере
2) Схемы - группы объектов одной базы по назначению.
3) Пакеты - группы хранимых процедур в зависимости от логики приложения
4) Запросы к другим серверам СУБД - возможность распределить логику по разным
серверам СУБД.
5) Табличные пространства - позволяют распределять нагрузки, вынося объекты в разные
каталоги,
на разные диски. Иногда этим можно облегчить резервирование.
6)Переменные сессии переменные, сохраняющиеся только в период соединения,
Контекст даёт возможность задавать значения по умолчанию для различных групп и
пользователей.

MySQL M$SQL Linter ORACLE

Функция PostgreSQL8.3(4)
5.1 200х 6.1 10
БД 5 5 5 5 *
схемы 1 5 4 * 3
Пакеты 0 0 0 0 5
Запросы к другим
0 4 * 5 5
серверам СУБД
Табличные пространства 2 5 5 * 5
Переменные сессии,
3 5 3 * 5
контекст

Метки: сравнениеСУБД

Комментариев: 1

12) аналитические функции часть 1 из 3

Функции ранжирования позволяют получать ранг(характеристическое число)
всей выборки или её части(окна).
Позволяют радикально, на много порядков ускорить целый класс SQL запросов.
Число 5 означает полную штатную реализацию. Промежуточные значения означает
бубен,
который разный для каждой из СУБД. Из таблицы видно, что товарищи из Редмонда
сделали
реализацию типа "на, отвали!". При этом БЕСПЛАТНАЯ(!) СУБД PostgreSQL
предлагает чуть ли не
оракловский набор функций ранжирования, за что ребятам огромное уважение. У
ребят из города
Воронежа не всё в порядке в Датском королевстве, то бишь, в доке. По слухам,
функции есть,
но где их описание, сколько их и какие - молчание, ну да ладно, потом
разберусь и впишу
недостающие звенья. Некоторые определения настолько непонятные, что были
просто скопированы,
и чуть позже будут переведены на разговорный язык.
Итак, опишем поподробнее назначение функций ранжирования:
row_number() - выдаёт номер строки.
rank() - ранжирование по колонке, в качестве ранга выдаётся
значение столбца.
dense_rank() - ранжирование по колонке, но с ОТНОСИТЕЛЬНЫМ рангом, т.е., в
отличии
от rank() - без дырок в нумерации.
percent_rank()- ранг в процентах

ratio_to_report() - процент от суммы всех значений колонки

cume_dist() - относительная позиция строки в группе
ntile() - разбивает записи на указанное количество групп.
lag() - значения предыдущих строк
lead()- значения последующих строк
first_value() Первое значение в группе
last_value() Последнее значение в группе
nth_value() определённое конкретное значение в группе,расширенный эквивалент
first_value() и last_value()

MySQL M$SQL Linter ORACLE

Функция PostgreSQL8.3(4)
5.1 200х 6.1 10
row_number() 2 5 5 5 5
rank() 0 5 5 5 5
dense_rank() 0 5 5 5 5
percent_rank() 0 5 0 2 5
RATIO_TO_REPORT() 0 4 0 4 5
cume_dist() 0 5 0 * 5
ntile(num_buckets integer) 0 5 5 * 5
lag(value any [, offset integer [,
0 5 0 5 5
default any ]])
lead(value any [, offset integer [,
0 5 0 5 5
default any ]])
first_value(value any) 3 5 3 5 5
last_value(value any) 3 5 3 5 5
nth_value(value any, nth integer) 0 5 0 1 5
Метки: сравнениеСУБД

12) аналитические функции часть 2 из 3

Вторая большая группа функций - статистические оконные функции.
У слоника с ораклем тут всё в полном порядке. У mySQL всё плохо,
но в некоторых случаях можно пользоваться подзапросами с одноимёнными
агрегатными функциями,
правда в очень ограниченном режиме.
Распишу поподробнее назначение каждой функции:
percentile_cont() - непрерывная функция распределения, определяемая путем
интерполяции (т.е.
оценки значения функции или последовательности между двумя известными
значениями). В данном
случае эта функция вычисляет процентиль путем линейной интерполяции
упорядоченных строк.
percentile_disc() - ступенчатая функция, принимающая дискретные значения. Эта
функция проверяет
(с помощью CUME_DIST) значение функции распределения дискретной случайной
величины,
выраженной в процентах, в каждой группе для поиска первого значения,
большего или равного
указанному значению.

MySQ PostgreSQL8.3( M$SQ Linte ORACL

Функция
L 5.1 4) L 200х r 6.1 E 10
PERCENTILE_CONT() 0 0 0 * 5
PERCENTILE_DISC() 0 0 0 * 5

CORR() 0 5 * * 5
COVAR_POP 0 5 * * 5
COVAR_SAMP() 0 5 * * 5
STDDEV_SAMP() 1 5 * * 5
REGR_(вид_функции_линейной_регрес
0 5 * * 5
сии)
STDDEV() 1 5 * 5 5
STDDEV_POP() 1 5 * * 5
VAR_POP() 1 5 * * 5
VAR_SAMP() 1 5 * * 5
VARIANCE() 1 5 * 5 5
Метки: сравнениеСУБД

Комментариев: 2

12) Аналитические функции часть 3 из 3

Остатки, что не вошло в основную серию
avg(expression) среднее
bit_and(expression) двоичное и
bit_or(expression) двоичное или
bool_and(expression) логическое и
bool_or(expression) логическое или
count(*) колличество
max(expression) максимальное
min(expression) минимальное
sum(expression) сумма

Функция MySQL 5.1 PostgreSQL8.3(4) M$SQL 200х Linter 6.1 ORACLE 10

array_agg(expression) 0 5 0 0 *
avg(expression) 3 5 5 5 5
bit_and(expression) 0 5 * 0 *
bit_or(expression) 0 5 * 0 *
bool_and(expression) 0 5 * * *
bool_or(expression) 0 5 * * *
count(*) 3 5 5 5 5
count(expression) 3 5 5 5 5
every(expression) 0 5 * 5 *
max(expression) 3 5 5 5 5
min(expression) 3 5 * 5 5
sum(expression) 3 5 5 5 5
xmlagg(expression) 0 4 * 0 *

настроение: Бодрое

Метки: сравнениеСУБД

13) Поддержка разных ОС

То, что ORACLE почти вообще несовместим с фряхой мягко говоря удивляет
OS MySQL 5.1 PostgreSQL8.3(4) M$SQL 200х Linter 6.1 ORACLE 10
Windows 5 5 5 5 5
Mac OS X 5 5 0 * *
Linux 5 5 0 5 5
BSD 5 5 0 5 1
UNIX 5 5 0 5 5

настроение: Боевое

Метки: сравнениеСУБД

14)Поддержка основных кодировок

Про кодировки разговор особый. Для меня существует только юникод.
Это моё ИМХО. Остальные недокодировки должны сдохнуть, и точка.
Лично я предпочитаю хранить базу в UTF8, т.к. её сейчас не
поддерживает только ленивый и писать можно хоть на нескольких
языках сразу.
При переходе с MySQL на PostgreSQL я заметил контраст - почти
польное отсутствие глюков с кодировками, чего не скажешь о MySQL.
MSSQL тоже не богат на глюки, они там возникают редко, но метко.
Если COLLATION баз отличаются от сервера, то возможен гемморой
с попыткой подключить такую базу к такому серверу.
PostgreSQL поддерживает единственную уникодную кодировку,
и это хорошо, т.к. исключает разнобой.
Линтер запомнился принципиальным отсутствием оной. Извольте
пользоваться однобайтными уродцами, как сейчас - не знаю.

OS MySQL 5.1 PostgreSQL8.3(4) M$SQL 200х Linter 6.1 ORACLE 10

cp1251 3 5 4 5 5
cp866 3 5 4 5 5
MacCyrillic 3 5 * * 5
KOI8-RU 3 5 * 5 5
UTF8 3 5 * 3 5
UTF16 3 * * * 5
UTF32 3 * * * *

настроение: Боевое
Метки: сравнениеСУБД

15) Написание своего функционала

1)Открытый исходный код
2)pl/sql,
3)pl/perl,
4)tSQL,
5)pl/R,
6)pl/php,
7)pl/java,
8)pl/phyton,
9)c/c++/c#
10) Свои собственные типы
11) Свои собственные индексы
12) Свои собственные операторы
13) Гочи(gochas). Нарушения логики разработчиков.
Строго говоря, это документированные баги. Чем их меньше, тем лучше.

MySQL M$SQL Linter ORACLE

функциональность PostgreSQL8.3(4)
5.1 200х 6.1 10
1)Открытый исходный код 5 5 0 0 0
2)pl/sql, 0 5 0 5 5
3)pl/perl 0 4 * 0 *
4)tSQL 5 0 5 0 0
5)pl/R, 0 2 0 0 0
6)pl/php, 0 1 0 0 0
7)pl/java, 0 3 0 0 4
8)pl/phyton, 0 2 0 0 0
9)c/c++/c# 2 3 4 * 4
10) Свои собственные типы 0 4 * * 4
11) Свои собственные
0 4 0 * 4
индексы
12) Свои собственные
0 5 0 4 *
операторы
13) Отсутствие
0 4 3 4 4
гочей(gochas).

Рызюме:
По языкам у pgSQL самое широкое разнообразие, но вот поддержка каждого из языков
весьма и весьма разная. По отсутствию гочей у MySQL твёрдый ноль.
Метки: сравнениеСУБД

16) Прочее

MySQL M$SQL Linter ORACLE

функциональность PostgreSQL8.3(4)
5.1 200х 6.1 10
1)Математические
5 5 5 5 5
функции
2)Строковые функции 3 5 4 4 5
3)Функции даты и
3 4 5 4 5
времени
4)Логические функции 3 5 5 4 5

Метки: сравнениеСУБД