Udai Karan Mathur Ответов: 1

Наличие столбца id в каждой таблице с кластеризованным и некластеризованным индексом


Привет,

В нашей базе данных sql server у нас есть столбец Id в каждой таблице. Этот столбец не является столбцом первичного ключа, но он сделан как столбец идентификатора. У нас есть еще один столбец для первичного ключа. Тип данных этого столбца-guid.

Цель того, что столбец ID в каждой таблице:
1) не следует создавать кластеризованный индекс на столбец GUID.
2) столбец Id очень полезен в случае миграции.

Эта практика была реализована в нашем последнем проекте, но наш текущий клиент сказал, что мы должны удалить столбец Id из каждой таблицы и создать кластеризованный индекс для столбца guid.

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

Пожалуйста, дайте мне знать, должен ли я удалить столбец Id из каждой таблицы или нет.

Ниже приведен пример структуры нашей таблицы:

Создайте таблицу [dbo].[Планрайдер](
[Id] [int] IDENTITY(1,1) NOT NULL,
[PlanRiderId] [uniqueidentifier] NOT NULL,
[CompanyId] [uniqueidentifier] NOT NULL,
[PlanDetailId] [uniqueidentifier] NOT NULL,
[BasePlanId] [uniqueidentifier] NOT NULL,
[RiderPlanId] [uniqueidentifier] NOT NULL,
[RiderType] [varchar](10) NOT NULL,
[CreatedBy] [uniqueidentifier] NULL,
[CreatedDate] [datetime] NULL,
[UpdatedBy] [uniqueidentifier] NULL,
[UpdatedDate] [datetime] NULL,
[PageReference] [nvarchar](100) NULL,
[RowStatus] [int] NULL,
Ограничение [PK_PLanRider] первичный ключ некластеризованный
(
[PlanRiderId] ASC
)С (КАК = ВЫКЛ, STATISTICS_NORECOMPUTE = OFF, ТО ЗНАЧЕНИЕ IGNORE_DUP_KEY = OFF, ТО ПАРАМЕТРЫ ALLOW_ROW_LOCKS = ON, ТО ALLOW_PAGE_LOCKS ИНСТРУКЦИИ =) НА [ОСНОВНОЙ]
) НА [ПЕРВИЧНОМ]
ГО

Что я уже пробовал:

Эта практика была реализована в нашем последнем проекте, поэтому я реализовал то же самое в текущем проекте.

Gerry Schmitz

Столбец IDENTITY - это столбец "первичный ключ", все остальное - "вторичное", независимо от вашего подхода к нему.

phil.o

Не совсем. Определение идентификатора для столбца приведет только к тому, что он будет иметь автоматически сгенерированную последовательность значений. Спецификация первичного ключа-это то, что приведет к тому, что столбец будет иметь уникальные значения по всей таблице, и он автоматически создаст кластеризованный индекс на нем.

Gerry Schmitz

Правда. Но что было "первым"? Таково было мое мнение. И если она действительно "первична", то идентичность избыточна, если только вы не используете ее для того, чтобы повесить детей, что опять же (на мой взгляд) делает идентичность "первичной". Только мои "чувства".
:0)

Еще одно "общее ощущение" состоит в том, что первичные ключи должны быть "бессмысленными" числами, для которых идеально подходит столбец идентификаторов (который включает в себя "номер клиента", номера счетов-фактур и т. д.)

Udai Karan Mathur

Пожалуйста, дайте мне знать, что мне делать.
1) удалить столбец Id из всей таблицы и создать кластеризованный индекс на guid coulmn ?
2) Поставить столбце ID в столбец идентификаторов и создания первичного ключа на столбец GUID уникальный некластерный индекс ?

Пожалуйста, дайте мне знать, какая из них лучше всего подходит для практики 1 или 2.

Gerry Schmitz

Сделать оба. Но "первичные ключи" людей обычно представляют собой некоторый "составной ключ" атрибутов, зависящий от ключа идентификации, и который позже оказывается плохим дизайнерским решением из-за изменения политики компании. Вы можете "изменить" первичные ключи, где на самом деле это создает большой беспорядок.

Существуют ли "детские отношения"? Сравните длину столбца идентификаторов с вашим столбцом "первичный ключ"? Что вы собираетесь использовать, чтобы связать их?
То, что "колонка идентичности не служит никакой цели", является недальновидным и наивным.

И наконец, что легче запомнить: Guid или int?

1 Ответов

Рейтинг:
0

Richard Deeming

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

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

Небезопасные прямые ссылки на объект профилактики шпаргалку | фонд[^]

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

Описание кластеризованных и Некластеризованных индексов - SQL Server | Microsoft Docs[^]
Руководство по архитектуре и дизайну индексов SQL Server - SQL Server | Microsoft Docs[^]