Унаследованная таблица в SQL Server 2008. Проблемы с производительностью?

Question

У меня есть идея, которую я обдумывал, основываясь на другой концепции, которую я где-то читал.В основном у вас есть одна «Первичная» таблица с очень небольшим количеством полей, другие таблицы наследуют эту первичную таблицу через внешний ключ.Это много было сделано раньше, так что никаких новостей.Я хотел бы, чтобы практически каждая таблица в базе данных наследовала эту Первичную таблицу.Таким образом, каждый объект, каждая запись, каждая запись в каждой таблице может иметь полностью уникальный первичный ключ (поскольку PK фактически хранится в основной таблице), и на него можно просто ссылаться по ID, а не по таблице.

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

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

Кто-нибудь пытался сделать что-нибудь подобное, и каковы были ваши результаты?

Answer 1

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

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

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

Answer 2

1. Да, основная таблица почти наверняка станет узким местом.
2. Как вы обеспечиваете реальную ссылочную целостность?
   Например, как вы можете быть уверены, что FK транзакции действительно связан с инвентарем, счетом, контактом или заказом, а не с яблоком, апельсином или ананасом?

Answer 3

Я думаю, что это было бы ужасным узким местом. Мало того, что это сильно затруднит соблюдение реальных отношений ПК / ФК. Это может создать кошмар целостности данных. Я не вижу, где вы вообще получаете какую-либо выгоду.