Помогите с выбором БД для разработки приложения типа клиент-сервер.
Пользователей от одного до десяти, все могут одновременно подключаться к серверу, изменять данные итп...  
Программа разработывается пока под свои нужды, но теоретически может быть продана где-нибудь на территории ex-USSR.
Думается мне, что надо бы использовать какой-нибудь SQL сервер, но какой?
Может есть чего-нибудь не настолько дорогое как MS SQL, чтобы заранее возможных покупателей не пугать.

Сергей

ЗЫ. Я понимаю, что подобная тема всплывала не раз, сам даже видел, но найти не смог

Обрати внимание наAdavantage Database Server
Если пишешь на Delphi(С++Builder) - тем более стоит: Второй  год подряд он по опросам среди разработчиков Delphi выйграл номинацию лучшего движка БД.
Особенности: кроме своего формата (adt), поддерживает (dbf) - очень помогает, елси вдруг нужно подключать данные из других программ. На сервере выполняются не только SQL-запросы, но (этого нет ни у кого) обычные фильтры по таблице. Имееются сервера под платформы Win9X!!!,WinNT/2000, Novel,Linux. Клиентская часть  под платформу Windows и Linux.Естественно имеются дравер ODBC и ADO
Локальную версию сервера и клиентскую часть (Nativ Component для Builder и Delphi) можно скачать с сервера совершенно бесплатно.Весь фокус в том, что при переходе к удаленному серверу перекомпиляции приложения не требуется. Т.е разработк уможно вести на локальном сервере, да и наначальном уровне можно поставлять систему на локальном сервере(правда со снижением надежности и быстродействия)
Дополнительные примочки: сервер  имет встроенный интернет-сервер, также бесплатно поставляется сервер приложений

Насколько серьёзная программа? Как много запросов? Если пользователей до 10 и число запрососв не превышает несколько в минуту, то даже MS Access подойдет - по крайней мере с установкой и покупкой проблем не будет.

Очень рекомендую SyBase Anywhere 5.5. Вещь не новая, но крайне надежная и
мощная.

Ответ прост, как все гениальное : MySQL - самая шустрая и бесплатная РСУБД.

Цитата(Sattu @ 08.8.2002, 12:45)

Ответ прост, как все гениальное : MySQL - самая шустрая и бесплатная РСУБД.

А как к ней подсоединиться из Дельфи, VB или VC?

Можно через ODBC, хотя в серьезных проектах его следует избегать. Можно через родную либу на С. Вообще - смотри тут API: http://www.mysql.com/downloads/api.html

Мда! Посмотрел я на эти API. Работка еще та...

To crimaniak: хочу предложить Вам зарегистрироваться на форуме, Вы у нас постоянно обитаете, при регистрации Вам же удобнее будет - легче отслеживать что уже прочитанно, а что новое, при желании получать на email уведомление о новых ответах в интересующие топики, участвовать в голосованиях и многое другое. Настоятельно рекомендую!

Цитата

Мда! Посмотрел я на эти API. Работка еще та...

 Конечно, в голом виде сишным mysql интерфейсом лучше не пользоваться, нужна ООП прокладка, кроме явы, где jdbc сразу правильно был сделан.

Цитата

To crimaniak: хочу предложить Вам зарегистрироваться на форуме, Вы у нас постоянно обитаете,

Это ненадолго, я уже практически ушел. А ответы, я думаю, должны быть отслеживаемы в любом случае, для этого не нужна регистрация (см. мой форум).

Проект скорее всего будет писаться на VC++, возможен VC#, в крайнем случае BC++ Builder.  Все пока на стадии разработки (сейчас создается структура данных) и еще возможно выбрать среду разработки. Но то что это будет не Delphi я уверен, ибо не перевариваю его в принципе. ;)

Скорость нужна небольшая, порядка запроса в секунду.

Вопрос: почему так не любите ODBC, потому как я склоняюсь к варианту VC++ +ODBC в виду его простоты и возможности подключения к любой СУБД ( благо SQL везде одинаковый).

Цитата(Seregy @ 13.8.2002, 06:31)

Вопрос: почему так не любите ODBC, потому как я склоняюсь к варианту VC++ +ODBC в виду его простоты и возможности подключения к любой СУБД ( благо SQL везде одинаковый).

Не люблю так как он самый медленный, да он наиболее универсальный, но по скорости уступает другим системам чуть ли не на порядок, но если ты будешь использовать такое количество запросов то может никто этого и не заметит. А то что SQL одинаков, так я тебе скажу там только 2 квери одинаковые:

