Внешний ключ с большой таблицей против маленькой таблицы

ProgramBox

Внешний ключ с большой таблицей против маленькой таблицы

Post author:admin
Запись опубликована:25 марта, 2023
Post category:Вопросы по программированию

#sql #sql-server #foreign-key-relationship

#sql #sql-сервер #отношение внешнего ключа

Вопрос:

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

 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 , существует ли какая-либо проблема с производительностью?

1. Какую СУБД вы используете? (Вопросы производительности почти всегда зависят от конкретного продукта.)

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

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

4. @AbdulRehmanSayed согласен. Но это не было моей заботой.

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

Ответ №1:

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

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

Вы говорите:

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

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

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

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

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

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

3. Да, в настоящее время это тоже было так. Но так как CHARTOFACCOUNT содержит все депозитные счета, то, если я сделаю связь с ним вместо DEPOSITACCOUNT целостности данных, это не будет нарушено. Но есть ли здесь какой-то подвох?

4. Извините, я не совсем понимаю, что вы подразумеваете под «целостность данных не будет нарушена» — почему установка внешнего ключа в DEPOSITACCOUNT таблицу приведет к нарушению целостности?

5. Я должен вернуть вас к первой строке моего ответа: это звучит как случай преждевременной оптимизации. Если у вас нет собственного доказательства проблемы с производительностью, поместите внешний ключ туда, где это имеет наибольший смысл . Ранее я работал с таблицами SQL Server, содержащими более 250 миллионов строк, и мы не думали о производительности, а не о дизайне, и у нас никогда не было проблем со скоростью вставок.

Ответ №2:

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

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

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

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