выбор SQL

← →
TCrash (2007-05-12 13:34) [0]

Доброе время суток.
Интересный вопрос возник.
Требуется выбрать SQL сервер для организации. Примерная нагрузка : ~20-25 компов, из задач - начисление зарплаты, основные фонды, отдел кадров, база потребителей и т.д.
База будет не большая, но под файл-серверную архитектуру писать не хочется.
Варианты SQL: MS SQL, MySQL, FireBird
Просьба высказать свои аргументы за и против каждого из вариантов.

PS: языки программирования на выбор MS C++ or Delphi

← →
Jan1 (2007-05-12 13:36) [1]

То что лучше знаешь и готовы ли платить за платную СУБД.

← →
homm © (2007-05-12 13:39) [2]

ИМхо, для дельфи FireBird, хотя сам только с MySQL работаю (топтому как ПХП)

← →
TCrash (2007-05-12 13:39) [3]

> То что лучше знаешь и готовы ли платить за платную СУБД.

Можно сказать, что готовы.
Руководство требует результата. И готово обеспечить мат. поддержку.

← →
TCrash (2007-05-12 13:40) [4]

> ИМхо, для дельфи FireBird, хотя сам только с MySQL работаю
> (топтому как ПХП)

Вообще, преимущественный вариант С++

← →
Jan1 (2007-05-12 13:41) [5]

> ожно сказать, что готовы.
> Руководство требует результата. И готово обеспечить мат.
> поддержку.

Я бы выбрал Delphi+SDAC+MSSQL2005.

← →
TCrash (2007-05-12 13:48) [6]

Аргументы плиз в студию. ибо машинка, которая будет все крутить не самая мощная, а MS SQL све же тяжеловат. Хотелось бы услышать( увидеть) ++++++
:)

← →
homm © (2007-05-12 13:53) [7]

> ибо машинка, которая будет все крутить не самая мощная,
> а MS SQL све же тяжеловат

MySQL требует ровно 3 мегабайта оперативной памяти :)

← →
Юрий Зотов © (2007-05-12 13:58) [8]

> TCrash (12.05.07 13:34)

Если 20-25 рабочих мест и небольшая БД, то, видимо, Firebird - про причине финансовой и простоты обслуживания.

← →
TCrash (2007-05-12 14:04) [9]

> Если 20-25 рабочих мест и небольшая БД, то, видимо, Firebird
> - про причине финансовой и простоты обслуживания.

Собственно с FireBird никогда плотного дела не имел. Есть там хранимые процедуры, тригеры? (Сразу оговорюсь - более менее плотно знаю только MS SQL)

← →
TCrash (2007-05-12 14:06) [10]

> Юрий Зотов © (12.05.07 13:58) [8]

Кстати сам примерно и думаю про FireBird по финансовым причинам и по легкости самого сервера

← →
Юрий Зотов © (2007-05-12 14:07) [11]

> Есть там хранимые процедуры, тригеры

Естественно.

← →
Jan1 (2007-05-12 14:21) [12]

> Сразу оговорюсь - более менее плотно знаю только MS SQL

Тогда чего тут думать?
Firebird проигрывает не только по скорости с MS SQL, а уж по части управления, сопровождения и программирования и кучи софта так и вообще далеко позади...

> Аргументы плиз в студию. ибо машинка, которая будет все
> крутить не самая мощная, а MS SQL све же тяжеловат.

Что значит тяжеловат? :) Дистрибутив что ли? :)
Аргументы ниже.

← →
Юрий Зотов © (2007-05-12 14:27) [13]

> а уж по части управления, сопровождения и программирования и кучи
> софта так и вообще далеко позади...

Аргументы ниже.
(c) Jan1

Потому что заявление - это не аргумент. Заявить можно что угодно.

← →
Romkin © (2007-05-12 14:32) [14]

Подойдет любой сервер БД под эти требования. Правда, насчет MySQL я бы поостерегся: на мой взгляд, возможностей маловато, он все-таки заточен под веб. Да и платный будет.
Если знаком с MSSQL - бери его. Только учитывай, что бесплатная версия имеет заметные ограничения.
У Firebird, предупреждаю, библиотеки для С++ довольно примитивны, а OLE DB провайдер платный.
Jan1 (12.05.07 14:21) [12] не говори, чего не знаешь.

← →
matt © (2007-05-12 14:53) [15]

PostgreSQL?

← →
Mystic © (2007-05-12 14:54) [16]

Из того, с чем я сталкивался, я бы расположил по удобству программирования примерно так:

