Это плохо для использования избыточных отношений?

Не является ли плохой практикой давать каждой другой таблице (избыточное) отношение к таблице Company для упрощения моих запросов sql?

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

Если вы хотите просто упростить ваш SQL, рассмотрите возможность использования представлений для «переноса» родительских данных. Вот представление, которое втягивает company_id в контракт путем присоединения через клиента:

create view contract_customer as
select 
  a.*, 
  b.contract_id, b.company_id
from 
  contract a 
  join customer b on (a.customer_id = b.customer_id);

Это соединение простое, но зачем повторять его снова и снова? Напишите его один раз, а затем используйте представление в других запросах.

Многие (но не все) СУБД могут даже оптимизировать объединение, если вы не помещаете столбцы от клиента в список выбора или предложение where запроса, основанного на представлении, при условии, что вы указали контракт .customer_id ограничение ссылочной целостности внешнего ключа на customer.customer_id.(При отсутствии такого ограничения соединение не может быть пропущено, потому что в этом случае может существовать contract.customer_id, которого не было у клиента. Поскольку вы никогда не захотите , что , вы добавите ограничение внешнего ключа.)

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

Если вам действительно нужно все упростить, то здесь пригодится View (или несколько представлений).

Наличие столбца для компании в вашем представлении сотрудника не будет плохо нормализовано, если он получен из соединения с разделом.

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

Я бы сказал, что не в случае ОП, но иногда это полезно (как и goto ;)).

Анекдот:

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

Это зависит от ваших функциональных требований к «Производительности». Будет ли ваше приложение удовлетворять большой спрос? Упрощение JOINS может похвастаться производительностью. Кроме того, оборудование дешевое, и время на его обслуживание очень важно.

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

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