| Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум программистов > Базы данных под .NET > Подскажите СУБД |
| Автор: amarenkov 16.6.2009, 09:59 |
| Добрый день. Есть небольшой проект. Проект на C# Framework 2.0 (если нужно, можно и выше). Для него нужна база данных: около 10 таблиц, в районе 60-100 тысяч записей в каждой. Доступ с пяти-шести рабочих мест в локальной сети. Необходима авторизация. Посоветуйте максимально простую, быструю СУБД подходящую для этого случая. Основная ориентация - на скорость операций с базой данных. Заранее спасибо  . |
| Автор: thomas 16.6.2009, 10:19 |
| бесплатная MS SQL Express 2005(2008) Добавлено через 2 минуты и 1 секунду Access не очень т.к. не на локальной машине, а через сеть. Если бы для одной машины то подошел бы. |
| Автор: amarenkov 16.6.2009, 11:40 |
| Спасибо, thomas. А оно не слишком тяжелое? Какой-нибуд MySQL илм SQLLight не шустрее будет? |
| Автор: Idsa 16.6.2009, 12:01 | ||
SQLite - файловая база данных, Вам же нужна клиент-серверная. MySQL распространяется по dual license, поэтому для коммерческого использования он платный (в отличие от SQL Server Express). Производительность СУБД, на мой взгляд, в Вашем случае не критична: с такими объемами справятся все современные клиент-серверные СУБД. |
| Автор: Conkistador 16.6.2009, 12:13 | ||
что Вы подразумеваете под тяжелым? да по размеру MS SQL Express 2005 будет по больше MySQL илм SQLLight но по скорости работы такая серверная БД для вашей задачи подойдет с лихвой. |
| Автор: Idsa 16.6.2009, 12:19 |
| Справедливости ради, в этой теме стоило бы упомянуть PostreSQL, который распространяется по bsd-like лицензии... но, пожалуй, с поставленной задачей справится и SQL Server Express. |
| Автор: amarenkov 16.6.2009, 12:37 | ||
Имеется в виду, что не слишком ли MS SQL Express 2005(2008) навороченная. Задача очень простая и хотелось бы использовать очень простую СУБД . Иными словами, чтобы из пушки по воробьям не стрелять. |
| Автор: Idsa 16.6.2009, 13:28 |
| amarenkov, всегда должен быть запас прочности. Думаю, по производительности SQL Server Express - то, что Вам нужно. Правда, можете попасть в неприятную ситуацию, когда потребуется функциональность, которой в Express Edition нет. Лицензии на SQL Server очень недешевые, поэтому, вероятно, придется переходить на другую СУБД. Поэтому: 1. Внимательно посмотрите, хватает ли Вам возможностей Express Edition 2. Используйте ORM. Во-первых, упростится процесс написания приложения (правильно ли я понял, что приложение - фронтенд к базе?). Во-вторых, при вероятной смене СУБД не придется переписывать код. |
| Автор: amarenkov 16.6.2009, 13:51 |
| Да, Idsa, вы все правильно поняли . А, раз уж зашел об этом разговор, насколько ORM производителен? Сильно ли уступает обычным запросам в скорости и используемой памяти? |
| Автор: Idsa 16.6.2009, 14:31 | ||
ORM - дополнительный слой над ADO.NET, поэтому он априори должен проигрывать в производительности. Однако: 1. Говоря, что ORM проигрывает в производительности чистому ADO.NET, мы предполагаем, что SQL-запросы писал гуру, оптимизируя их под конкретную версию конкретной СУБД. В реальности это далеко не всегда так. Поэтому если на простых запросах ORM проигрывают по всем статьям (в 2-4 раза), то на реальных запросах, например, с участием навигационных свойств (которые чаще всего преобразуются в join'ы) ORM может сгенерировать и более оптимальный запрос, чем это бы сделал программист (разработчики провайдера, как правило, знают больше об оптимизации под конкретную СУБД, чем рядовые прикладные программисты и даже DBA). Безусловно, если Вы пишете социальную сеть с ожидаемой посещаемостью 10 миллионов уникумов в день, про ORM лучше забыть - немало сэкономите на железе. В более же приземленных приложениях ORM оказывается отличным выбором: жертвуя в некоторой степени производительностью, мы получаем удобство разработки и поддержки. 2. В LINQ To SQL и Entity Framework для увеличения производительности можно скомпилировать запрос. |
| Автор: jonie 16.6.2009, 19:21 |
| стоит также рассмотреть вариант с FireBird |
| Автор: Rififi 16.6.2009, 22:52 |
| я бы рассматривал 3 варианта 1. mysql. собственный првайдер не поддерживает embedded версию, а те библиотеки которые поддерживают - платные. впрочем, если ты уже морально разложился и готов украсть - welcome to torrents.ru (((: 2. sql server ce - почти "настоящий" sql server, но есть ограничение на обьем базы и прочие (узнать подробнее можно из msdn) 3. berkley db - шустрая и маленькая встраиваямая БД, но после того как её прибрало к рукам Оракле, хз чё они с ней сделали... ps. кстати есть еще Oracle XE, но его ограничения делают его практически бесполезным. |
| Автор: amarenkov 17.6.2009, 06:18 |
| Спасибо за советы. А LINQ To SQL и Entity Framework одинаково хорошо работает со всеми вышеперечисленными СУБД? Или есть те, под которые эта технология более "заточена", что ли? |
| Автор: Skynin 17.6.2009, 09:40 | ||
Политика Microsoft была, есть и будет - предоставить свой полный комплект ПО и технологий игнорируя совместимость с сторонним ПО. (только иногда, под давлением обстоятельств, они делают что-то иное, типа поддержки OOXML) |
| Автор: Idsa 17.6.2009, 11:36 |
| 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 |
| Автор: amarenkov 17.6.2009, 11:48 |
| Idsa, спасибо. Попробую LINQ и SQL Server. |
