Расширенный дизайн базы данных - Какой самый эффективный способ выполнить следующее

Question

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

Концепция

Я создаю интерфейс администратора, который позволяет владельцу сайта «создавать» набор контента на основе выбранных «контейнеров» контента. В настоящее время интерфейс содержит различные типы данных sql, такие как int, varchar, text и т. Д., И позволяет пользователю выбрать тип данных, пометить его, а затем связать их вместе в группу.

Затем на эту группу ссылаются как на экземпляр набора данных, и ее можно использовать повторно. Например, контейнеры 'title' и 'body' могут использоваться для создания простой страницы, и каждый новый экземпляр этой группы может быть новой страницей.

Выпуск

Проблема, с которой я сталкиваюсь, заключается в том, чтобы ссылаться на эти контейнеры наиболее эффективным способом. Я не могу просто иметь таблицу с идентификатором экземпляра и идентификатором контейнера, потому что нет никакого способа узнать, какой тип контейнера. Например, таблица content-varchar имеет поле id, а затем поле значения в формате varchar. Таблица содержимого-текста имеет поле идентификатора, а затем поле значения в формате текста.

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

Каковы ваши идеи / предложения?

Answer 1

Вы делаете вещи на бесполезно низком уровне.

Вы заново изобретаете реляционную базу данных. Внутри реляционной базы данных.

Вы не можете эффективно управлять каждым небольшим фрагментом данных как строго типизированными реляционными данными.

Один из вариантов - использовать структуры более высокого уровня (не отдельные строки, а составные записи с несколькими связанными вместе вещами).

Другой вариант - использовать только текст. Это проще В конце концов, все это становится текстом, когда HTML отправляется обратно в браузер.

---

"... различные типы данных sql, такие как int, varchar, text и т. Д., И позволяют пользователю выбирать тип данных, маркировать его и затем связывать их вместе в группу."

Группа простых типов == строка. Позволяя пользователю свободно определять таблицу на основе набора типов данных - ну, вы делаете их программистом. Вы создаете интерфейс для дизайна таблицы.

Кстати, множество инструментов уже сделали это для вас. На ум приходят RoR и Django: вы определяете строку в базе данных и шаблон для размещения этих элементов на странице, и функция просмотра, которая показывает, как извлечь строку и сопоставить ее со страницей.

Или

Пометить простые отдельные текстовые поля меткой поля и меткой группы. Гораздо проще Просто текст с двумя ключами. Вы можете выбрать "группу" и использовать пары метка / значение для заполнения шаблона. В Django это одна строка кода для извлечения строк, превращения их в словарь и передачи в шаблон.

Answer 2

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

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

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

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

Решение не было быстрым, но оно было очень гибким, надежным и простым в использовании.

Answer 3

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

Тем не менее, если вы настаиваете, здесь следует сделать несколько замечаний:

• ContentSet определяет один или несколько ContentItems.
• ContentItem может быть одним из нескольких четко определенных примитивных типов, ContentTypes.

Похоже, у вас будет четыре стола:

• content_sets: ContentSets и связанные с ним метаданные, такие как пользователь, создавший каждый, название наборов и т. Д.
• content_items: ContentItems вместе с внешним ключом к ContentSet, к которому они принадлежат.
• content_types: список возможных типов, которые можно сохранить в каждом ContentItem. Ваше приложение обеспечит правильность данных, хранящихся в каждом элементе.
• content_groups: экземпляры ContentSets, содержащие реализованные данные и внешний ключ к ContentSet, экземпляром которого они являются. Используйте свойство bag / blob / text field для хранения самих данных.

Answer 4

Вот что руководство MySQL говорит о полях TEXT и BLOB:

В большинстве случаев вы можете рассматривать столбец BLOB как столбец VARBINARY, который может быть настолько большим, насколько вам нравится. Аналогично, вы можете рассматривать столбец TEXT как столбец VARCHAR.

Перевод: использование всех столбцов TEXT или BLOB не приведет к потере места. MySQL будет обрезать то, что не использует (как в VARCHAR).