» Выбор БД?

Подскажите какую локальную БД лучше с точки зрения надёжности,
скорости работы И безопасности выбрать? С ней будут работать 2-3
(максимум 5 пользователей). Общее кол-во записей во всех таблицах 10-15 тыс.
Максимум 50.Клиентское приложение будет на Delphi 7.0.

Microsoft SQL Server Developer Edition AKA MSDE

Interbase, Firebird

naPmu3aH

Цитата:

MSDE

Есть два MSDE:
1. Microsoft SQL Server™ version 7.0 or the Microsoft Data Engine (MSDE)
2. Microsoft Database Engine (MSDE) which will ship with Microsoft Office 2000, shares the same code base as SQL Server 7.0.

Как видно, суть есть одно и то же - укоцанный MS SQL Server 7/2000, а вот Developer Edition это полноценный MS SQL Server
Можешь глянуть в MSDN.

Negr
MSDE будет бесплатным и свободным к redistribution только в том случае, если есть лицензия на MS Office 2000 или MS SQL 7/2000.

Firebird - бесплатный Interbase 6 с дополнениями и улучшениями.

Еще есть MS Access, но тот проигрывет по возможностям первым двум, однако стоит отметить что это файловая СУБД, а те с выделенным сервером. MSDE, если можно так сказать, лучше Firebird/Interbase.

naPmu3aH

Цитата:

с точки зрения надёжности,
скорости работы И безопасности выбрать

Цитата:

Microsoft SQL Server

Очень смешно.

Negr
А сколько за это денег готов выложить? Если деньги есть то однозначно Oracle. Хотя, для такой крохотной БД это наверное слишком жирно.
Альтернатива - MySQL.

MS SQL по скорости проигрывает всем известным мне БД. По надежности и удобству работы аналогично. С безопасностью вообще п****ц. А стОит почти как Оракл.
(Давно хочу посмотреть на людей которые ЭТО покупают )

Вообще, посмотри сюда:
http://www.eweek.com/article2/0,3959,293,00.asp
http://www.eweek.com/slideshow/0,3670,s=1590&a=23120&po=1&i=1,00.asp

Jet 4.0
Полностью тебя удовлетворит!
Халявная мелкая и майкрософтовская - тобишь через АДО работает прекрасно

Я конечно не эксперт, но оптимально именно MySQL.
Полностью поддерживаю mymuss:

Цитата:

А сколько за это денег готов выложить? Если деньги есть то однозначно Oracle. Хотя, для такой крохотной БД это наверное слишком жирно.
Альтернатива - MySQL.

А !!! Ну да!
Для несведущих!
MS Jet 4.0 - база данных с которой работает Access! Тобишь файлы с расширением mdb.
Для того чтобы юзать MS Jet - Access устанавливать ненужно - нужно установить только сам MS Jet - который лежит на сайте майкрософта и доступен для закачки забесплатно!

Добавлено
Но и против мускуля я ничего неимею!

Bloody_Nokia_Adept

Цитата:

Microsoft Database Engine

Ну да, это я описАлся...

mymuss

Цитата:

MS SQL по скорости проигрывает всем известным мне БД. По надежности и удобству работы аналогично. С безопасностью вообще п****ц. А стОит почти как Оракл.

Я на такие заявления давно привык возлагать.
Но если хочется поспорить я с удовольствием выслушаю где у MS SQL Server не так с надежностью, удобством и особенно безопастностью... Желательно из личного опыта, а не цитатами с сайтов где собираются "ненавидящие Майкрософт" и "преисполненные веры в Linux".
А скорость - это... от рук зависит. От того куда и как они приложены.
Оракл это конечно кр00то , но есть мнение, что время которое потребуется автору вопроса на его изучение покроет по стоимости и SQL Server и и прогу вместе взятые.

На таком наборе данных - любая БД будет работать быстро. Надо только правильно ее спроектировать и с индексами разобраться. А так - хоть plain text. Другое дело - транзакционность, безопасность и надежность.
Я не работал с access, не знаю как там с безопасностью и транзакционностью, но вроде по отзывам система надежная и достаточно шустрая.
SQL если и стоит использовать, то в сильно порезанном виде. Штука сильно уж мощная для таких баз данных и достаточно дорогая.
То же самое и про Oracle.

