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

ПОБОЧНОЕ ПРИМЕЧАНИЕ: я только что присоединился к компании, которая первоначально наняла третье лицо. Новой базе данных менее двух недель, и она была запущена в мои первые дни работы.

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

Обе базы данных являются SQL Server 2012

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

Текущее производство

CREATE TABLE [dbo].[Table](
    [field] [varchar](255) NULL,
    [data] [varchar](255) NULL,
    [id] [int] IDENTITY(1,1) NOT NULL
) ON [PRIMARY]
GO

Таблица из старой базы данных

CREATE TABLE [dbo].[Table](
    [id] [int] NOT NULL,
    [field] [varchar](255) NULL,
    [data] [varchar](255) NULL,
PRIMARY KEY CLUSTERED 
(
    [id] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY]
GO
  1. Повлияет ли это на изменение рабочей таблицы и ее добавление в первичный ключ вместе с индексом, существующим в старой базе данных? Есть ли руководство по лучшей практике для этого?

  2. Это подходящий sql для изменения производственной таблицы

ALTER TABLE [dbo].[Table] ADD PRIMARY KEY CLUSTERED 
(
    [id] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
GO
  1. Есть ли программная причина, по которой сторонний разработчик мог бы решить использовать IDENTITY вместо репликации первичного ключа в новой схеме?

РЕДАКТИРОВАТЬ: Мой план основан на рекомендации, приведенные в ответах

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

Я подтвердил, что столбец IDENTITY в настоящее время уникален с помощью этого запроса

SELECT DISTINCT(id), COUNT(id)
FROM Table
GROUP BY id
HAVING Count(id) > 1

Если вышеупомянутое остается верным, то я буду выполнять следующее в непиковые часы:

ALTER TABLE [dbo].[Table] ADD CONSTRAINT PK_Table PRIMARY KEY CLUSTERED
(
    [id] ASC
)
1
LongGin 2 Май 2019 в 00:36

3 ответа

Лучший ответ
  1. Добавление CLUSTERED INDEX в таблицу стоит дорого. Это заставит страницы переупорядочиваться, что означает интенсивный ввод-вывод, что в зависимости от таблицы может занять некоторое время. Скорее всего, на какое-то время стол заблокируется.
  2. Да, это правильный синтаксис, однако я рекомендую дать вашему ключу имя. Это меняет синтаксис на:

    ALTER TABLE [dbo].[SampleTable] ADD CONSTRAINT PK_SampleTable PRIMARY KEY CLUSTERED (ID ASC);

  3. Боюсь, мы не можем отвечать за решения других людей.

0
Larnu 1 Май 2019 в 21:45

Столбец идентификации в SQL Server не гарантированно является уникальным. В качестве документация четко определяет:

Свойство удостоверения в столбце не гарантирует следующее:

  • Уникальность значения. Уникальность должна обеспечиваться с помощью ограничения PRIMARY KEY, UNIQUE или индекса UNIQUE.

Столбцы идентичности почти всегда объявляются первичным ключом, но они не обязательны.

Во-вторых, если вы сделаете столбец первичным ключом, то он обычно будет кластеризованным (если другой кластеризованный индекс уже не существует). Как объясняется в

Gordon Linoff 1 Май 2019 в 21:52

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

Присвойте Имя первичному ключу вместо того, чтобы система генерировала анонимное имя.

Подумайте, какова цель таблицы и данных? Где это используется?

0
Sai Krishna 1 Май 2019 в 22:09