Оптимальная структура БД для сущности дополнительных полей

Единственный обходной путь (при сохранении вашей структуры) - иметь отдельные таблицы:

create table IntProps(...);
create table StringProps(...);
create table CurrencyProps(...);

Но не думаю, что это хорошая идея ...

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

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

Как насчет этого ... каждый подтип получает свою собственную таблицу БД. А в базовой / супертаблице просто есть столбец varchar, который содержит имя таблицы БД подтипа. Тогда у вас может получиться что-то вроде этого ...

Entity
------
ID
Name
Type
SubTypeName   (value of this column will be 'Dog')


Dog
---
VetName
VetNumber
etc

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

У вас может быть таблица ключей / значений для каждого типа. Доступная таблица должна будет кодировать доступность конкретной пары ключ / тип, чтобы указать на правильно набранную таблицу ключ / значение.

Однако это кажется очень неэффективной архитектурой для реляционных баз данных на основе строк.

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

Дизайн, с которым вы экспериментируете, представляет собой разновидность Сущность-Атрибут-Значение, и в нем есть множество проблем и недостатков. Это не лучшее решение для того, чем вы занимаетесь, кроме как в крайнем случае.

Лучшим решением может быть то, что описывает fallen888: создать таблицу «подтипов» для каждого из ваших подтипов. Это нормально, если у вас есть конечное количество подтипов, что похоже на то, что у вас есть. Тогда ваши атрибуты, зависящие от подтипа, могут иметь типы данных, а также ограничение NOT NULL, если это необходимо, что невозможно, если вы используете дизайн EAV.

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

редактировать: Что касается вашей дополнительной информации о комментариях к любому объекту, да, это довольно распространенный шаблон. Остерегайтесь неработающего решения, называемого «полиморфная ассоциация», который многие люди используют в этой ситуации.

Спасибо за ответы. Я объясню чуть более конкретно, что мне нужно. Есть необходимость запрограммировать сайт блог + форум, и я смотрел Структура БД WordPress.

Существует острая необходимость в возможности размещать комментарии к любому типу «объекта», например, записи в блоге или прикреплению к нему видеофайла. Причиной ее выбора стала указанная выше структура БД, которую легко масштабировать и удовлетворить все наши потребности.

Но еще не поздно изменить это, потому что это находится на стадии ранней разработки. Также наша модель теперь пахнет БД, полностью основанной на древовидной иерархии. А пока я приму Ответы Билла Карвина и падшего 888, но, может быть, я иду совершенно не в том направлении?

о том, что пользователь может добавить новое поле в таблицу:

Я восхищаюсь комментариями всех этих людей.

Раньше я интересовался такими вещами несколько лет назад, но недавно написал немного кода (кроме небольшого количества PHP и MYSQL).

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

Извините, что обливаю схему холодной водой - восхищаюсь вашими усилиями. Я лично считаю, что если вы пойдете достаточно далеко в этом направлении, вы получите систему, которая интерпретирует больше естественного языка, чем SQL. (Примерно в 1970 году SQL фактически назывался Sequel, и это фактически означало «структурированный английский язык запросов», но после того, как они стандартизировали его в 1970-х - я думаю, кто-то сказал, что Oracle была первой коммерческой реализацией, 19079, «английский» получил упал, потому что, я думаю, они решили, что это всего лишь небольшая часть английского языка.

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

Наилучшие пожелания всем.

извините, я написал 19079 выше, я имел в виду 1979 год. Oracle получила свой первый контракт на создание базы данных для ЦРУ.