Работая на Дельфи можно использовать борландовские БД, типа Interbase или Paradox.

А в принципе - что заморачиваться на конкретной БД - пиши для ADO .NET - хорошо сделаная штучка, а затем используй то, для чего найдешь ADO .NET провайдеров.

кхм
вы бы тово
спросили требования человека к базе чтоли, эксперты на линии
т.е. нужна ли поддержка
- транзакций
- триггеров/логики DB
- какова интенсивность select/insert/delete/update
etc

а так - для 5-10 юзеров и маленьких табличек вполне сойдут
MySQL (с транзакциями у него правда не совсем тово)
PostgreSQL (медленная при интенсивных запросах)
Solid
FireBird (former Interbase) - почти идеальна пожалуй для данной задачи будет, особенно ценно что можно в server logic использовать свои модули например на C++
Pervasive (former Btrieve), он правда денежек хочет, но это лечитца
4th Dimension

и ваще таких баз - валом в инете

SQL, Oracle. Угу, DB/2 исчо приплетите в этот список

Всем спасибо и Всех жду на продолжении нашей увлекательной беседы на тему "Хранение данных" <a href="http://forum.ru-board.com/topic.cgi?forum=33&bm=1&topic=1689#1">здесь</a>

Добавлено
Тест -


http://forum.ru-board.com/topic.cgi?forum=33&bm=1&topic=1689#1

redp
угу

ALL
ну робяты вы загнули
Oracle (MSSQL etc) для 5 пользователей, 50 тыс записей ????

для такой постановки задачи,
плюс Дельфи, лучше имхо Interbase/Firebird
причины:
1) хорошие компоненты под дельфи (доступ к БД, гриды, репорты)
2) простые визуальные средства проектирования (практически не зная SQL можно базы ваять не заморачиваясь)
3) практически не требует администрирования (при необходимости backup, restore делается легко, на этом, в принципе, все администрирование заканчивается)
4) надежность (имеется ввиду практически не чуствительна к некорректному завершению работы)
5) полноценные транзакции
6) стандартный SQL (для замороченных запросов)



mymuss
вот здесь вы батенька не правы,
MSSQL по скорости достаточно шустрый,
плюс интеграция с другими продуктами от MS (хотя часто это боком выходит),
только вот шустрость его с лихвой компенсируется его "безопасностью".
за примером далеко ходить не надо, недавняя эпидемия охватившая MSSQL сервера ,
прикольно, вирус поражающий БД сервера по сети ,
сложно представить что либо подобное, скажем с Ораклом, или тем же DB/2,
хотя если работа в режиме 24/7 не есть первостепенная задача, то запросто можно MSSQL пользовать и в ус не дуть

GreyGendalf

Цитата:

вот здесь вы батенька не правы,
MSSQL по скорости достаточно шустрый,

Позволю себе не согласиться. Смотрим факты:

Наихудший результат (200 за сек c пиком в 300 юзеров при 600 / 850 юзеров у MySQL и Oracle)


Опять наихудший результат (40 сек / 300 юзерах против 32 у MySQL и Oracle при 850 юзерах)

Время отклика - 105 сек при 1000 юзеров против 30 у MySQL и Oracle.

Т.е. мало того что он медленный, он не в силах вытянуть больше 250-300 запросов.

данные тесты ничего не говорят, ибо неизвестно, через что производилось обращение к BD (тем более при чем тут webpages? и причем тут JSP ? а если я через ODBC на C перепишу - результаты с Javой будут весьма сильно отличаться на одной и той же базе) - через ODBC/ADO/etc. Опять же сервер приложений/http сервера одинаковые были или что ? Для Oracle что использовалось например ? server side код на самой базе ?
Опять же OS/тачка и все прочее одинаково ?
Таблицы из которых запросы производились - одинаковые ? а индексы ? а насколько время запросов будет отличаться при одновременных updates в эти таблицы и на таблицах разной сложности ?
Вобщем цынк на полное описание тестов дай пажалста

То что MySQL быстрее - совершенно понятно, он заточен под скорость обработки относительно простых запросов. Зато у него с обеспечением транзакций и непротиворечивости представления данных несколько тово

