Разница в OODBMS - RDBMS и какая из них подходит для системы управления предприятием

Question

Я немного искал различия между OODBMS и РСУБД. Я в значительной степени знаю, что это такое. Однако, как я буду решать, какой из них лучше для каких приложений. Может ли кто-нибудь любезно помочь мне, пожалуйста?

Что я имел в виду для управления заводом: есть производственные линии для производства бутилированных, замороженных и других продуктов питания. Приложению удается назначить персонал на линии, чтобы сохранить производственные записи в системе. Какие dbms лучше для таких систем?

Заранее благодарен.

Answer 1

Вот хорошая статья Рик Grehan, который описывает случаи, когда ООСУБД полезны: http://www.odbms.org/wp-content/uploads/2013/11/006.04-Grehan-When-to-Use-an-ODBMS-2005.pdf

Answer 2

Это зависит от используемого слоя приложения. Если это простой подход к процедурной процедуре [которая также может иметь классы], то СУРБД более подходит. В противном случае, если вы больше ориентируетесь на строгую объектно-ориентированную систему, то можно использовать OODBMS.

Answer 3

Отказ от ответственности: это ответ «старого кумира», от парня, который написал много совершенно функционального учета, изготовления и другого кода, прежде чем ООП вошел в мейнстрим.
С учетом этого ...

Управление фабрикой - это классическая реляционная база данных, это то, что было придумано. Код для классических реляционных приложений имеет тенденцию следовать очень предсказуемым шаблонам, множеству циклов по извлеченным строкам из таблиц или прямым сквозным вещам: передача данных до пользовательского интерфейса или до базы данных. Если ваша БД хорошо разработана, логика логики, которую вы кодируете, будет детализирована в этих циклах или сквозных проходах, но эти два шаблона будут доминировать.

OODMS, с другой стороны, с точки зрения этого «старого заклинателя» пытается переделать идеально и эффективно функциональную RDBMS во что-то, что будет работать с классами/объектами, без видимой выгоды над системой, которая зарекомендовала себя на протяжении десятилетий, чтобы работать очень хорошо. Классы имеют мало или ничего общего с классическими шаблонами кода, которые располагаются поверх реляционных баз данных. Фактически, они, как правило, усложняют ситуацию и могут легко мешать. Я не говорю, что не используйте код ООП для работы с базой данных, только ООП был изобретен для другой проблемы, проблемы, с которой приложения базы данных не случаются.

Answer 4

Решение о выборе OODBMS или RDBMS не зависит от конкретного приложения, такого как управление фабрикой/автоматизация. Это зависит от многих критериев, как

1) Программирование Paradigm - Если вы [программист] выбрать для визуализации/реализации в языке OO программирования, то OODBMS подходит для хранения объектов, как непосредственно в базу данных, но Наиболее распространенный тип реляционной СУБД, поскольку он хорошо зарекомендовал себя на коммерческой основе и имеет хороший математический фон.

2) Применение Специфические - Для автоматизации производства/управления быстродействием и быстрым доступом важно. OODBMS быстрее, чем СУБД. Если вы считаете, что для веб-разработки, легкий инструмент, подобный MySQL, подойдет многим.

3) Тренд - Теперь существует парадигма быстро от Legacy/Структурно к объектно-ориентированному программированию. поэтому в этой тенденции OODBMS лучше всего подходит для корпоративных приложений, таких как управление на заводе и т. д.

Answer 5

Я обычно рисую линию полезности в точке, в которой они должны быть интегрированы в корпоративные системы. Если ваш проект не обязательно должен интегрироваться, ODBMS обычно проще или технически лучше. Если вы можете интегрировать через веб-службы или «push/pull» в БД системы предприятия, тогда вы все равно можете использовать ODBMS, но может быть политическое давление на него. (более новая репликация ODBMS/RDBMS, такая как dRS для db4o, может быть хорошей подгонкой). Но если вам нужна жесткая интеграция с устаревшими или корпоративными хранилищами данных, вы обычно вынуждены использовать СУБД по той или иной причине.

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

Я использую ODBMS в течение многих лет и боялся проекта, который требует от меня возврата к чисто реляционному управлению данными. Хотя недавние улучшения в инструментах ORM сделали реляционную систему гораздо более приятной для работы, решение ORM + RDBMS по-прежнему не может идти в ногу с системами ODBMS в нескольких ключевых областях (см. previously mentioned article на odbms.org).