Что преимуществами использования является непосредственная связь между таблицами? (MySQL)
Что преимуществами использования является непосредственная связь между таблицами в противоположность тому, чтобы просто хранить все данные в одной таблице? Я понимаю и использую one-many, many-one, и many-many все время, но реализация непосредственных отношений походит на утомительную и ненужную задачу, особенно при использовании соглашений о присвоении имен для связи (php), возражает против таблиц базы данных.
Я ничего не мог найти в сети или на этом сайте, который мог предоставить хороший реальный пример непосредственных отношений. Сначала я думал, что могло бы быть логично разделить 'пользователей', например, в две таблицы, одна содержащая общедоступную информацию как 'обо мне' для страниц профиля и одной содержащей частную информацию, таких как вход в систему/пароль, и т.д. Но почему проходят всю проблему использовать ненужные СОЕДИНЕНИЯ, когда можно просто выбрать который поля выбрать из той таблицы так или иначе? Если бы я отображаю страницу профиля пользователя, очевидно, я только ВЫБРАЛ бы идентификатор, имя пользователя, электронную почту, aboutme и т.д. а не поля, содержащие их частную информацию.
Кто-либо хочет просветить меня с некоторыми реальными примерами непосредственных отношений?
9 ответов
Я использовал взаимосвязь «один к одному» для расширения некоторых функций в существующих приложениях, не затрагивая структуру базы данных приложения. Это ненавязчивый способ расширения существующих таблиц БД .
Другой причиной использования взаимно-однозначного отношения является реализация Наследования таблиц классов , в которой каждый класс в иерархии имеет таблицу, а объект имеет соответствующую строку в своем классе таблицы в таблица его родительского класса, таблица классов его бабушки и дедушки и так далее.
См., Например, Doctrine 2 Страница наследования таблицы классов
Мы использовали «отношение один к одному», когда нам нужно было расширить одну из наших таблиц слишком большим количеством полей (96 полей!); Итак, мы создали еще одну таблицу и поместили в нее все новые поля.
В любом случае, мне нравится такой подход:
Table_Base:
ID
MANDATORY_FIELD
Table_Option:
ID
OPTIONAL_FIELD
Вот два, я уверен, что другие опубликуют еще
- , если вы хотите расширить существующую таблицу без фактического изменения таблицы. Возможно, он был предоставлен сторонним поставщиком, и вы хотите, чтобы ваши расширения были разделены, просто имея вторую таблицу с тем же ключом.
- возможно, в таблице есть столбцы фиксированной ширины, к которым часто обращаются, и столбцы переменной ширины, к которым нет. В этом случае можно добиться повышения эффективности за счет наличия таблицы с фиксированной длиной строки для часто используемых материалов и вспомогательной таблицей для всего остального.
Кроме того, при нормализации базы данных, скажем, в 3-й нормальной форме (3NF) вы можете обнаружить, что у вас есть столбцы, которые на самом деле не связаны с ключом, и их нужно вытащить в отдельный стол.
В дополнение к тому, что уже было сказано,
в некоторых столбцах могут быть другие требования к «допуску к секретности», чем в других. Например. имя сотрудника может быть «немного более публичным», чем его зарплата. Теперь СУБД обычно не обеспечивает безопасность на уровне столбцов, но часто обеспечивает безопасность на уровне таблиц.
Таким образом, выделив зарплату в отдельной таблице, вы покупаете возможность реализовать требования безопасности пользователя, используя только средства безопасности СУБД.
Механизму базы данных может потребоваться загрузить целые строки в память, чтобы извлечь из них данные, даже если считывается только подмножество полей. Меньшее количество полей в строке означает больше строк на странице, что означает меньшее количество обращений к диску.
Конкретно для вашего примера: Вы не хотите, чтобы информация пользователя, такая как имя и адрес, сохранялась в той же таблице, что и информация для входа в систему и пароля, потому что таким образом вы можете предоставить кому-либо в своей организации разрешение на таблицу сведений о пользователях, а не на таблицу данных для входа. Я не согласен с другими по теме «слишком много полей для одной таблицы». Если полей много и они все не нужны в форме или отчете, вы можете выбрать только нужные поля с помощью sql или даже использовать представление, чтобы не получить слишком много данных.
В OO у вас есть наследство. Таким образом, у вас может быть таблица, содержащая данные родительского объекта, и другие таблицы, содержащие поля, специфичные для дочерних объектов.
Одно из возможных применений - когда часть информации является необязательной. Таким образом, вам не нужно иметь кучу полей, допускающих значение NULL, в одной большой таблице, но вы можете логически разделить ее на обязательную и необязательную таблицы.
Другое использование - это когда некоторые данные используются совместно с разными таблицами. Например, допустим, у вас есть сайт, на котором вы продаете комплектующие для компьютеров. Вы можете указать детали, которые разделяют все компоненты, например. таблица "частей", но укажите специфику "материнские платы", "процессоры" и т. д., которые будут использовать таблицу частей с взаимно-однозначным соотношением.
Наиболее частая причина в том, что отношения могут быть необязательными. т.е. существует набор атрибутов, применимых к каждому базовому объекту, но некоторые атрибуты применяются только к подмножеству.
Еще одна веская причина для этого - контроль прав доступа - у вас может быть таблица клиентов, используемая во всем приложении, и хотя у каждого клиента есть пароль и кредитная карта, вы можете захотеть ограничить права доступа / обновления.
Комментарий Марги Кеувелаар к ответу Игнасио Васкес-Абрамса неверен. Возможно, вы сможете смягчить воздействие, используя более совершенный DML / DDL, но не во всех случаях. Однако вы жертвуете прозрачностью модели данных и преимуществами в производительности, что всегда необходимо тщательно учитывать.
С.