Select * From MyTable
Delete From MyTable

А ещё чуть глубже и различий будет ни счесть. Сам не однократно переделывал программы с DBase, Paradox, MS SQLServer, Oracle, MS Access - каждый раз очень существенные изменения, причём зачастую приходилось очень сильно код менять, а не только сами квери из-за отсутствия очень многих возможностей в той или иной среде. Я уже молчу об оптимальности запросов - то что оптимально и быстро работает для одной базы данных может убить другую...

Я тоже присоединяюсь к мнению, что ODBC - страшные тормоза.На мой взгляд, попытки реализовать на его основе более-менее работающую клиент-серверную систему заранее обречены на провал.

Насчет MySQL. В Builder6 (и я думаю в Delphi 6)  предоставлена возможность подключения к MySQL через  dbExpress. Я пока использую по основной работе Builder 5, но тестовый пример подключения к МySQL на Builder 6 уже делал. Особых проблем не заметил.

Цитата(Vyacheslav @ 13.8.2002, 09:27)

На мой взгляд, попытки реализовать на его основе более-менее работающую клиент-серверную систему заранее обречены на провал.

Точно! Если его использовать то только в системах - 1 локальная база данных на том же компьютере, что и клиентское приложение при наличии только 1 приложения работающего с базой данных. В этом случае будет получена вполне удовлетворительная производительность, при увеличении количества клиентов, особенно на удалённых компьютерах скорость будет падать в экспотенциальном порядке. При количестве клиентов в 10-15 система умрёт (ну не так чтоб умрёт, но я видел такие системы там обычный запрос выполняется минут по 15-20...). Кстати эти же соображения применимы и к BDE, только BDE для локального монопользовательского доступа к Paradox/Dbase таблиц тоже превосходит ODBC по производительности, а для клиент-серверных технологий - проблемы те же - хорошая производительность для монопользовательского доступа и умирание при возрастании числа пользователей.

Уговорили ODBC мне уже не внушает доверия.
Значит кроме него остается альтернатива OLEDB. Но, если не брать
MS SQL, то больше ни с какими распространенными серверами он не работает.
Обидно - остается только пиратским ПО пользоваться
Хотя когда по-другому было

несколько слов в защиту ODBC. У него есть режим, когда запросы передаются  без всякой обработки напрямую серверу. В данном случае запрос пишется  не на ODBCшный SQL"е, а на SQL"е используемом на сервере. Этот режим мног-много быстрее.

Oracle, это даже не вопрос..... стандарт де-факто!

Цитата(Pegas @ 02.11.2002, 12:57)

Oracle, это даже не вопрос..... стандарт де-факто!

Стандарт то он конечно стандарт, спору нет хорошая база особенно если пишется что-то жутко большое, но вот незадачка - цена-то кусается, и даже очень! Тот же MS SQL Server при практически той же производительности стоит в 3 раза дешевле, а на многопроцессорных системах цена может различаться уже на порядок, про более дешёвые сервера я уже молчу, их нет даже смысла сравнивать с Ораклом. У нас на фирме было время начали задумываться на переходе на Oracle, но подсчитав все плюсы и минусы выяснилось что будет в 3 раза дешевле купить ещё штук 5 серверов и установить MS SQL Server и что аналогичной производительности можно добится на MS SQL Server увеличивая число серверов и докупая железо, что обойдётся гораздо дешевле...

Коллеги, а чем вам InterBase не нравится ?  Очень простой, очень компактный, очень надежный и очень мощный сервер. Его клоны под названиями FireBird (Штаты) и Yaffil (Россия) даже бесплатны. Сервер кросс-платформенный, имеются драйвера ODBC, JDBC, OLEDB-провайдеры, SQL-линки для BDE, компоненты прямого доступа для Delphi и BCB; и коммерческие, и бесплатные. Можно работать напрямую с IB API. Сервер полностью поддерживает ANSI SQL-92 Entry Level. Его российский клон Yaffil также готовится в embedded-варианте, встраиваемый прямо в разрабатываемое приложение. В общем, арсенал для работы с InterBase вполне приличный  

А есть у кого-нибудь реальный опыт работы с IB и c MS SQL/Oracle чтобы он мог поделиться впечатлениями? Прес-релизы, реклама, документация это одно, а реальный опыт это другое, особенно если есть опыт работы с обоими серверами, чтобы была база для сравнения...