1) Oracle
2) Firebird
3) MS SQL 2000

В MS SQL 2000 меня очень сильно ограничивает тот факт, что использовать результаты выполнения хранимой процедуры внутри самого SQL довольно проблематично, тогда как в Firebird и Oracle такой проблемы нет. Реализовывать аналитическую функцию в T-SQL тоже не сильно приятно. С MySQL я сталкивался только с ранними версиями, впечатление было такое: хорошая робастая база данных, но с малыми возможностями для программирования.

← →
Jan1 (2007-05-12 14:54) [17]

> не говори, чего не знаешь.

знаю и говорю. работаю с MS SQL 3 года и с Firebird - 5. В Firebird в 2-ку понатыкивали много всего от insert or update(еще в бы и or delete прилипили) и еще всякого, которое то и не нужно, доделали бы нормальные тулзни и секьюрити.

← →
Jan1 (2007-05-12 15:01) [18]

Еще меня сильно напрягает тот факт что в Firebird разделены SQL комманды для ХП и обычного SQL, да они добавили execure block, но млин зачем еще одна кострукция? Надо упрощать, а они усложняют... А сделать интеграцию со своей же базой, не говоря уже про другие СУБД, просто гемморой...

← →
Romkin © (2007-05-12 15:33) [19]

Jan1 (12.05.07 14:54) [17] И чем тогда тебя IBExpert не устраивает?
И что там плохого в секьюрити? вроде же по стандарту все.
Команды, кстати, не разделены. Ты говоришь, наверно, о пакетном исполнении команд? Я и в надобности execute statement сомневаюсь :)
А вот схем не хватает, это да.
Я бы не удивился, если бы ты указал на трудности с бекапом/восстановлением. Или ты это имел в виду под сопровождением?
А приведенные тобой аргументы довольно спорные.
Скорость - ну, во-первых, это как запрограммируешь, во-вторых, если производительность устраивает - то какие вопросы?
Управление - есть IBExpert. Не вижу, что еще нужно.
Сопровождение - а что ты под этим подразумеваешь? Обеспечение работоспособности? У нас этим занимаются обычные сисадмины.
Программирование? А здесь какие проблемы?
Куча софта? Это как? Какого софта и зачем?

← →
Jan1 (2007-05-12 15:48) [20]

> И чем тогда тебя IBExpert не устраивает?

устраивает конечно, но не в нем дело...

> И что там плохого в секьюрити? вроде же по стандарту все.

стандарт то стандарт, но :
1. хотелось бы интеграции с актив директори.
2. управление доступом на уровне колонок.

> Я бы не удивился, если бы ты указал на трудности с бекапом/восстановлением.
> Или ты это имел в виду под сопровождением?

я имел ввиду большой набор встроенных функций и ХП, чего в ФБ нет, надо или UDF искать, или как-то извращаться...
и не только, взять хотя бы набор утилит, которые идут с MS SQL и сравнить с FB. Тут и репликация, и интеграция с другими СУБД(большущий минус ФБ!), и профайлинг, и оптимизация и импорт/экспорт...

> Скорость - ну, во-первых, это как запрограммируешь, во-вторых,
> если производительность устраивает - то какие вопросы?

да, все конечно зависит от программиста, но все таки в MS посильнее будет, те же кластерные индексы и индексированные вьюхи, временные таблицы...

← →
PEAKTOP © (2007-05-12 15:54) [21]

>MS SQL
Для 20-25 компов - не тяжеловато будет ? Да и сервак ему мощный потребуется, если писать что-то вроде 1С (когда все данные на клиента тянуться, гы-гы).

> MySQL
Это вообще не SQL-сервер (по крайней мере, до 5-й версии), а машина баз данных, типа BDE или ODBC. Отсутствуют напрочь транзитивность и многоверсионность. В пятерке вроде "прикрутили", зато на Windows Server 2003 ОЗУ жрет 89МБ, это для шести потоков для hMailServer. И это для одной единственной базы почтового сервера на 1,5 метра. Может, конечно, еще и hMailServer кривыми ручками писали, тут ручаться не буду.

Рядом крутиться Firebird 2.0 в классике для 46-потоков суммарно жрет 340МБ. Дык база у него больше 5 Гиг. Хотя на точках продаж он же изолированно от центра обслуживает клиентское ПО на 400-х вторых пнях и не тормозит.

← →
Romkin © (2007-05-12 16:35) [22]

> 1. хотелось бы интеграции с актив директори.

