Каковы преимущества использования отношения "один к одному"? (Баз данных)

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

Я не мог найти ничего в сети или на этом сайте, что могло бы послужить хорошим примером взаимного отношения "один к одному". Сначала я подумал, что было бы логично разделить "пользователей", например, на две таблицы, одну из которых содержит общедоступную информацию, например "обо мне" для страниц профиля, а также одну личную информацию, такую ​​как логин/пароль и т.д. Но зачем идти через все проблемы с использованием ненужных JOINS, когда вы можете просто выбрать, какие поля выбрать из этой таблицы? Если я покажу страницу профиля пользователя, я бы выбрал только SELECT id, username, email, aboutme и т.д., А не поля, содержащие их личную информацию.

Кто-нибудь заботится о том, чтобы просвещать меня некоторыми реальными примерами отношений "один-к-одному"?

ОТВЕТЫ

Ответ 1

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

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

См., например, Doctrine 2 Страница наследования таблицы классов

Ответ 2

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

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

Ответ 3

Здесь два, я уверен, что другие отправят больше

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

Кроме того, при нормализации базы данных, скажем, 3-я нормальная форма (3NF), вы можете обнаружить, что у вас есть столбцы, которые на самом деле не являются "о" ключе и нужно вытащить на отдельную таблицу.

Ответ 4

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

Ответ 5

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

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

Марга Квевелар комментирует ответ Игнасио Васкес-Абрамса неверный. Вы можете смягчить воздействие, используя лучший DML/DDL, но не во всех случаях. Однако вы торгуете прозрачностью модели данных в сравнении с преимуществами производительности, которые всегда необходимо тщательно рассмотреть.

С.

Ответ 6

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

Ответ 7

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

Ответ 8

Мы использовали отношения "один к одному", когда нам нужно было расширить один из наших таблиц слишком много полей (96 полей!); поэтому мы создали другую таблицу и помещаем в нее все новое поле.

В любом случае, мне нравится такой подход:

Table_Base:
    ID
    MANDATORY_FIELD
Table_Option:
    ID
    OPTIONAL_FIELD

Ответ 9

В дополнение к уже сказанному,

некоторые столбцы могут иметь разные требования к безопасности, чем другие. Например. имя сотрудника может быть "немного более публичным", чем его зарплата. Теперь безопасность на уровне столбцов обычно не применяется СУБД, но безопасность на уровне таблиц часто бывает.

Таким образом, выделяя зарплату в отдельной таблице, вы покупаете себе возможность реализовать требования безопасности пользователя, используя только средства безопасности СУБД.

Ответ 10

Еще одна вещь, основанная на моем опыте, о котором не упоминалось:

Разделение на две таблицы также помогает при создании классов модели. Допустим, у вас есть таблица Customers и таблица DriverLicense и отношения между ними один к одному. Если вы используете инфраструктуру сущности, я готов поспорить, что должно быть лучше, если у вас есть две отдельные таблицы, поскольку в вашем приложении могут быть два класса моделей, класс Customer и DriverLicense. Таким образом, структура сущностей упростит добавление новой информации о лицензии на драйверы позже существующему клиенту или удаление и обновление. Вкратце, учитывая также сторону веб-разработки, я считаю, что если они представляют собой два разных объекта, они должны иметь свои собственные таблицы, даже если они имеют отношения "один-к-одному".