Проектное решение: динамическое добавление данных вопроса

Question

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

По сути, я хочу динамически добавлять метаданные (или категории) в документ на временной основе. Вот варианты, о которых я подумал:

Вариант 1: Должен ли я сделать это путем динамического создания новых столбцов таблицы в базе данных?

Вариант 2: Должен ли я определить 5 столбцов, называемых attirbute1, attirbute2, attirbute3, attirbute4, attirbute5, а затем использовать и показывать их, только если пользователю требуются атрибуты.

Вариант 3: Должен ли я создать таблицу метаданных, которая отслеживает столбцы и данные, связанные с ними?

Какой, по вашему мнению, лучший способ достичь этого? Можете ли вы придумать какие-либо другие способы легко добавить эту функциональность. Проблема в том, что функциональность должна быть очень общей.

Answer 1

Каждый документ имеет уникальный DocumentID.

Просто добавьте еще одну таблицу с тремя столбцами:

DocumentID
MetaName
MetaData

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

-Adam

Answer 2

Одна вещь, которую вы не уточняете, это то, является ли число и / или имя атрибутов изменяемым или одинаковым для всех документов. Это несколько изменит мою рекомендацию.

Предполагая, что у вас есть дескриптор объекта, который уникально описывает данный документ, я предлагаю таблицу, которая управляет метаданными. Если у вас есть неизвестное количество атрибутов и неизвестные имена этих атрибутов, я рекомендую что-то вроде этого:

create table DocMetaData
(
   DocumentHandle        varchar NOT NULL,
   MetaDataName          varchar NOT NULL,
   MetaDataText          varchar NOT NULL
);

Затем вы вставляете в эту таблицу, когда у вас есть метаданные, используя наиболее подходящее имя. Если нет строки, нет метаданных. Если есть метаданные, у вас явно есть имя для этих метаданных и сами данные. Вы можете включить обнуляемость в самих метаданных, если вам нужно, хотя я бы, вероятно, просто сделал это пустым текстом (что-то вроде default ''), а не пустыми, потому что вы получаете странное поведение (не получайте свою строку!) если вы выбрали столбец, а его там нет, и вы явно не запросили строки с нулевым значением. Помните, что этот дизайн не прописывает unique, поэтому у вас есть возможность, сохраняйте только тогда, когда у вас есть данные ...

Конечно, если известны все возможные атрибуты метаданных, вы можете просто их прописать!

Создание динамических таблиц - КОРОЛЕВСКАЯ боль - я бы не стал делать это здесь.

Answer 3

Это очень похоже на тегирование. Вероятно, вы можете изменить actions-as-taggable , чтобы сделать то, что вам нужно.

Answer 4

Я бы пошел с тремя таблицами.

Документ (Документ)

Категория (Определенные категории)

DocumentCategory (таблица ссылок, связывающая документы с категориями)

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

Answer 5

Я бы пошел с вариантом 3.

Динамическое изменение структуры данных станет очень сложным в обслуживании и может привести к появлению интересных ошибок.

Наличие ряда столбцов, которые могут или не могут понадобиться, все равно увеличит сложность, поскольку вам нужно будет проверить, используется ли каждый столбец. Кроме того, вы все равно будете ограничены 5 столбцами.

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

Answer 6

Я бы, конечно, выбрал вариант 3: иметь таблицу под названием DocumentCategories, в которой хранится категория, к которой принадлежит каждый документ. Он не только «более реляционный», но и поможет, если ваши требования когда-нибудь изменятся: что если вы решите, что завтра вы хотите получить 6 категорий?

Плюс, это дает вам больше возможностей для запросов: что, если вы хотите увидеть, сколько раз использовалась каждая категория, или выбрать документы по категориям? С вариантом 3 это просто соединение, и его можно быстро и легко написать. Варианты 1 и 2 делают выполнение таких простых вещей очень сложным.

Answer 7

Все эти варианты осуществимы, и нет правильного ответа. Вы должны взвесить различные варианты и выбрать лучшее решение для вашей ситуации.

Вариант 1: выполнимо, но может действительно выйти из-под контроля по мере увеличения количества пользователей. Может также влиять на стоимость хранения.

Вариант 2: Вероятно, самое быстрое решение для реализации, но наименее надежное решение и более высокая стоимость обслуживания. Если вам нужно перейти к 6 столбцам, вам придется добавить еще один столбец и т. Д.

Вариант 3: Вероятно, наиболее надежное решение - иметь таблицу метаданных, которая собирает эту информацию, а затем динамически строить таблицы / столбцы на основе этих метаданных. Это решение также, вероятно, займет больше всего времени и будет стоить больше $$.