Ну это как бы сказать... Ты хочешь от мультиплатформного сервера интеграции с проприетарной технологией одной конкретной ОС? Мне почему-то кажется, что полное взаимодействие может сделать только MS...

> 2. управление доступом на уровне колонок.
А это куда делось? Всегда было.

> я имел ввиду большой набор встроенных функций и ХП, чего
> в ФБ нет, надо или UDF искать, или как-то извращаться...
> и не только, взять хотя бы набор утилит, которые идут с
> MS SQL и сравнить с FB. Тут и репликация, и интеграция с
> другими СУБД(большущий минус ФБ!), и профайлинг, и оптимизация
> и импорт/экспорт...

> да, все конечно зависит от программиста, но все таки в MS
> посильнее будет, те же кластерные индексы и индексированные
> вьюхи, временные таблицы...

Вот так всегда: одним словом, хочется все и сразу :)
Хочется от простого сервера всей функциональности монстров вроде MSSQL и Oracle.
Firebird - это чистый сервер БД. Без излишеств. И на мой взгляд, это правильно: сервер БД должен обрабатывать данные в БД, остальное - это не его задачи.
Набор функций? Мне достаточно, вполне. И неужели, если так уж припрет, стандартной библиотеки udf недостаточно?
Утилиты? Да, поставляется только необходимый набор. Остальное - есть утилиты. Некоторые бесплатные, некоторые платные.
Нужно учитывать, что MSSQL фактически еще и сервер приложений, и большая часть из перечисленного не входит в обязанности сервера БД. И при небольшой БД на 20-25 пользователей прктически и не потребуется.

Дело в том, что я спокойно делаю и профайлинг, и оптимизацию, и материализованные вьюхи, и многое другое...
А вот кластерные индексы - хм. В версионнике? С какой целью?
Временные таблицы тоже не так уж и нужны.

С интеграцией с другими СУБД решение - как с безопасностью в жигулях: интеграцией занимается другая СУБД :)

Firebird - простой, но мощный сервер БД. И только сервер БД.
Сложность тут только одна, в разработчиках. Понятное желание: выучить один инструмент и пихать его куда попало.
Млин. Мне всерьез предлагали поставить Оракл для 5 рабочих мест со смешным размером БД. Просто потому, что потянет.
Тут еще близко стоит желание разработчика изучить мощный инструмент: с целью повышения ЗП. И, кстати, на мой взгляд, это одна из основных (если не самая основная) причин, по которым для разработки выбирается MSSQL или Oracle. Их право :)

← →
homm © (2007-05-12 17:46) [23]

> > MySQL
> Это вообще не SQL-сервер (по крайней мере, до 5-й версии)
> , а машина баз данных, типа BDE или ODBC. Отсутствуют напрочь
> транзитивность и многоверсионность. В пятерке вроде "прикрутили",
> зато на Windows Server 2003 ОЗУ жрет 89МБ,

Может и гиг жрать и больше, главное правильно настроить ;) (если ты понимаешь о чем я)

← →
Desdechado © (2007-05-12 18:17) [24]

> Примерная нагрузка : ~20-25 компов,
Загрузка сервера исчисляется не подключениями к нему, а интенсивностью и видом операций, выполняемых на нем. Можно и одним запросом на колени поставить крутейшую СУБД на невдолбенном железе.

PS пока не вижу смысла у автора применять что-то, кроме FB

← →
PEAKTOP © (2007-05-12 18:17) [25]

> Может и гиг жрать и больше, главное правильно настроить
Это ты про "my.ini", чтоль :))) а толку-то. Все равно MySQL его не читал :))

← →
homm © (2007-05-12 18:22) [26]

> Все равно MySQL его не читал :))

Ого! Видимо самопальная компиляция с вырезаной инициализацией. Как вариан — не там лежал, или не так назывался. Еше может называться «my.cnt», кажется.

← →
PEAKTOP © (2007-05-12 18:57) [27]

> Ого! Видимо самопальная компиляция с вырезаной инициализацией. Как вариан — не там лежал, или не так назывался. Еше может называться «my.cnt», кажется.

Да нет. Скачано с mysql.com. И в НТ-сервайсе прописана строчка ини-файла.
Дело в hMailServer, он курсоры открытыми держит (в ОпэнСурсэ, исходники не трудно проанализировать). Вот и накапливается буфер дня за три. Со старта - положенные в конфиге размеры. А может, это что-то WinNT не подружилась с ним. В общем, ковыряться надо, а сегодня суббота и мне в падлу.

← →
PEAKTOP © (2007-05-12 18:59) [28]

И вообще, решил переделать все на FireBird на Indy самостоятельно. Когда-нибудь. Потом.