Шесть лет работаю на InterBase   С позиций опыта имею основания заявить, что IB вполне покроет сектор от малых проектов, до средних и сложных (даже иногда залезая в тяжелые - есть сведения о базе размером в 180 Гб, работающей под InterBase). С размером рабочего дистрибутива сервера IB - ~900 Кб - не может поспорить даже local-Paradox !!! Также пробовал MSSQL, но отказался от него. Главная причина отказа - InterBase практически не требует администрирования, что делает его очень предпочтительным в тиражируемых системах. Мой личный рекорд - база ~300 Мб, проработавшая "без ухода" в течение 4 лет.   А мощь InterBase мало в чем уступает мощи MSSQL...
А в стане "соперника" - клона FireBird - готовится сервер нового поколения с еще большими возможностями. Об InterBase, его клонах и инструментарии лучше читать тут - http://www.ibase.ru

Очень интересно. Мои требования к серверу баз данных для тех продуктов которые я разрабатываю примерно следующие:

1) Поддержка баз данных размером до 200-300 Gb
2) Одновременное подключение около нескольких тысяч пользователей - возможно, что каждый под своим логином (пока можно считать разумным максимум в 5000 одновременных подключений)
3) Примерное количество запросов - до 100 в секунду (имеются ввиду простые и небольшие запросы), задержки времени выполнения запроса более 1 секунды не допустимы
4) поддержка не менее десятка баз данных на одном сервере
5) поддержка репликаций, DTS
6) поддержка удалённого доступа (через интернет)
7) поддержка tape backup
8) поддержка многопроцессорных серверов
9) поддержка true loading balansing

Есть ли такие возможности в IB и насколько хорошо они работают?

По п.1. Я сам, конечно, с такими гигантскими базами не работал еще   Скажу только следующее - база IB может резаться на части до 2Gb (InterBase <=6.0) и до 4Gb (Firebird, IB > 6.0), всего может быть 65536 частей. Так что суммарный размер базы может быть вполне приличным.

По п.2. Нет проблем, число подключений ограничивается только "пропускной способностью" ОС и железа.

По п.3. Тоже нет проблем. Скажу больше - со скоростью работы IB может конкурировать, пожалуй, только Oracle. Конечно, на простых тестах с одним-двумя-тремя-десятком коннектами показатели IB не столь впечатляющи, как, скажем, у MSSQL. Но InterBase - сервер с версионной архитектурой, в котором блокировки отсутствуют, как класс. И во всей красе он себя проявляет при одновременной интенсивной работе большого кол-ва юзеров, с большим числом транзакций, запросов и т.д. В нем нет, например, такой неприятной проблемы MSSQL, как эскалация блокировок (правда, я не в курсе возможностей новейших версий MSSQL). Ну и плюс, конечно, железо - на рядовой писишке вряд ли высокую скорость получим...  

По п.4. - тоже никаких проблем, баз может быть сколько угодно. Но! В одной базе можно обращаться только к собственным объектам (таблицам, вьюхам и т.д.). К объектам других баз обращаться нельзя (в-принципе, это правильно, т.к. противоречит принципам целостности данных). Если такая фишка нужна - придется писать приложение/аппсервер, который подключается к разным базам, и выдает юзерам select по объектам из разных БД.

По п.5. Вот этого, к сожалению, нет. Может быть, будет в сервере FireBird нового поколения. Для нынешних версий есть репликаторы от сторонних производителей, которые добавляют к таблицам служебные поля, создают служебные триггеры и т.д. для обеспечения механизма репликации.

По п.6. Никаких проблем - протоколы NetBEUI, IPX/SPX, TCP/IP. Плюс локальное подключение к файлу базы (желательно в однопользовательском режиме, чтобы не испортить базу), ежели сетевые протоколы не установлены. Клон Yaffil, помимо этого, содержит экспериментальный локальный протокол XNet, для быстрого и безопасного локального подключения (предназначается для использования в embedded-версии).

По п.7. Есть утилита GBak для снятия бэкапа. Стартует как юзер в snapshot-транзакции, делает backup закоммиченых на момент старта транзакции данных (юзеры при этом продолжают работать). Для больших баз настоятельно рекомендуется делать контрольный restore на другой машине. Во избежание.
Иногда встречаются базы с такой навороченной логикой, рекурсиями в триггерах, рекурсиями в calculated-полях и т.п., что restore такой базы просто не проходит.

