Дизайн базы данных. Следует ли избегать отношений "один-к-одному"?

Возможный дубликат:
Есть ли время, когда использование отношения базы данных 1:1 имеет смысл?

Для простоты я задам прямо вопрос: следует ли избегать взаимных отношений в дизайне базы данных или это приемлемо?

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

Через пользовательский интерфейс, мы надеемся, что это нарисует лучшую картинку, у меня есть основная форма со всеми необходимыми атрибутами. У меня будет кнопка, которая позволит пользователю щелкнуть по ней, и она откроет новую форму для добавления дополнительных атрибутов. Не более 1 записи могут быть связаны с основной формой (сущностью), т.е. Это конечное отношение 0..1.

Любые советы будут оценены.

Ответ 1

Нет, отношения 1:1 могут иметь смысл.

Представьте себе сущность, которая необязательно имеет ведро, полное атрибутов - у некоторых из ваших объектов есть те, другие - нет.

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

Или: вы можете поместить эти "необязательные" атрибуты в отдельную таблицу, настроить связь 1:1 (или скорее: 0: 1) с базой данных сущностей и хранить только вещи в том случае, если ваш субъект действительно имеет эти атрибуты.

Основными критериями для принятия решения о том, следует ли "аутсорсинг" некоторых атрибутов в отдельную таблицу, будет:

Сколько атрибутов это касается? Если это один или два - не переходите к длинам, чтобы поместить их в отдельные таблицы. Но если вы говорите о 8, 10, 15 - тогда рассмотрите его
сколько из базовых объектов могут иметь эти необязательные атрибуты? Опять же: если 95% всех объектов всегда будут иметь все эти атрибуты, то нет смысла делать этот дополнительный шаг. Если только половина или меньше ваших объектов будут иметь эти атрибуты → я определенно рассмотрю такую таблицу

Ответ 2

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

Ответ 3

Зависит от требований приложения

Как правило, я бы сказал, что отношения "один к одному" моделируются как столбцы в таблице, однако существуют обстоятельства, когда это слишком ограничительно:

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

Я видел таблицы, в которых отношения 1 > 1 разделяются между таблицами в вертикальном окошке и базами данных с высокими требованиями к индексу.

Вы можете разделить и абстракционировать до такой степени, что вы получите что-то в строках структуры Entity-attribute-value.. которая это не всегда то, что вы хотите (добавленная сложность, производительность), если это не требует ваше приложение. Как говорит marc_s, вы хотите избежать этого, когда это возможно.

Ответ 4

Есть два сценария, в которых это может иметь смысл:

A кусок необязательных атрибутов, которые могут быть связаны с основным объектом, что делает его отношением 1: [0-1]. Это также может использоваться для представления полей подкласса при выполнении объектно-реляционного сопоставления.
A денормализация производительности, когда это делается как часть физического дизайна. Если дополнительные атрибуты редко необходимы, их можно отбросить в отдельную таблицу, в которую можно вступить, если необходимо. Однако этот метод, вероятно, не понадобится, если ваша база данных может оптимизировать с помощью охватывающего индекса или материализованный вид, чтобы создать физическое представление часто посещаемого подмножества данных.

Ответ 5

Если все элементы будут иметь все атрибуты, одна таблица имеет смысл.

Если некоторые элементы будут иметь только некоторые атрибуты, использование нескольких таблиц имеет смысл.

Чтобы сделать ORM более эффективным, может показаться что-то вроде ленивого атрибута. Дело в том, что все еще довольно редко; не беспокойтесь о оптимизации, если вы действительно не думаете, что это будет проблемой. Преждевременная оптимизация не является эффективным местом для проведения вашего времени по определению.