Добрый день.

Есть небольшой проект. Проект на C# Framework 2.0 (если нужно, можно и выше). Для него нужна база данных: около 10 таблиц, в районе 60-100 тысяч записей в каждой. Доступ с пяти-шести рабочих мест в локальной сети. Необходима авторизация.

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

Заранее спасибо .

бесплатная MS SQL Express 2005(2008)

Добавлено через 2 минуты и 1 секунду
Access не очень т.к. не на локальной машине, а через сеть. Если бы для одной машины то подошел бы.  

Спасибо, thomas. А оно не слишком тяжелое? Какой-нибуд MySQL илм SQLLight не шустрее будет?

SQLite - файловая база данных, Вам же нужна клиент-серверная. MySQL распространяется по dual license, поэтому для коммерческого использования он платный (в отличие от SQL Server Express).

Производительность СУБД, на мой взгляд, в Вашем случае не критична: с такими объемами справятся все современные клиент-серверные СУБД.

Это сообщение отредактировал(а) Idsa - 16.6.2009, 12:05

что Вы подразумеваете под тяжелым? да по размеру MS SQL Express 2005 будет по больше MySQL илм SQLLight но по скорости работы такая серверная БД для вашей задачи подойдет с лихвой.

Справедливости ради, в этой теме стоило бы упомянуть PostreSQL, который распространяется по bsd-like лицензии... но, пожалуй, с поставленной задачей справится и SQL Server Express.

Имеется в виду, что не слишком ли MS SQL Express 2005(2008) навороченная. Задача очень простая и хотелось бы использовать очень простую СУБД . Иными словами, чтобы из пушки по воробьям не стрелять.

amarenkov, всегда должен быть запас прочности. Думаю, по производительности SQL Server Express - то, что Вам нужно. Правда, можете попасть в неприятную ситуацию, когда потребуется функциональность, которой в Express Edition нет. Лицензии на SQL Server очень недешевые, поэтому, вероятно, придется переходить на другую СУБД. Поэтому:
1. Внимательно посмотрите, хватает ли Вам возможностей Express Edition
2. Используйте ORM. Во-первых, упростится процесс написания приложения (правильно ли я понял, что приложение - фронтенд к базе?). Во-вторых, при вероятной смене СУБД не придется переписывать код.

Да, Idsa, вы все правильно поняли . А, раз уж зашел об этом разговор, насколько ORM производителен? Сильно ли уступает обычным запросам в скорости и используемой памяти?

ORM - дополнительный слой над ADO.NET, поэтому он априори должен проигрывать в производительности. Однако:

1. Говоря, что ORM проигрывает в производительности чистому ADO.NET, мы предполагаем, что SQL-запросы писал гуру, оптимизируя их под конкретную версию конкретной СУБД. В реальности это далеко не всегда так. Поэтому если на простых запросах ORM проигрывают по всем статьям (в 2-4 раза), то на реальных запросах, например, с участием навигационных свойств (которые чаще всего преобразуются в join'ы) ORM может сгенерировать и более оптимальный запрос, чем это бы сделал программист (разработчики провайдера, как правило, знают больше об оптимизации под конкретную СУБД, чем рядовые прикладные программисты и даже DBA).

Безусловно, если Вы пишете социальную сеть с ожидаемой посещаемостью 10 миллионов уникумов в день, про ORM лучше забыть - немало сэкономите на железе. В более же приземленных приложениях ORM оказывается отличным выбором: жертвуя в некоторой степени производительностью, мы получаем удобство разработки и поддержки.

2. В LINQ To SQL и Entity Framework для увеличения производительности можно скомпилировать запрос.

стоит также рассмотреть вариант с FireBird

я бы рассматривал 3 варианта
1. mysql. собственный првайдер не поддерживает embedded версию, а те библиотеки которые поддерживают - платные. впрочем, если ты уже морально разложился и готов украсть - welcome to torrents.ru (((:
2. sql server ce - почти "настоящий" sql server, но есть ограничение на обьем базы и прочие (узнать подробнее можно из msdn)
3. berkley db - шустрая и маленькая встраиваямая БД, но после того как её прибрало к рукам Оракле, хз чё они с ней сделали...

ps. кстати есть еще Oracle XE, но его ограничения делают его практически бесполезным.

Спасибо за советы. А LINQ To SQL и Entity Framework одинаково хорошо работает со всеми вышеперечисленными СУБД? Или есть те, под которые эта технология более "заточена", что ли?

Политика Microsoft была, есть и будет - предоставить свой полный комплект ПО и технологий игнорируя совместимость с сторонним ПО. (только иногда, под давлением обстоятельств, они делают что-то иное, типа поддержки OOXML)

Skynin, давайте не будем предаваться холиварам.

amarenkov, LINQ To SQL изначально разрабатывался как ORM для SQL Server. Хотя позже появились реализации под многие СУБД: LINQ To Oracle, LINQ To MySQL и т. д. Реализации эти сторонние, и стоят денег. EF, наоборот, разрабатывался как универсальная ORM. Однако в стандартной поставки фреймворка есть провайдер только под SQL Server. Есть масса сторонних (небесплатных) провайдеров, которые реализуют поддержку других СУБД. 

Получается, и LINQ To SQL, и EF удобнее использовать именно с SQL Server. Если Вы остановите свой выбор на другой СУБД, можно либо приобрести платный провайдер, либо воспользоваться другой ORM, например, NHibernate. NHibernate поддерживает следующие базы данных: https://www.hibernate.org/361.html

Это сообщение отредактировал(а) Idsa - 17.6.2009, 11:40