По п.8. Надо отметить, что InterBase существует в 2 вариантах - ClassicServer и SuperServer. Первый - отдельный процесс на каждый коннект + процесс-диспетчер. Отлично масштабируется на многопроцессорных серверах. Второй - сервер представляет собой один процесс, каждый коннект создает отдельный поток. Масштабируемость у него - хреновая, в силу многих причин. Зато очень быстр на большом кол-ве коротких запросов, да еще и общий для всех юзеров кэш (в Классике - отдельный кэш на каждый процесс). В новом FireBird пытаются это исправить и создают SuperServer2, который хорошо будет масштабироваться на несколько процессоров.

По п.9. Этого точно нет, потому как не нужно в силу архитектурных особенностей InterBase.

Цитата

сервер с версионной архитектурой, в котором блокировки отсутствуют, как класс.

Дык иногда они нужны, хотя конечно очень редко.

Цитата

К объектам других баз обращаться нельзя (в-принципе, это правильно, т.к. противоречит принципам целостности данных).

Это очень плохо, у меня проект работает с 8 базами данных физически расположенных на разных серверах и квери типа

Цитата

Select a From server1.database1.table1,server2.database2.table2 where server1.database1.table1.field1=server2.database2.table2.field2

мне очень нужны.

Цитата

По п.5. Вот этого, к сожалению, нет. Может быть, будет в сервере FireBird нового поколения. Для нынешних версий есть репликаторы от сторонних производителей, которые добавляют к таблицам служебные поля, создают служебные триггеры и т.д. для обеспечения механизма репликации.

Очень существенный минус

Цитата

По п.9. Этого точно нет, потому как не нужно в силу архитектурных особенностей InterBase.

Как это в смысле не нужно? Например у меня сервак который во первых не справляется с нагрузкой, во вторых должен работать ни на минуту не прерываясь - у нас договор, что каждая минута простоя оплачивается в тысячи долларов. Никто не гарантирует что на компе может слететь винт или сгореть процессор... Следовательно ставим например 3-4 сервера вместе, устанавливаем true loading balancing и все 3 компьютера работают как 1 сервер - запрос отправляется наименее загруженному серверу, если один компьютер сдыхает - пользователь этого даже не замечает - система продолжает работать без него без всяких проблем.

В целом, с твоих слов, складывается впечатление что IB довольно неплохой сервер, особенно для маленьких проектов, однако с администрированием у него большие проблемы - для средних и крупных проектов он мало пригоден, здесь как всегда вне конкуренции MS SQL и Oracle

Цитата(Guest @ 07.11.2002, 16:58)

InterBase практически не требует администрирования

Штука это обоюдо-острая! Автоматическое администрирование существенно упрощает жизнь новичкам-разработчикам и клиентам, но одновременно с этим очень сильно сужает возможности , делает продукт почти непригодным для средних и больших проектов, когда администрирование начинать играть очень большую роль - backup, subscription, replication, DTS, назначение пользователей, настройка кластеров, настройка взаимодействий серверов и т.п. Мне в этом плане нравится MS SQL Server 7.0/2000 - он вообще без настройки и всякого администрирования позволяет работать на малых проектах, а по мере усложнения можно всё больше и больше вмешиваться во все аспекты работы сервера.

> Автоматическое администрирование существенно упрощает жизнь новичкам-разработчикам

Под минимальным администрированием в InterBase понимается вот-что - достаточно сделать операцию backup-restore файла базы, чтобы все было ОК. При этом производится сборка мусора, перестройка индексов, отметка испорченных страниц, если таковые будут и т.д. Для прочих манипуляций, таких как работа с юзерами, раздача грантов, etc, существует масса инструментария от сторонних производителей, разной степени юзабельности. Если база+программа относительно сложные - должен быть админ БД !
А InterBase особенно привлекателен для клиентов, у которых нет админов, и программный комплекс работает самостоятельно и не требует присмотра.

> Как это в смысле не нужно? Например у меня сервак который во первых не справляется с нагрузкой, во вторых должен

Короче, получается кластер ? InterBase имеет такую штуку, как shadow - теневую копию базы. Делаем несколько массивов RAID, на одном - база, на остальных - теневые копии. По мере последовательной порчи страниц или выхода из строя массива InterBase подключает очередную по счету теневую копию. Управление массивами осуществляется несколькими компами, объединенных в кластер, где перераспределение нагрузки производит ОС, а не сервер БД (это не его функции, однако!). И я не верю в существование серверов баз данных, для которых не нужно проводить профилактику с остановкой сервера. Не царское это дело - непрерывность процесса обеспечивать... В любом случае это получается некая программная система, задействующая возможности сервера БД, ОС, сети и т.д.

