Каковы преимущества использования отношения «один к одному» таблицы, а не просто хранения всех данных в одной таблице? Я все время понимаю и использую «один-ко-многим», «много-к-одному» и «многие-ко-многим», но реализация взаимно-однозначных отношений кажется утомительной и ненужной задачей, особенно если вы используете именование соглашения для привязки (php) объектов к таблицам базы данных.
Я не мог найти что-либо в сети или на этом сайте, что могло бы послужить хорошим реальным примером отношений «один к одному». Сначала я подумал, что было бы логично разделить «пользователей», например, на две таблицы, одну из которых содержит общедоступную информацию, например «обо мне» для страниц профиля, а также одну личную информацию, такую как логин / пароль и т. Д. Но зачем идти через все проблемы с использованием ненужных JOINS, когда вы можете просто выбрать, какие поля выбрать из этой таблицы? Если я покажу страницу профиля пользователя, я бы выбрал только SELECT id, имя пользователя, адрес электронной почты, aboutme и т. Д., А не поля, содержащие их личную информацию.
Кто-нибудь хочет просветить меня некоторыми реальными примерами отношений «один-к-одному»?
Я использовал отношения один к одному для расширения некоторых функций в существующих приложениях, не затрагивая структуру приложения db. Это ненавязчивый способ расширения существующих таблиц db .
Другая причина использования отношения «один-к-одному» заключается в реализации наследования класса Class , в которой каждый класс в иерархии имеет таблицу, а объект имеет соответствующую строку в своем классе таблицы в своей таблице родительских классов в своем классе бабушки и дедушки стол и так далее.
См., Например, страницу наследования на уровне класса Doctrine 2
Одно из возможных вариантов использования – это когда часть информации является необязательной. Таким образом, вам не нужно иметь пустые поля с нулевым значением в одной большой таблице, но можно логически отделить его от обязательной таблицы и необязательной таблицы.
Другое использование – когда некоторые данные разделяются с разными таблицами. Например, скажем, у вас есть сайт, на котором вы продаете компьютерные части. Вы можете разместить детали, на которые распространяются все компоненты, например. таблицу «parts», но поместили специфику в «материнские платы», «cpus» и т. д., которые просто использовали бы таблицу деталей с отношением «один к одному».
Вот два, я уверен, что другие будут публиковать больше
Кроме того, при нормализации базы данных, скажем, в 3-й нормальной форме (3NF), вы можете обнаружить, что у вас есть столбцы, которые на самом деле не «о» ключевом, и их нужно вытащить в отдельную таблицу.
В частности, для вашего примера: вы не хотите, чтобы информация пользователя, такая как имя и адрес, хранилась в той же таблице, что и информация о логине и пароле, потому что таким образом вы можете предоставить кому-либо в вашей организации разрешение на пользовательскую информационную таблицу, а не на логин Таблица данных. Я не согласен с другими в теме «слишком много полей для одной таблицы». Если есть много полей, и вам не нужны все они в вашей форме или отчете, вы можете выбрать только нужные вам поля с помощью sql или даже использовать представление, чтобы убедиться, что вы не получаете слишком много данных.
Наиболее распространенная причина заключается в том, что отношения могут быть необязательными. т.е. существует набор атрибутов, применимых к каждому базовому объекту, но некоторые атрибуты, которые применяются только к подмножеству.
Другой важной причиной для этого является контроль прав доступа – у вас может быть таблица клиентов, используемая в вашем приложении, и хотя у каждого клиента есть пароль и кредитная карта, вы можете ограничить права на доступность / обновление.
Комментарий Марги Квевелара относительно ответа Игнасио Васкеса-Абрамса неверен. Вы можете смягчить воздействие, используя лучший DML / DDL, но не во всех случаях. Однако вы торгуете прозрачностью модели данных в сравнении с преимуществами производительности, что всегда необходимо тщательно рассмотреть.
C.
Механизму базы данных, возможно, придется загружать целые строки в память, чтобы извлекать данные из них, даже если считывается только подмножество полей. Меньшее количество полей в строке означает больше строк на странице, что означает меньшее количество обращений к диску.
В OO у вас есть наследство. Таким образом, у вас может быть таблица, содержащая данные родительского объекта, и другие таблицы, содержащие поля, которые являются конкретными для детей.
Мы использовали отношения «один к одному», когда нам нужно было расширить одну из наших таблиц со слишком большим количеством полей (96 полей!); поэтому мы создали другую таблицу и помещаем в нее все новое поле.
Во всяком случае, мне нравится такой подход:
Table_Base: ID MANDATORY_FIELD Table_Option: ID OPTIONAL_FIELD В дополнение к тому, что уже было сказано,
некоторые столбцы могут иметь разные требования к обеспечению безопасности, чем другие. Например, имя сотрудника может быть «немного более публичным», чем его зарплата. Теперь безопасность на уровне столбцов обычно не применяется СУБД, но часто возникает проблема безопасности на уровне таблиц.
Таким образом, выделяя зарплату в отдельной таблице, вы покупаете себе возможность реализовать требования безопасности пользователя, используя только средства безопасности СУБД.
Еще одна вещь, основанная на моем опыте, о котором не упоминалось:
Разделение на две таблицы также помогает при создании классов модели. Допустим, у вас есть таблица Customers и таблица DriverLicense и отношения между ними один к одному. Если вы используете инфраструктуру сущности, я готов поспорить, что должно быть лучше, если у вас есть две отдельные таблицы, поскольку в вашем приложении могут быть два класса моделей, класс Customer и DriverLicense. Таким образом, структура сущностей упростит добавление новой информации о лицензии на драйверы позже существующему клиенту или удаление и обновление. Вкратце, учитывая также сторону веб-разработки, я считаю, что если они представляют собой две разные сущности, они должны иметь свои собственные таблицы, даже если они имеют отношения «один-к-одному».