Мой опыт:
- RDBMS:
- Честно говоря, мне не нравится работать с SQL, языком 15-летней давности, но реальность такова, что вы вынуждены делать это, если вам нужно что-то полезное, например, массовые вставки (среда ORM LINQ-to-Entity не поддерживает массовые вставки, поэтому для 20 000 записей требуется 30 секунд, по сравнению с 500 мс для массовой вставки в SQL). В конечном итоге вам придется использовать ADO.NET для вставки базы данных.
- Существуют некоторые преимущества СУБД по сравнению с объектной базой данных, а именно, данные не зависят от вызывающего приложения (однако это также является недостатком, поскольку уровень отображения делает все медленнее, более сложным и более хрупким).
- Итог: Потратил 6 недель на среду ORM LINQ-to-Entity и Microsoft SQL Server 2008 R2. Достаточно крутая кривая обучения.
- Объектные базы данных: Пробовал объектную базу данных, а именно, бесплатную, с открытым исходным кодом db4o .
- Обнаружено, что я могу сохранить свои объекты с помощью одной строки кода.
- Нет изменений схемы, чтобы справиться, это просто сработало.
- Мгновенная поддержка POCO (Plain Old Class Objects). Создайте свой класс в коде, затем сохраните его. Это возможно сделать то же самое с платформой Entity, однако, это много работы с ручным отображением, и это очень легко ломается.
- Включите прозрачное постоянство, и оно автоматически выполняет отложенную загрузку в фоновом режиме - больше не нужно проверять объекты, которые не загружены из-за отложенной загрузки в платформе Entity.
- Производительность объектных баз данных также впечатляет: если у вас есть 10 миллионов строк в объектной базе данных и включена индексация, ее 16 мс для выбора из трех столбцов. Это прилично.
- Итог: Через 1 неделю у меня было такое же решение, что и использование СУБД для обеспечения устойчивости, однако это было намного чище, намного меньше кода и более легко обслуживаемо - и если Я действительно хотел бы использовать службу для синхронизации базы данных db4o с MSSQL.
Для действительно больших систем в корпоративном мире, состоящих, скажем, из 250 миллионов строк в таблице, таких как sharding и таких опций, как кластеризованная индексация против non- кластерная индексация становится важной для производительности. В этом случае db4o не будет работать, это может потребовать чего-то более корпоративного. Однако, если вы тривиально простой способ сохранения объектов, тогда объектная база данных будет отвечать всем требованиям. Вся работа по изучению SQL, настройке отображения в ORM, работе с установкой MSSQL, реализации ваших собственных процедур массовой загрузки и т. Д. Просто исчезает, оставляя вам чистый, элегантный 100% -ный управляемый код.
Я подозреваю, что одна из причин того, что поставщики не приняли объектные базы данных, это то, что рынок баз данных стоит 3 миллиарда долларов в год, и пока нет причин убивать дойную корову.
Отказ от ответственности: я не связан ни с Microsoft , ни с db4o .