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

Question

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

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

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

Answer 1

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

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

Answer 2

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

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

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

Answer 3

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

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

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

Answer 4

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

Answer 5

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

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

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

C.

Answer 6

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

Answer 7

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

Answer 8

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

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

Answer 9

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

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

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

Answer 10

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

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

Table_Base:
    ID
    MANDATORY_FIELD
Table_Option:
    ID
    OPTIONAL_FIELD