И пачиму в этих тестах нету PostgreSQL (раз уж MySQL тестировался) ?

redp

Цитата:

Опять же сервер приложений/http сервера одинаковые были или что

Да.

Цитата:

Опять же OS/тачка и все прочее одинаково ?

Да, все одинаковое, все СУБД были поставлены в равные условия (а что ты видел чтобы скажем Oracle тестили на 2-х процессорном Xeon, 4Gb RAM, а MS-SQL на Celeron 500 / 128Mb ?)

Описание железа: http://www.pcmag.com/article2/0,4149,11821,00.asp
Софт, который использовался для тестов: http://www.pcmag.com/article2/0,4149,11820,00.asp


Цитата:

Зато у него с обеспечением транзакций и непротиворечивости представления данных несколько

Аргументируем, дабы не быть голословными


Цитата:

И пачиму в этих тестах нету PostgreSQL (раз уж MySQL тестировался) ?

пАчИму да пАчИму. Все ему расскажи Дело в том что PostgreSQL как СУБД для production server имеет нулевую ценность. Она настолько тормознутая, что ее просто принципиально нет смысла использовать на здоровых БД. А этот тест проводился как раз среди СУБД, ориентированных на бизнес-приложения.

> что ты видел чтобы скажем Oracle тестили на 2-х процессорном Xeon, 4Gb RAM, а MS-SQL на Celeron 500 / 128Mb
ага, красноглазые пингвинофилы оченно любют сравнивать ж..у с пальцем обычно

