Aleksei_dФирма берется за разработку крупного коммерческого проекта с использованием Delphi и СУБД (MS SQL Server или Firebird) пока не определились.
Firebird не предназначен для крупных проектов. Для крупного коммерческого проекта - крупный коммерческий софт :)
Aleksei_d
1 - Хотелось бы выслушать тех у кого был опыт работы и с тем и с другим.
Пока склоняются в сторону Firebird (аргумент бесплатность, ведь используя MS SQL
отсекается доля потенциальных покупателей у кого не установлен MS SQL или автоматом
идет удорожание проекта)
Я совсем не поклонник MSSQL, но минусы Firebird:
- нет инкрементных backup и де-факто нет логов => крайне скудные возможности восстановления
- очень плохо с распараллеливанием (даже в рамках SMP) и буферизацей
- нет возможности перехода вверх на Enterprise-версии
- бедный SQL (правда, тут MSSQL тоже не очень...)
- крайне корявая реорганизация БД (через backup-restore)
- отвратный оптимизатор (надо ОЧЕНЬ тщательно писать запросы)
- ...
Единственный плюс - компактность и нетребовательность к ресурсам. Отсюда и все недостатки :)

Aleksei_d
2 - Я лично с FB не работал. Мой опыт это (MS SQL + Sybase) в связи с этим интересно мнение
людей принимавших участие в средних и выше проектах с использованием FB (ее надежность,
скорость, устойчивость к нагрузкам и др)

Проект предполагает не менее 100-150 клиентских подключений и около 100 таблиц в
начальной стадии дистрибутива, в процессе эксплуатации кол-во таблиц будет расти.
Таблицы будут содержать текстовую и графическую информацию.
У меня достаточно большой опыт работы с Firebird и IBM DB2, с MSSQL - довольно скудный. Мое мнение: Firebird - это СУБД для простых втроенных / коробочных систем без обслуживания.
Мой любимый совет - IBM DB2 Express-C. Совсем бесплатна, почти все фичи взрослых версий, кроме Enterprise (общий код) + часть дополнительных, почти полный автомат в обслуживании, нет ограничений на данные-коннекты и т.д., только 2 проц. ядра / 2 ГБ ОП.
Есть нативное хранение / индексация / запросы XML, полнотекстовая индексация и запросы (Net Search Extender), рекурсивный SQL, прекрасный оптимизатор, туча утилит, бесплатная граф. среда разработки и администрирования... Вобщем, imho ЕДИНСТВЕННАЯ на рынке бесплатная (без ограничений на данные) версия "взрослой" СУБД. С Firebird'ом сравнивать по функционалу бессмысленно.
Кстати, из Delphi Enterprise к DB2 можно обращаться через dbExpress, ADO DB, ODBC...
Я с ней работаю из C++ Builder и VS (С++).

pkarklin
И чего Вам не хватает и, самое главное, для чего?!
Например, раздражает необходимость писать в MS SQL процедуры с циклами там, где в DB2 достаточно одного запроса. Нет предиката WITH, розволяющего писать Prolog-подобные многоэтажные (в т.ч. рекурсивные) select'ы. Насколько я знаю, нет оператора MERGE (множественный insert-update-delete по условиям). Да, без этого можно обойтись - но в DB2 SQL богаче. К тому же, декларативный запрос оптимизируется/параллелится куда лучше процедуры.
Не хватает XML native storage с индексами и XML-запросами. Если он нужен (фактически, иерархическая СУБД внутри реляционной), то заменить нечем.

pkarklin
И потом, ищи-свищи спецов по ИБМ, особенно в регионах. А вот 1С со скулем, уже чуть ли ни в каждой забегаловке стоит.
DB2 9.5 спокойненько может жить в автономе. Ее надо один раз настроить и прописать автомат. администрирование. Мы ее встраиваем в т.ч. в закрытое оборудование, без администрирования руками вообще. К тому же, с простыми операциями типа backup-resore-runstat-reorg разберется за 1 день любой DBA с опытом в любой СУБД - все есть в граф. интерфейсе. Вся дока есть на русском.
Кстати, 1С живет и с DB2 (у 1С даже есть дистрибутив Express-C на сайте :).

pkarklin
Берите MS SQL - не пожалеете. Это уже мой любимый совет. ;)
На вкус, цвет и СУБД - товарищей нет :)
Если бы речь шла о платных СУБД - универсальный совет использовать то, что хорошо знаешь.
Но у халявной, в т.ч. для распространения, DB2 Express-C сейчас по совокупности свойств вообще нет конкурентов.

Leonid
В DB2 - действительно навороченный язык запросов. Отчасти для компенсации отсутствия банальных хранимок в предыдущих версиях. Раньше их нужно было неприменно на сях компилировать под платформу - гемор еще тот, зато быстро работали. Вроде как только сейчас исправили, хотя я уже давно с DB2 не общался.
ОЧЕНЬ давно :) Процедурный SQL есть в DB2 уже много лет. Хранимки и функции можно писать на нем, можно на Java. Хотя и на С писать все еще можно, для ценителей :) Скорее, навороты процедурного языка нужны для компенсации бедного SQL.