:)))

> Romkin (12.05.2007 16:35:22) [22]

> И, кстати, на мой взгляд, это одна из основных (если не самая основная) причин, по которым для разработки выбирается MSSQL или Oracle.

Не знаю, кто на каком основание выбирается, но ниша MSSQL от КПК до мощных датацентров с многотеррабайтными базами. В верхней нише он сравним с Oracle, а в нижней не знаю даже есть ли альтернативы.

> Romkin (12.05.2007 19:11:29) [29]

Не требуется особо и стараться, можно на колени поставить любой сервер и с 0 операторами, достаточно правильно сформировать запросы на серверной стороне.
А можно нормально работать и с тысячами операторов.

> ниша MSSQL от КПК до мощных датацентров с многотеррабайтными
> базами

Ну можно сказать, об этом я и говорю :)))
Выбирается для изучения что-то одно большое и всеобъемлющее. Как С++. Невзирая на эффективность.

Desdechado © (12.05.07 18:17) [24]
> PS пока не вижу смысла у автора применять что-то, кроме FB
вот
TCrash (12.05.07 14:04) [9]
... (Сразу оговорюсь - более менее плотно знаю только MS SQL)
имхо достаточный смысл.
написанное чтото со знанием дела будет явно лучше чем на том в чем дилетант. и если цель не в изучении, а в написании... по моему выводы очевидны.

> ниша MSSQL от КПК до мощных датацентров с многотеррабайтными
> базами. В верхней нише он сравним с Oracle, а в нижней не
> знаю даже есть ли альтернативы

То, что на КПК - не MS SQL. Это крохотный, никак кроме названия с ним не связанный, движок БД. Он даже что такое "индекс" понятия не имеет, не говоря уже о ХП, триггерах и всем остальном :) Справедливости ради стоит заметить, что конкурентов у него действительно ноль.
В десктопной/персональной нише он тоже ни то, ни се. Ибо здесь к СУБД первое требование - удобная морда и возможность мышкой сооружать отчеты и формы. Т.е. Access форева.
В нише "легких" SQL-серверов опять же, куда ему конкурировать с FB/PostgreSQL? Ограничения бесплатной версии уже стают серьезным препятствием для использования, а платная... она платная.
Т.е. реально он эффективен только в тяжеловесных мощных решениях

> DrPass © (13.05.07 15:00) [34]

> То, что на КПК - не MS SQL. Это крохотный, никак кроме названия
> с ним не связанный, движок БД. Он даже что такое "индекс"
> понятия не имеет, не говоря уже о ХП, триггерах и всем остальном
> :)

Инфа устарела однако уже.

> DrPass (13.05.2007 15:00:34) [34]

Правда мне непонятно, почему ты связал фронт энд инструмент с СУБД, ну бог тебе судья, хотя и это все есть - Reporing Services, Simple Query, Analises Services, OLAP.

Говоришь Акцесс форева, так Микрософт тоже самое говорит, вы можете использовать любой клиентский инструмент для создания/работы с MS SQL, например Акцесс, ФоксПро и прочее, прочее.

Кстати, наша команда разработчиков почти полностью из FB/Delphi перешла на MS/MS. Сейчас без переменных типа table и еще некоторых "вкусностей" MS SQL 2005 было бы сложно.

> Карелин Артем (13.05.2007 15:09:37) [37]

Да, да, надоели обещания, что мол в следующей версии будет.

> Карелин Артем © (13.05.07 15:06) [35]

Ну почему? Вот свежак SQL Server Mobile стоит (вместе с VS2005 достался). Я щас ему create index bla-bla-bla, а он мне в ответ capability not supported.

>
> Anatoly Podgoretsky © (13.05.07 15:07) [36]

Конечно, связал - потому что сама по себе СУБД конечным продуктом не является, это всего лишь кусочек инфраструктуры. И речь о применимости СУБД в той или иной сфере может идти лишь в контексте применения всего сопутствующего софта.
А потребителю той самой персональной СУБД действительно в подавляющем большинстве случаев будет удобнее взять просто Access именно в качестве СУБД, а не клиента для SQL-сервера и решить свою задачу. И уж тем более не обкладываться десятком других, далеко не самых простых и понятных инструментов

> DrPass (13.05.2007 15:20:39) [39]

В общем сделаем вывод, что ты плохо знаешь MS SQL
И делаешь странные выводы по фронт энд, который кстати весьма мощный у MS SQL, но это лишнее для SQL сервера.

выбор SQL Найти похожие ветки