Как бороться со смешанными базами данных?

Question

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

• набор файлов и дополнительная информация о каждом из них, хранящаяся в реляционной базе данных SQL.
• OODB вместе с тройным магазином.
• два ранее совершенно не связанных хранилища данных ключ / значение, которые должны быть интегрированы, но храниться отдельно.

Как вы думаете, это лучший способ справиться с такой ситуацией? разделить два типа данных и написать программный слой, который будет синхронизировать их? использовать только один тип базы данных, адаптировать один тип данных к другому (например, сохранить файл в реляционной базе данных в виде большого двоичного объекта или сохранить реляционную часть в взломанной файловой базе данных на диске)?

Answer 1

Этот тип проблемы известен как системы федеративных баз данных. Я бы рекомендовал прочитать статью о федеративных базах данных в wikipedia .

Это непростая ситуация, и решение этой проблемы во многом зависит от того, насколько тесно связаны между собой / связаны данные в ваших разных «базах данных», а также от того, насколько похожа схема разных «баз данных».

Answer 2

Вы описываете проблему, решаемую механизмами виртуальных баз данных (также называемыми объединенными системами СУБД).

Я подозреваю, что идеальная ситуация для вас - это Концептуальный уровень, который расположен на разных логических источниках, которые могут представлять собой любую комбинацию: реляционные механизмы управления базами данных (позади ERP, CRM, HR, системы учета), веб-сервисы, XML и т. Д.

Virtuoso (продукт моей компании) справляется с этим, позволяя вам подключать внешние / удаленные источники данных, связанные с множеством форматов представления данных (согласно списку выше). Затем он позволяет использовать модель EAV / CR (например, модель графика RDF) в качестве основы для концептуального уровня, который является одновременно конкретным и фокусом всего последующего взаимодействия с данными. Этот концептуальный уровень наделяет каждый элемент данных идентификатором на основе схемы HTTP; таким образом, вам нужен только пользовательский агент с поддержкой HTTP, когда вы начинаете изучать богатый концептуальный граф, который теперь направлен на ваши разнородные логические источники данных.

То, что я описал выше, в основном то, что сегодня широко известно как: связанные данные на основе HTTP.

Ссылки:

1. http://virtuoso.openlinksw.com

Кингсли

Answer 3

Я не думаю, что "объединение" двух миров было бы хорошей вещью (производительность, маневренность и так далее). Во-первых, это хорошо для меня, держите их отдельно и отделяйте их от бизнес-логики слоем. Работа со слабосвязанным слоем имеет много преимуществ. Этого можно добиться с помощью шаблонов проектирования или работы с интерфейсами / абстрактными классами.