LeonidНо по большому счету нет там ничего такого, чего бы нельзя было компенсировать в том же Transact-SQL условно двумя-тремя операторами.
Не спорю. Но при сложной обработке оптимизатор гораздо лучше переварит/распараллелит один большой запрос, чем кучку вложенных циклов.
Ксати, оптимизатор в DB2 полностью переформулировает весь запрос, со всеми неявными функциями-триггерами. С процедурой сие невозможно по определению. В SQL все-таки лучше писать ЧТО, а не КАК.

LeonidFavn, вы отстали от жизни. WITH - уже есть в MSSQL, а так же куча всего другого. MERGE появится в 2008.
Увы, не отстал. Я не имею в виду WITH (<table_hint> ) в MS SQL. Этого как раз нет в DB2 - ее оптимизатор настолько суров, что не принимает подсказок
В DB2 WITH имеет совсем другой смысл:
WITH temp1 (col1, col2) as
(VALUES ( 0, 'AA'), ( 1, 'BB'), ( 2, NULL) )
, temp2 (col1, col2 ) as
( select col1, col2 from temp1 where col1 < 2 )
SELECT * FROM temp2;
temp1 описывает первый предикат (таблица из 2 полей и 3 записей), temp2 его уточняет условием, select запускает выборку. Фактически, это описание "виртуальных" временных таблиц, но без их заполнения. Возможна рекурсия, можно обойти дерево одним запросом. Кто помнит Prolog - поймет весь кайф.
По поводу MERGE - рад. Правда.

LeonidМожет, может... Но MSSQL может не хуже.
Не спорю. Я говорил о том, что нехватка админов - не проблема для не очень сложных БД, и уж тем более для БД под бесплатной версией.

LeonidНе забывайте про MSSQL2005 Express. Он конечно немного обрезанный. Но на первое время в маленькой конторке даже он справляется.
Угу. Ладно бы MAX 1 ГБ RAM, но вот MAX 4 ГБ данных в БД... Тут по поводу немного обрезанный вспоминается куча анекдотов
Версия с ограничением по объему данных - по определению ознакомительная , а не бесплатная . ЭТО нельзя использовать в коммерческих проектах.

LeonidТак ли давно? Если мне память не отшибает, то 7-ка обладая процедурным языком, на самом деле парсила его в Си-шные тексты и компилировала. Или я чего-то путаю?...
Все так. Было. Но 8-ка вышла лет этак 5 назад, если не больше. Давно - понятие относительное :)
Уже и 9-ка пару лет как работает.
А из новостей - в свежей бесплатной Data Studio наконец-то появилась построчная отладка SQL и Java процедур на сервере, с проектами и подсветкой синтаксиса. Ну прям как в нормальном RAD, разродились наконец-то
Так что пользоваться SQL-процедурами удобно стало совсем недавно, тут я не спорю :)

Упс. Случайно опубликовал. Мыша дрогнула.

LeonidКстати, чего там в последних версиях DB2 c колэйшенами? Или по прежнему "Ёжик" <> "ежик" по любому? GUID ввели уже?
Коллейшены есть, настраиваются, в т.ч. для Unicode.
GUID - это ROW_ID? Тогда - уже появился в 9.5. Только что :)

LeonidСрадства разработки серверной части какие? Я в свое время Quest Central юзал. По сравнению с MSSQL-ми даже встроенными средствами, DB2 в этом плане геморой еще тот.
Угу. И тот был геморрой, и этот - тоже :) К счастью, тока что вышла халявная IBM Data Studio на Eclipse. Почти все, за что надо было платить Quest sofware за Toad (или красть оную :) - умеет сама. Quest Central - тоже остался, родимый

LeonidМое ИМНО: DB2 - делает по скорости запросов и MSSQL и Oracle. Иногда, при очень больших объемах это сильно заметно. При этом по удобству работы, скорости проектирования и работе с модными наворотами она уступает последним.
На Firebird в коммерческом проекте лучше забить.
Согласен, но сейчас и с удобством дело сильно исправилось. Firebird для коммерческого применения пригоден, но для совсем компактных (или встроенных) проектов. Типа халтур :)

LeonidИногда и DB2 - шный оптимизатор ошибается, а вот помочь ему, выходит, никак. Но, я бы на вашем месте излишне не нахваливал оптимизатор DB2, поскольку у MSSQL оптимизатор запросов не то что хорош, а чуть ли не лучший. К тому же, как я уже сказал, язык запросов MSSQL уже очень близок к возможностям DB2.
Теоретически - может быть. Я с ошибками не сталкивался. По поводу крутости - IBM как раз считает, что это у нее лучший в отрасли оптимизатор. Думаю, у Оракл будет еще одно мнение
По поводу SQL - мое мнение сформировано опытом этак 6-летней давности. Если с тех пор SQL у MS стал лучше - рад. Но - только что почитал о фичах 2008. Не нашел ничего, чего еще нет в DB2.

