Кто-нибудь может подумать о каких-то веских причинах * не * использовать объектно-ориентированную СУБД для поддержки сайта?

Question

Скажем, вы кодируете какое-то веб-приложение. Что-то, где люди могут вносить контент, например простой сайт для обмена фотографиями.

Сколько веских причин вы можете назвать , а не с объектно-ориентированной базой данных (например, db4o)?

Answer 1

OODBMS лучше, если вам нужен только доступ к вашим данным через ваши объекты. Если вашему решению требуются дополнительные пути к вашим данным (например, специальные запросы, отчеты, другие приложения, которым необходим доступ к данным, но которые не могут использовать ваши объекты), тогда традиционная система RDBMS лучше.

Примечание. В этой области OODBMS значительно улучшены.

Answer 2

Я бы сказал тот факт, что если вы рассматриваете что-то вроде db4o, то у них, похоже, нет корпоративных примеров питания сайтов, и они в основном используются для встроенных приложений.

Смотрите мой другой пост по этому вопросу. ( Примеры сайтов, использующих db4o )

Ничего технически здесь, просто усыновление кажется. Однако, для скорости разработки, поддержки и гибкости проектирования, OODB довольно непобедимы.

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

Answer 3

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

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

Answer 4

Это немного натянуто, но, перефразируя пост Джоэла, планируйте успех. Что если ваше приложение станет действительно популярным?

Например, что делать, если вы размещаете свое приложение на своем компьютере, но решаете перейти на официальный хостинг или даже на ферму серверов. Каковы шансы, что они будут поддерживать OODB по сравнению с MySQL?

Answer 5

Для сообщения с db4o, пожалуйста, смотрите:

http://developer.db4o.com/Resources/view.aspx/Reference/Implementation_Strategies/Reporting/

Answer 6

Я бы порекомендовал использовать OODBMS только в том случае, если дизайн вашего приложения действительно, действительно сильно ориентирован на объекты, а сложность представляет собой необходимость. Сайт для обмена фотографиями не выглядит слишком тяжелым с точки зрения OO, поэтому я не вижу смысла переходить на db4o.

Однако, если вы действительно хотите изучить все тонкости использования OODBMS из проекта с домашним животным, то лучше использовать один.

Answer 7

Размер данных (Если я имею дело с миллионами и миллионами строк, я придерживаюсь того, что знаю)

Отчетность (как правило, достаточно сложно в нормализованных базах данных, хуже в базах данных OO)

Наличие опыта / опыта (СУРБД явно имеют больше приверженцев)

Большое количество ETL (большинство людей импортируют и экспортируют в виде плоских файлов, если вы не получаете / отправляете XML, вы говорите просто о старых таблицах)

Ничто из этого не похоже на препятствия для вашего проекта

Answer 8

Еще одна веская причина - относительная долговечность. db40 - превосходный продукт для своих целей, но его пользовательская база невелика и вряд ли переживет что-то вроде SQL Server.

Конечно, я также говорил, что Java никак не выживет.

Answer 9

В сложных приложениях со скромными потребностями в данных вы не можете превзойти GLASS (Gemstone, Seaside и Smalltalk). Отчетность - это определенно то, что вы хотите сделать OO в Smalltalk.

Answer 10

Может быть, вы, ребята, тоже хотите проверить эту статью:

http://microsoft.apress.com/asptodayarchive/74063/using-an-object-oriented-d

«Использование OODB на веб-сайте» Джима Патерсона

Best!