кароче, тесты шо ты смотрел(полный цынк кстати вот: http://www.eweek.com/article2/0,3959,293,00.asp) всего навсего меряют по большому счету производительность JDBC для разных баз. Особенно рекомендую обратить внимание на показатели SQL 2000 2nd Ed при использовании родных .ASP компонентов. Результаты совсем другие. Я бы даже сказал - кардинально отличаются
Так что не надо гнать что SQL медленный и ваще ацтой. Тогда уж JDBC драйвер для него

> Аргументируем, дабы не быть голословными
очень просто проверяется - запусти скажем 20 (а еще лучше 200) одновременных транзакций с массовым update/rollback на MySQL и скажем на oracle. И посмотрим производительность. А еще при этом если базу стопнуть - будет ли MySQL содержать непротиворечивые данные после этого ? Oracle - сто пудов

Цитата:

> что ты видел чтобы скажем Oracle тестили на 2-х процессорном Xeon, 4Gb RAM, а MS-SQL на Celeron 500 / 128Mb
ага, красноглазые пингвинофилы оченно любют сравнивать ж..у с пальцем обычно

кароче, тесты шо ты смотрел(полный цынк кстати вот: http://www.eweek.com/article2/0,3959,293,00.asp) всего навсего меряют по большому счету производительность JDBC для разных баз. Особенно рекомендую обратить внимание на показатели SQL 2000 2nd Ed при использовании родных .ASP компонентов. Результаты совсем другие. Я бы даже сказал - кардинально отличаются
Так что не надо гнать что SQL медленный и ваще ацтой. Тогда уж JDBC драйвер для него

> Аргументируем, дабы не быть голословными
очень просто проверяется - запусти скажем 20 (а еще лучше 200) одновременных транзакций с массовым update/rollback на MySQL и скажем на oracle. И посмотрим производительность. А еще при этом если базу стопнуть - будет ли MySQL содержать непротиворечивые данные после этого ? Oracle - сто пудов

Не могли бы ли вы мне помочь, был бы вам очень признателен. http://forum.ru-board.com/topic.cgi?forum=33&topic=1689#1 - здесь продолжение начатого.
Спасибо.

уйди мальчик
тут на MS SQL наехали, а ты ...

Цитата:

уйди мальчик
тут на MS SQL наехали, а ты ...

Ну да, собираю вещички и ухожу, так что Access пойдёт или нет?

2Negr: пиши на FoxPro
или сходи на http://www.sql.ru/forum/actualforum.aspx - там все гуры (или гурии ?) по базам данных сидят

2mymuss: я таки жду аргументированного ответа пачиму MS SQL - ацтой

redp

Цитата:

Особенно рекомендую обратить внимание на показатели SQL 2000 2nd Ed при использовании родных .ASP компонентов. Результаты совсем другие. Я бы даже сказал - кардинально отличаются

Это ровным счечтом ничего не значит. SQL server сравнили с самим собой. Весело.

Все равно что реализовать бизнес логику на PL/SQL и сравнивать Oracle с MySQL где бизнес логика реализована на Visual Basic.

Поэтому драйвер должен быть одинаковым на всех машинах.


Цитата:

всего навсего меряют по большому счету производительность JDBC для разных баз

Ты бы еще сказал что они всего-навсего меряют произврдительность разных СУБД на HP Netserver


Цитата:

очень просто проверяется - запусти скажем 20 (а еще лучше 200) одновременных транзакций с массовым update/rollback на MySQL и скажем на oracle. И посмотрим производительность. А еще при этом если базу стопнуть - будет ли MySQL содержать непротиворечивые данные после этого

Пока что это все не идет дальше твоих ничем не подкрепленных домыслов. Пожалуйста, конкретнее, либо ссылки на авторитетный источник, либо конкретное приложение, либо код итд...


Цитата:

пачиму MS SQL - ацтой

Патаму

по поводу slammerа - патч от MS был доступен уже полгода. Админы-лентяи

JDBC драйвер для MS SQL был бета версии. Непонятно почему для других баз не были взяты беты - ведь
> драйвер должен быть одинаковым на всех машинах

> SQL server сравнили с самим собой
нифига подобного, сравни цыфры на графиках SQL + ASP с прочими базами + JSP. SQL выглядит весьма достойно, если не сказать - отлично. Этак можно сказать что Java - сосет, ASP - рулит

> Все равно что реализовать бизнес логику на PL/SQL и сравнивать Oracle с MySQL где бизнес логика реализована на Visual Basic
мы скорость меряем и производительность, не так ли ? А на чем сие написано - дело втростепенное

Ну Вы господа и флеймеры!
Автора топика выгнали из его собственного треда! Это номер!!!

Чего спорить-то? У нормальной СУБД есть свои фишки. Моя фирма использует и MSSQL, и Oracle. По производительности они обе на уровне и со своими задачами, и с failsafe справляются очень даже. Если возможности СУБД не ограничивают разработчика (а это относится в равной степени к этим СУБД), то "кривость" или "рульность" относятся уже к решению задачи разработчиком.

Сходите на www.sql.ru там есть специальный форум по сравнению СУБД - там уж точно найдете себе достойныый оппонентов

redp

Цитата:

по поводу slammerа - патч от MS был доступен уже полгода. Админы-лентяи

Факт остается фактом. Ущерб нанесен колоссальный.


Цитата:

нифига подобного, сравни цыфры на графиках SQL + ASP с прочими базами + JSP

В равных с другими условиях MSSQL показал наихудший результат. А для того чтобы говорить про цЫфры в случае с ASP нужно иметь эти цифры для других серверов. А нам их не показали в силу определенных причин. Поэтому такое сравнение - это все равно что сравнивать цифры, полученные под Oracle на двухпроцессорном Xeon и цифры, полученные в MSSQL на Celeron. Повторяю: условия должны быть равными для всех.

Короче, все это оффтопик и я предлагаю на этом закрыть тему.

GreyGendalf

Цитата:

только вот шустрость его с лихвой компенсируется его "безопасностью".
за примером далеко ходить не надо, недавняя эпидемия охватившая MSSQL сервера ,
прикольно, вирус поражающий БД сервера по сети, сложно представить что либо подобное, скажем с Ораклом

представить не так и сложно: предлагаю зайти на www.cert.org и поинтересоваться SecurityAlert'aми по Oracle (187) и Microsoft SQL(35). Даже если учесть, что в список Oracle (уважаемой мной компании) попали и часть данных от смежных продуктов (app server, etc.), то все равно списов весьма приличный.

Там, при желании, можно обнаружить переполнения буферов в сетевых компонентах, возможность запуска удаленного кода и т.д. Само по себе такое количество alert"ов вовсе не означает, что Oracle слабозащищенный продукт. Просто админам нужно внимательно относиться к своим обязанностям.

GreyGendalf
mymuss

О SQL Slammer:

Администраторов, которые устанавливают сервер БД на прямо доступный из интера сервер и не закрывают при этом порты доступа к этому серверу БД "...нужно морально убивать на месте...(с) О. Бендер.". С администраторами, которые не отслеживают security alert'ы для ПО, установленном на интернет-серверах нужно делать то же самое (о других серверах тоже забывать не стоит). Что делать с администраторами, которые при этом еще и работают в банках и !национальных! ISP (см. начало статьи из ZD Net, которые привел mymuss) - мне даже сложно предположить. Что-то сильно-запоминающееся и показательное

all

Дискуссии о производительности, все чаще, являются простой потерей времени (IMHO). Уж больно много факторов влияет на конечный результат и его интерпритацию. Начиная от того, кто, зачем и на чьи деньги проводит испытание и заканчивая объектами и методами тестирования.

Равные условия для всех тестируемых продуктов тоже создать очень сложно - слишком много компонентов в объекте тестирования (я имею ввиду полную систему со всем ПО, включая ОС, драйвера и т.д., hardware). Маааленькая бага в бета-версии драйвера может существенно повлиять на конечный результат, не говоря уже о настройках ОС и hardware.

Так что равные условия - это миф (IMHO).

Можно, правда, измерять производительность и масштабируемость по другому: взять Х килобаксов, четкие спецификации тестовой задачи, специалистов-профессионалов по каждой из платформ. Дальше профи на фиксированную сумму килобаксов покупают железо и софт (условно, компоненты системы для тестирования могут быть взяты во временное пользование у производителей), пишут прикладное ПО, и УСИЛЕННО оптимизируют всю систему в целом с использованием знаний о конкретной платфоме (ситуация, когда специалисты по *nix начинают измерять производительность Wintel платформы, которую они же и установили - ничего кроме смеха не вызывает).

Но и в этом случает все будет очень приблизительно: для решения прикладной задачи самые эффективные решения (по скорости и масштабируемости) не всегда самые простые в разработке и сопровождении. Какой процент реальных систем для и-нета создан на языках 3G (CGI/ISAPI на плоском С)? Когда от времени выхода продукта на рынок зависит жизнь/смерть компании - не до особых технологических изысков.

P.S. В общем, относитьcя к "графикам из интернет" стоит с изрядной долей скептицизма.

добавлено

С предложением mymuss закрыть топик согласен, увлеклись что-то мы все...

Сомневаюсь в выборе базы данных и движка к ней перед запуском проекта. Сомневаюсь, соотв, между MariaDB vs Percona vs Postgres.

Входные данные такие:
Время жизни проекта (лет) 10
Объектов    2000
Записей для объекта в день 12
Байт в 1 записи    4096 (в таблице меньше, но думаю что вполне может быть больше)

Итого получается 87 600 000 записей.
Или 334,1674805    Гбайт данных.

Данные соотв добавляться будут максимум 12 раз в день (INSERT без всяких понтов), а остальные запросы - select по ключам id AND date (неуникальным).


Код: CREATE TABLE `myobjects` (
`id` int(8) NOT NULL,
`a0` tinyint(4) unsigned default '0',
`a1` mediumint(9) default NULL,
`a2` mediumint(9) default NULL,
`date` varchar(10) default NULL,
`a4` mediumint(9) NOT NULL,
`a5` smallint(6) default NULL,
`a6` tinytext NOT NULL,
`a7` tinyint(4) default NULL,
`a8` mediumint(9) default NULL,
`a9` smallint(5) default NULL,
`a10` varchar(10) default NULL,
`a11` varchar(512) default NULL,
`a12` varchar(12) default NULL,
`a13` tinyint(1) default NULL,
`a14` varchar(64) NOT NULL,
KEY `wid` (`wid`),
KEY `a12` (`a12`)
) ENGINE=XXXXXX DEFAULT CHARSET=cp1251;

DeADMoHAX
С такими вводными - ту, которую лучше знаете, ИМХО. Тем более если ошибки некритичны.

Лучше использовать то что через 10 лет не умрет, тот же MySql или MsSql, накройняк Oracle.

ekemov
как раз в дальнейшей судьбе MySQL как то все сейчас видится печально... выбрал марию, посмотрим