Низкая связь и соединения SQL

Question

Скажи, у меня есть стол people (id, firstname, lastname).

Есть две другие таблицы, которые должны содержать эти поля, поэтому мы просто повторно используем таблицу people: users (id, username, person_id) и companies (id, name, contact_person_id).

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

Это настоящая проблема? Моя структура БД имеет недостатки? Есть ли решение для поддержания низкой связи, например, ORM?

Спасибо за все ответы.

Answer 1

Соединение - это концепция, основанная на программных модулях.

Я не вижу отношения к SQL.

Поскольку обе таблицы находятся на одном и том же сервере, они уже связаны (что касается программного обеспечения, использующего сервер). Я просто не вижу, какого низкого сцепления вы пытаетесь достичь.

Из Википедия :

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

Answer 2

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

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

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

Этохороший дизайн базы данных.

Answer 3

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

Является ли это реальной проблемой?Моя структура БД имеет недостатки?

Нет, ваша структура не имеет недостатков в этом контексте.Ваше восприятие этого неверно.

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

Допустим, вы извлекаете код своей базы данных из своей системы управления версиями и меняете имена столбцов в своей таблице "people" на first_name, last_name.Без каких-либо других изменений вы не сможете перестроить базу данных, потому что вы нарушили публичный интерфейс.(Представления, которые выбирают «firstname», убивают сборку. Хранимые процедуры, которые читают или записывают в «firstname», убивают сборку.)

Но вы можете быстро восстановить это, переименовав таблицу «people» и создаввид.Вы можете идти вперед, как это.

• Переименуйте "people" в "people".
• Создайте представление с именем "people".(SELECT * FROM persons;)
• В представлении создайте псевдонимы для двух измененных столбцов, присваивая псевдонимы от имени до имени, а от фамилии до фамилии.
• Если ваша база данных не поддерживает нативно обновляемые представления,напишите любой процедурный код, который вам нужен, чтобы сделать представление обновляемым.

Любой код, который должен запрашивать или обновлять базовую таблицу с именем "people", вместо этого будет запрашивать и обновлять представление с именем "people".Никакой другой код не должен быть переписан.(Если у вас нет кода, который делает необоснованные предположения о том, работает ли он с базовой таблицей.)

Реляционные базы данных реализуют логическую независимость данных через обновляемые представления.

Answer 4

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

Системы управления реляционными базами данных позволяют создавать специальные типы данных, которые значительно упрощают определенные модификации.Если FirstName и LastName были определены как определяемый пользователем тип PersonName, то при изменении типа такое же изменение будет отображаться во всех запросах и хранимых процедурах, использующих столбцы.К сожалению, вряд ли кто-нибудь когда-либо использует определяемые пользователем типы данных.

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