Как далеко я могу взять этот дизайн базы данных?

Question

Мне интересно знать плюсы и минусы создания собственной системы, поддерживаемой базой данных, подобной описанной ниже:

У него есть 6 таблиц, которые его поддерживают.

Сущность: Скажем, все «физическое», что может существовать, и в нем хранятся детали. (Hilton Hotel, Тони Такси, Бар One)

Тип объекта: Группировка / тип объекта (Бар, гостиница, ресторан)

Метаданные: Любая деталь, описывающая элемент сущности или принадлежащий ему (IR232PH, foo@bar.com, 555-555-555)

Тип метаданных: Группировка / тип метаданных (Почтовый индекс, телефон, электронная почта, адрес)

Взаимосвязь сущностей: Возможность сгруппировать любой элемент сущности в другой (Entity1-Entity2, Entity3)

Тип отношений сущностей: Группировка / тип отношений сущностей.

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

Каковы плюсы / минусы его использования для сущностей, как описано?

• Артист может выступать (тип отношений) на месте.
• Художник может поддерживать (тип отношений) другого художника

Каковы были бы плюсы / минусы его использования для хранения более стандартных объектов, таких как пользователи системы?

• У пользователя может быть любимое (тип отношений) место / исполнитель / бар и т. Д.
• Пользователь может иметь посещающее (тип отношения) событие

Будете ли вы считать, что в нем есть новости и записи в блогах?

Answer 1

Хотя вы, безусловно, можете хранить данные в такой модели данных, есть несколько проблем (по крайней мере) с ней.

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

Вторая проблема - получение данных. Предположим, я хочу знать всю информацию о конкретном отеле? Как мне написать запрос для этого? На самом деле, даже вставить данные сложно, но выбрать их, во всяком случае, сложнее. Если мне нужны только три атрибута, это легко - если в отеле есть все. Сложнее, если в отеле указаны только два из трех. Но предположим, что в отеле 30 атрибутов, что немного. Тогда это ужасно сложно.

То, что вы описываете, является усовершенствованной версией модели, известной как модель данных EAV или Entity-Attribute-Value . Общепринято считать «плохой идеей», для всех это общая идея.

Answer 2

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

В некотором смысле, чтобы быть немного шутливым, ИМХО, то, что вы предлагаете, уже сделано ... Это называется реляционной базой данных. Каждая СУБД - это программный инструмент, предназначенный для моделирования любого возможного набора объектов и их атрибутов таким образом, чтобы точно моделировать эти объекты и отношения между ними.

Answer 3

То, что вы описали, также называется триплетным складом.Тройка - это предикат субъект-объект (Hotel HAS Rooms, Joe Likes HotelX и т. Д.).Существуют механизмы для запуска этих вещей (реализации хранилища триплетов), управления данными (например, с помощью онтологий) и для их запроса (например, язык SPARQL).Тем не менее, это все довольно крутые вещи, и, как известно, имеют проблемы с масштабируемостью.Тем не менее, в сочетании с подходами NoSQL (индексирование всех ваших отелей в большом хранилище документов и т. Д.), Это интересная область, за которой нужно следить.

См .: http://en.wikipedia.org/wiki/Triplestore.