Может ли таблица SQL Server 2000 не иметь PK и, следовательно, содержать повторяющиеся записи? - PullRequest
Новая
       6

Может ли таблица SQL Server 2000 не иметь PK и, следовательно, содержать повторяющиеся записи?

0 голосов
/ 23 сентября 2011

У меня есть таблица аудита, и вместо определения идентификатора или столбца с метками я собираюсь просто вставить записи записанной таблицы (через триггеры).

Может ли таблица SQL Server 2000PK, и, следовательно, содержат дубликаты записей?

Если да, то все, что мне нужно сделать, это СОЗДАТЬ СТОЛ без определения каких-либо ограничений на него?

Ответы [ 5 ]

3 голосов
/ 23 сентября 2011

Да, это возможно, но не обязательно хорошая идея. Репликация и эффективная индексация будут довольно сложными без первичного ключа.

2 голосов
/ 23 сентября 2011

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

например 

CREATE TABLE bla(ID INT)


INSERT bla (ID) VALUES(1)
INSERT bla (ID) VALUES(1)
INSERT bla (ID) VALUES(1)


SELECT * FROM bla
GO
1 голос
/ 23 сентября 2011

Для таблицы аудита вам необходимо подумать, для чего вы можете использовать данные аудита.И даже если вы не проводите аудит, чтобы специально использовать его для восстановления записей при неудачных изменениях, они неизбежно используются для этого.Будет ли легче определить запись, которую вы хотите восстановить, если у вас есть суррогатный ключ, который предотвращает случайное восстановление 30 других записей, когда вам нужны только самые последние записи?Поможет ли ключевое значение идентифицировать 32 578 записей, которые были удалены в одном пакете, который необходимо восстановить?

Что мы делаем для аудита, так это две таблицы для каждой таблицы, в одной из которых хранится информация об изменении пакета записей., включая автоматически увеличивающийся идентификатор, пользователя, приложение, дату и время, количество затронутых записей.Затем дочерняя таблица использовала идентификатор в качестве fk и сохранила подробности о старых и новых значениях для каждой вставленной / обновленной / удаленной записи.Это действительно помогает нам, когда ошибка процесса приводит к случайному изменению многих записей.

1 голос
/ 23 сентября 2011

SQL Server 2000+, может иметь таблицы без ПК.И да, вы создаете их, не используя ограничение.

1 голос
/ 23 сентября 2011

Да, таблица SQL Server 2000 не может иметь первичного ключа и содержать повторяющиеся записи, и да, вы можете просто создать таблицу без определения каких-либо ограничений на нее.Однако я бы не стал это предлагать.

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

Создайте свою таблицу аудита следующим образом 

CREATE TABLE dbo.PersonAuditID
(
  PersonAuditID int NOT NULL IDENTITY (1, 1),
  PersonId int NOT NULL,
  FirstName nvarchar(50) NOT NULL,
  LastName nvarchar(50) NOT NULL,
  PersonWhoMadeTheChange nvarchar(100) NOT NULL,
  TimeOfChange datetime NOT NULL,
  ChangeAction int NOT NULL,
  /* any other fields here*/
  CONSTRAINT [PK_PersonAudit] PRIMARY KEY NONCLUSTERED 
  (
[PersonAuditID] ASC
  )
)  ON [PRIMARY]

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

Ваши триггеры будут выглядеть следующим образом 

CREATE TRIGGER Insert_PERSON
   ON  PERSON
   AFTER INSERT
AS 
BEGIN
    SET NOCOUNT ON;
    INSERT INTO PERSONAUDIT
    (PersonID, 
     FirstName, 
     LastName, 
     PersonWhoMadeTheChange, 
     TimeOfChange, 
     ChangeAction,
     ... other fields here
     SELECT 
       PersonID,
       FirstName,
       LastName,
       User(),
       getDate(),
       1,
       ... other fields here
     FROM INSERTED

END

CREATE TRIGGER Update_PERSON
   ON  PERSON
   AFTER UPDATE
AS 
BEGIN
    SET NOCOUNT ON;
    INSERT INTO PERSONAUDIT
    (PersonID, 
     FirstName, 
     LastName, 
     PersonWhoMadeTheChange, 
     TimeOfChange, 
     ChangeAction,
     ... other fields here
     SELECT 
       PersonID,
       FirstName,
       LastName,
       User(),
       getDate(),
       2,
       ... other fields here
     FROM INSERTED

END

CREATE TRIGGER Delete_PERSON
   ON  PERSON
   AFTER DELETE
AS 
BEGIN
    SET NOCOUNT ON;
    INSERT INTO PERSONAUDIT
    (PersonID, 
     FirstName, 
     LastName, 
     PersonWhoMadeTheChange, 
     TimeOfChange, 
     ChangeAction,
     ... other fields here
     SELECT 
       PersonID,
       FirstName,
       LastName,
       User(),
       getDate(),
       3,
       ... other fields here
     FROM DELETED

END
...