Внешний ключ с большим столом и маленьким столом

Отношения внешнего ключа с большим столом оказывают какое-либо влияние на производительность?Внешний ключ с большим столом и маленьким столом

CREATE TABLE CHARTOFACCOUNT --Contains all accounts 
(
    AccountNo VARCHAR(23) PRIMARY KEY, 
    --, 
) 

CREATE TABLE DEPOSITACCOUNT --Contains all deposit accounts(row less than CHARTOFACCOUNT) 
(
    AccountNo VARCHAR(23) PRIMARY KEY, 
    --, 
) 

CREATE TABLE DEPOSITACCOUNTSTATUS --Contains all Deposit account status 1 to 1 relation 
(
    AccountNo VARCHAR(23) PRIMARY KEY, 
    --,  
)

DEPOSITACCOUNT имеет внешний ключ отношения с CHARTOFACCOUNT. Теперь, когда он пришел для DEPOSITACCOUNTSTATUS, я мог бы сделать отношение внешнего ключа с DEPOSITACCOUNT или CHARTOFACCOUNT и оба будут действительны. Но поскольку CHARTOFACCOUNT содержит больше строк, чем DEPOSITACCOUNT, существует ли проблема с производительностью?

источник

2016-10-19 Esty

Какой у вас dbms? (Вопросы производительности почти всегда зависят от продукта.) – jarlh

в настоящее время для MS SQL Server 2012 и более поздних версий, но я бы предпочел узнать, есть ли у других проблемы. – Esty

Первичные ключи для целых чисел работают лучше, чем на varchars. –

Это звучит как случай преждевременной оптимизации.

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

Вы говорите:

Я мог бы сделать внешний ключ отношения с DEPOSITACCOUNT или CHARTOFACCOUNT и оба будут действительны

Это заставляет меня думать, что вы могли бы иметь проблемы с вашим дизайном. Что хранит таблица таблиц CHARTOFACCOUNT, которая отличается от таблицы DEPOSITACCOUNT?

Почему учетные записи по-разному относятся к другим типам счетов? Почему бы не сохранить их в таблице Account с типом, являющимся атрибутом?

И почему статус депозитной учетной записи хранится отдельно от самой учетной записи? Если между таблицами существует взаимно однозначная взаимосвязь, вы можете переместить эту информацию в таблицу Account.

источник

2016-10-19 10:03:45 Tony

посмотреть 'CHARTOFACCOUNT' содержит все учетные записи и общую информацию о них, где, поскольку' DEPOSITACCOUNT' содержит только депозитные счета и депонирует соответствующую информацию. Проблема с дизайном не существует. Проблема дизайна заключается в том, что я могу объединить таблицу DEPOSITACCOUNTSTATUS с 'DEPOSITACCOUNT', так как они содержат одинаковое количество строк с 1 по 1. Но в этой ситуации лучше было бы использовать таблицу с' DEPOSITACCOUNTSTATUS' ??? – Esty

Если вы не хотите комбинировать статус учетной записи с таблицей депозитов, то логически она должна иметь внешний ключ в таблице 'DEPOITACCOUNT'. В конце концов, это статус депозитного счета. – Tony

Да, в данный момент это было так. Но поскольку «CHARTOFACCOUNT» содержит все депозитные счета, тогда, если я свяжусь с ним вместо «DEPOSITACCOUNT», целостность данных не будет нарушена. Но есть ли здесь улов? – Esty

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

Вы должны настроить свои отношения, чтобы они имели смысл. Из схемы именования я бы предположил, что DepositAccountStatus связан с DepositAccount. Следовательно, я бы поставил отношение внешнего ключа к этой таблице.

Это не проблема с производительностью. Это просто правильное моделирование данных.

Другой вопрос, почему таблица состояния имеет тот же первичный ключ, что и DepositAccount. Почему бы просто не поставить статус прямо в эту таблицу?

источник

2016-10-19 10:46:39

Вы попали в точный босс. Использование другой таблицы DEPOSITACCOUNTSTATUS действительно плохой дизайн. – Esty

Внешний ключ с большим столом и маленьким столом

ответ

Смежные вопросы