LeonidFavn, я именно это и имел в виду. В mssql2005 это называется CTE - common table expression. Синтаксис такой же.
А рекурсия допускается?! (с маниакальным блеском в глазах :)

Leonid Не забывайте еще, что MSSQL2005 уже не блокировочник, а некая хренотень по желанию: хочешь тебе блокировочник, хочешь - версионник с честной поддержкой serializable.
В 9.5 появился механизм "оптимистичной блокировки". Фактически - версионное чтение с возможностью последующей проверки записи на предмет ее изменения по ROW_ID. DB2 сама обновляет спец. поле с временем последнего изменения записи.

LeonidЗато у вас в DB2 табличных переменных по моему как не было так и нет (не путать с временными таблицамми)
В 9.5 появились массивы. И есть функция TABLE, формирующая таблицу из всего, что ей скормят :)

LeonidЕще какая проблема! А вот админа на MSSQL, при том который даже в случае чего чего-нибудь подправить сможет, уже почти в каждой дыре найдешь.
Ну, хорошего-то не во всякой дыре :) Литературы куча, курсов куча, да и на базовом уровне админить DB2 9.5 стало совем не сложно - автоматы, адвизоры... Все через граф. интерфейс.

LeonidДа чаще всего ни кого не коробит свежетянутый полноценный сервер поставить - кому какое дело (не забывайте, где живем :) )
Оно конечно, но тогда вообще сравнивать версии бестолку. Да и не коробит для единичного заказа, а вот ежели тиражировать систему - закоробит, и еще как!

Aleksei_dОкончательное решение за маркетингом, думаю, что будут смотреть в сторону MS SQL Server по причине:
1. Сегмент рынка у них все же больше чем у IBM
2. Большинство программистов учавствущих в проекте имеют опыт работы с MS SQL
3. DB2 Express-C менее документирована. Хотя ИМХО: очень заслуживает внимания.
1. В России - да, вообще - не очень :)
2. На самом деле - самый веский довод. Не считая цены :)
3. Сомнительно. Документации - куча, в т.ч. на русском. А если говорить о платной версии - саппорт IBM и в России хорош.

Aleksei_d2Favn: Вопросик: Я на сайте ibm не нашел принцип ограничения в 4 Гб (все что больше не используем или если больше то просто не работаем)?
Тут все для Express-C сложно.
1. Есть версия 9.1.2, у нее ограничение 4 ГБ и 4 проц ядра (не процессора!) на весь сервер. Т.е. на сервер мощнее ставить нельзя - нарушение лицензии. Для скачивания с сайта IBM уже недоступна, но есть и другие сайты :) Легально использовать ее можно и сейчас.
2. Есть версия последняя 9.5, у нее ограничение 2 ГБ и 2 ядра, но ее можно ставить на любой сервер, она сама больше не съест. У нее есть несколько полезных фич, в т.ч. полностью автоматическое управление буферами в ОП (перераспределение каждые 30 сек по ситуации, СУБД надо сказать только сколько памяти всего отъесть), лучше мультитрединг в Linux, ROW_ID, оптимистичная блокировка, кое-что в XML и т.д.
IBM утверждает, что 9.5 на 2Гб живет не хуже, чем 9.1.2 на 4 Гб. Судя по форуму IBM, особо в это не верят :) Но - фичи полезные, то есть каждый может выбирать сам.
3. Есть платная подписка на Express-C 9.5 - 3000-3500$ на сервер в год. Она расширяет ее до 4 ядра / 4 Гб и добавляет репликацию и зеркальные кластеры (HADR), а также настоящий саппорт.

Конкретика есть на форуме http://www.ibm.com/developerworks/forums/forum.jspa?forumID=805
Он же и саппорт для бесплатной версии.

LeonidGUID - это (Globally Unique Identifier). Что-нибудь типа '{3CDD5964-76C3-4B77-94F2-761E597AB61C}' mssql - поддерживает его найтивно. Можно даже вместо целочисленного ID-шника использовать, но вообще - идеальное средство для всяких там рукотворных сверок и репликаций, поскольку совпадение практически невозможно.
Понял. ROW_ID уникален до следующего REORG, это не о том - просто адресный доступ к записи.
Если я правильно понял, GUID можно заменить SEQUENCE - значение будет уникальным. Если ему никто RESTART не сделает :)
Кроме того, есть функция, возвращающая гарантированно уникальное значение. Но - на базе TIMESTAMP, т.е. время на сервере при ее использовании назад лучше не переводить :)