Random_GoodmanЧе-то я склоняюсь к DB\2. Быстрая, надежная, бесплатная. а платная не так уж и дорого стоит, по сравнению с тем же Ораклом. Но надо подумать.Как недавно плотно занимавшийся ознакомлением DB2 скажу:
DB2- база хорошая, но посмотрите для себя внимательно следующее:
1) Посмотрите как и чем вы с ней будете работать. Инструментария мало и он не удобен.
2) По сравнению с другими, плохая поддержка UNICODE.
3) В отличии от MSSQL VARCHAR-ы case и accent-зависимые. "Ёжики" и "ежики" в индексах будут разными.
4) Написание хранимок по сравнению с MSSQL и Оракл - еще тот геморой.
5) Тип GUID не поддерживается и в ближайшее време небудет. Хотя далеко не всем надо.

Leonid3) В отличии от MSSQL VARCHAR-ы case и accent-зависимые. "Ёжики" и "ежики" в индексах будут разными.Вернее в MSSQL они настраиваемые.

Victor Metelitsa
Leonid2) По сравнению с другими, плохая поддержка UNICODE.
В чём?Это разве не ваши слова:
Victor MetelitsaХм. Посмотрел в CREATE TABLE:

# Tables created with CCSID UNICODE cannot be referenced in SQL functions or SQL methods (SQLSTATE 560C0).
# An SQL statement that references a table created with CCSID UNICODE cannot invoke an SQL function or SQL method (SQLSTATE 53090).
# Tables cannot have both the CCSID UNICODE clause and the DATA CAPTURE CHANGES clause specified (SQLSTATE 42613).
# Declared global temporary tables cannot be created with CCSID UNICODE (SQLSTATE 56031).
# SQL statements are always interpreted in the database code page. In particular, this means that every character in literals, hex literals, and delimited identifiers must have a representation in the database code page; otherwise, the character will be replaced with the substitution character.

Не вдохновляет.Если взять тот же MSSQL, то там работа с (char/nchar)(varchar/nvarchar) (text/ntext) (varchar(max)/nvarchar(max)) практически прозрачна.

Victor Metelitsa Leonid4) Написание хранимок по сравнению с MSSQL и Оракл - еще тот геморой.В чём?Для того чтобы написать хранимку под win мне пришлось поставить старый VS, поскольку от VS2005 Си-шный nmake не подходил. Это может и фигня, но фактически SQL-льные хранимки в DB2 это жестко-платформенно откомпилированные модули. Разве не так?
В кросплатформенном Оракле нет необходимости такой компиляции процедур на PL/SQL (хотя она и возможна), а на T-SQL и подавно. И они будут переносимы с версии на версию и с сервера на сервер с минимальными телодвижениями.

Victor Metelitsa Leonid5) Тип GUID не поддерживается и в ближайшее време небудет. Хотя далеко не всем надо.
Я полагаю, это очень легко сделать, если приспичит (и вы дружите с C).Под win не сложно, под Linux немного сложнее. Я, например, не знаю точного алгоритма создания GUID. Попробуйте найти и создать, если хотите.
В любом случае, это не будет так просто, как встроенный тип.
Но опять же повторюсь, далеко не всем это надо.

Victor MetelitsaЦитаты про unicode относятся про случай unicode-строк в не-unicode базе. В unicode базе дела обстоят по-другому.Честно говоря, вообще, не очень понятно, зачем такое деление на unicode/ не unicode базы? Казалось бы достаточно типа поля unicode/не unicode.
Кстати, как создается unicode база на DB2 - только заданием кодовой страницы при создании базы? А то на 7.2 для русского языка мне этого сделать так и не удалось.

Victor MetelitsaХранимые процедуры в DB2 8.2 совсем не обязательно писать на C, и они переносимы. Да SP и на C переносимы (см. SQLLIB\SAMPLES), с версии на версию, с ОС на ОС (нужна всего лишь перекомпиляция). Но с 8.2 компилятор C для SP SQL не нужен, прям как в Oracle.Поверю вам про 8.2 на слово, поскольку я его увижу лишь через месяц.
Хотя по языку Oracle все равно впереди, а с mssql2005 они уже практически наравне

Victor MetelitsaУверен, что для генерации GUID где-нибудь в интернете найдётся готовый код.Попробуйте найти, я уже пытался для Linux...
Может вам больше повезет. Еще раз повторю, в любом случае это будет геморойнее, чем встроенный тип.
Вообще, если сравнивать с MSSQL, то набор встроенных типов у MSSSQL несколько богаче (есть даже variant).

По настройке и администрированию мне DB2, в принципе, понравился. При желании, сервер многое может взять на себя и делает это хорошо.
В этом они схожи с MSSQL. Чего не скажешь про Оракл (наш админ даже с 10-кой прыгает с бубном).

ASCRUSЕсли есть глобальные инкременты или сиквенсы или нет репликаций, то я лично потребности в GUID вообще не ощущаю - наоборот, если его использовать в качестве PK, то мы получаем одни недостатки в виде увеличения обьема данных и индексов, невозможности сортировки по нему, так как значения выдаются неупорядоченно и еще кучу геммора. Лично для меня GUID хорош только для ввода уникального обозначения данных для разных систем, то есть при интеграции и передаче данных, но никак для хранения в качестве основного идентификатора и работы с ним (та же песня, что и с XML).Зачем вам сортировка по PK? Так уж ли сильно увеличится объем? И что за куча гемора?
Не делайте голословных утверждений. Если вы их не используете - это ваше дело.
Вы просто не умеете их готовить :)

Еще XML зачем-то приплели. Он-то чем вам не угодил? Или то же по старчески :)