Нет первичного ключа и составного первичного ключа

Question

Мой сценарий состоит в том, чтобы иметь таблицу для регистрации и сообщения о некоторых важных параметрах, которые пользователи могут изменять в наборе поддерживаемых нами сайтов (каждый сайт имеет собственную БД). Когда я разрабатывал таблицу (которая будет развернута на каждом БД), я был смущен, если мне нужен Primary Key или нет. У меня есть столбец с именем SiteID, и каждая строка в таблице регистрации будет иметь SiteId, newVal of Setting, oldVal of setting, Change date. Я буду использовать это, чтобы просматривать историю изменений на Сайте, фильтровать изменения по дате и т. Д. Таким образом, в этом случае, очевидно, SiteId не может быть PK, но действительно ли мне нужно добавить новый столбец, например LogId, чтобы создать композитный P K? Я что-то пропустил здесь?

Answer 1

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

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

В большинстве баз данных MPP (база данных, предназначенных для отчета, например: vertica) первичный ключ является необязательным. Итак, в нижней строке, если вы знаете свои данные и прецеденты, первичные ключи в чем-то можно избежать

Спасибо.

Answer 2

Я хотел бы сделать схему, как этот

{SiteId, версия, Установка, изменение даты}

As, старые настройки вы можете найти в предыдущей версии так держать значение на каждая версия в порядке.

Конечно, вы можете также использовать дату изменения, чтобы быть PK, как показано ниже:

{SiteId, Изменение даты, Установка}

Если дата включает время и ваш сценарий позволяет это, используя дату и siteID лучше.

Answer 3

Стол без дубликатов строк всегда имеет как минимум один ключ-кандидат. Мы можем выбрать один для объявления через PRIMARY KEY; любые другие - через UNIQUE NOT NULL. (UNIQUE NOT NULL - это ограничение, которое вы получаете от декларации PRIMARY KEY.) Если вы не сообщите СУБД о ваших ключах-кандидатах, то это не поможет вам, например, уменьшить ошибки, предотвращая дублирование или улучшая производительность, неявно определяя индекс на его столбцах.

Непонятно из вашего вопроса, как вы записываете, какие настройки заданы для новых значений &. Если ваши столбцы siteId, setting, newValue, oldValue & changeDate тогда у вашей таблицы есть один ключ кандидата, (siteID, setting, changeDate). Как единственный ключ кандидата, это первичный ключ. Если заданные значения определяют настройки, чтобы ваши столбцы составляли siteId, newValue, oldValue & changeDate тогда у вас есть два ключа-кандидата, (siteID, newValue, changeDate) и (siteID, oldValue, changeDate). Каждый должен получить ограничение UNIQUE NOT NULL. Можно было бы сделать заявление PRIMARY KEY.

Если вы добавили еще один столбец уникальных/суррогатных/идентификационных значений, тогда в таблице есть другой ключ-кандидат. Как и прежде, все они ограничены с помощью ограничения UNIQUE NOT NULL, один из которых может быть выражен через PRIMARY KEY. Есть причины для добавления такого уникального столбца/суррогата/идентификатора, но это не потому, что нет первичного ключа, если в таблице не было бы дубликатов строк.

Answer 4

Все лица таблицы должны иметь PK, а не все таблицы. В журналах истории/журналов обычно нет ПК, поскольку они представляют события, а не сущности. (Скорее, им не нужен ПК. Я видел, как они были определены с одним (как правило, автоматически сгенерированы), но мне еще нужно увидеть значение, используемое в запросе. Насколько я мог сказать, они совершенно лишний.)

В каких таблицах истории и журналов do есть поле временной метки и поле, представляющее, какое событие имело место. Остальная часть записи будет иметь некоторую информацию о сущности, включая объект PK, и другие данные, относящиеся к событию, - как до, так и после значений, таких как указанный OP.

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