> В целом, с твоих слов, складывается впечатление что IB довольно неплохой сервер, особенно для маленьких проектов,

Для маленьких - в особенности годится. Я уже не использую ничего другого в подобных проектах, никаких проблем InterBase мне не доставлял. Для администрирования пишется маленький bat-файл, где производится сеанс backup-restore, и обучается девочка простому клику мышой после окончания рабочего дня или недели  

Цитата(Guest @ 08.11.2002, 08:50)

Короче, получается кластер ? InterBase имеет такую штуку, как shadow - теневую копию базы.

Ну это не совсем то, это ситуация когда один из серверов на подхвате - в случае чего он просто принимает запросы на себя, а основной сервак выключается. Действительно распределение нагрузки берёт на себя ось, но БД должна поддерживать такой режим работы.

Цитата(Guest @ 08.11.2002, 08:50)

И я не верю в существование серверов баз данных, для которых не нужно проводить профилактику с остановкой сервера. Не царское это дело - непрерывность процесса обеспечивать... ;-)

Таких действительно нет, но речь не об этом, мы тоже делаем профилактику (точнее никакую ни профилактику, а глобальные изменения структуры баз данных и софта) пару раз в год, при этом мы за месяц предупреждаем всех клиентов что например в ночь с субботы на воскресенье с 20:00 до 21:30 сервис будет выключен, я же говорю о внезапных поломках системы - например драйв посыпался, блок питания перегорел, мамка сдохла, и т.п. При таких ситуациях сервис не должен прерываться ни на одну секунду, так как клиенты заранее не были предупреждены.

Посмотрите информацию на сайте www.shushu.boom.ru там интересненькая база данных на высоких скоростях и бо о о льших обьемах данных

Цитата

Так что суммарный размер базы может быть вполне приличным

А backup, а в особенности restore базы такого объема будет длится тоже вполне приличное время - не менее нескольких суток. Ничего не имею против - Interbase замечательный сервер, но ИМХО ниша его - базы <10-15 Гб и юзеров <200.

ИМХО ВЫ не правы (если вы имеете в виду firebierd) то вот ссылка Читать здесь

какая СУБД удовлетворяет этим условиям???

potgresql, oracle, возможно sqlite и mysql


? может лучше одно подключение для сервера-программы  и пусть пользователи работают с клиентом который подключается к серверу


могу посоветовать postgresql - только не знаю насчет:

Всем требованиям сразу удовлетворяют "промышленные" СУБД - Oracle, DB2, SQL Server, Sybase ASE.

2All
Ну вы, блин, даете... Объем базы, режим работы, задача - ничего нет. А уже советами засыпали. Очередная религиозная война... Я тогда тоже спрошу: "я вот программку хочу написать - а какой язык лучше?" 

Seregy, 
Давай так: пока вопрос сформулирован ну совсем никак, ничего не выберешь. А сейчас именно так:
"Хочу авто, чтобы 10 человек везти мог...". А потому:
1. Ожидаемый объем БД и тенденции его изменения в ближайшие 2-5 лет?
2. Траффик (чтение, модификация) данных? Средние и пиковые значения (юзеров и мегабайт)?
3. Режим работы? 7х24... 5х9 дней х часов в неделю?
4. Оперативность/надежность? (сервер рухнул - ну и ладно, через 2 часа после подъема из бэкапа продолжим... 5 минут простоя - $5,000,000 штрафа) 
5. Администрирование/дуракоустойчивость? Местными силами.. через telnet. Маша из межделмаша...под роспись "с инструкцией ознакомлен..."
6. Защита от несанкционированного доступа? (а нехай своруют - никому не интересно...если стащат 5 кБ - получу 5 лет строгого режима)
7. Функционал? (Интернет-форум...сервер коммерческого банка...сервер КБ, разрабатывающего, например грелки для пупка   )
8. Сколько денег за него можно будет просить и насколько востребован будет (забесплатно раздадим - контора зарплату платит... $150,000/1 лицензия, 1 контора...worldwide  а-ля мелкомягкие...
И это еще не все...

SergeBS, тема 2002 года, и в данном случае был ответ на вопрос Rodman.