Каковы за и против использования много первичных ключей столбца?
Я хотел бы видеть пример:
- Когда это является соответствующим
- Когда это не является соответствующим
Существует ли время, когда выбор базы данных имел бы значение к вышеупомянутым примерам?
7 ответов
Вы также можете посмотреть на эту статью из Herb Sutter У вас есть масса существующего кода и вы хотите добавить параллелизм. С чего начать?
-121--2072756-Стандартный C++ (по крайней мере C++ 98) не имеет никакого отношения к организации сети. Таким образом, вы должны сделать что-то специфичное для платформы.
Некоторые платформы имеют реализации IOStreams, которые позволяют создавать поток из дескриптора файла. В этом случае используйте дескриптор сокета в качестве дескриптора файла.
-121--2672272-Это действительно вопрос о суррогатных ключах, которые всегда являются либо автоматически увеличивающимся числом, либо GUID и, следовательно, одним столбцом, в сравнении с естественными ключами, которые часто требуют нескольких частей информации, чтобы быть действительно уникальными. Если у вас есть естественный ключ, который является только одним столбцом, то точка в любом случае явно спорная.
Некоторые люди будут настаивать только на использовании того или иного. Потратьте достаточно времени на работу с производственными базами данных, и вы узнаете, что нет независимой от контекста передовой практики.
Некоторые из этих ответов используют терминологию SQL Server, но эти концепции, как правило, применимы ко всем продуктам СУБД:
Причины использования одноколонных суррогатных ключей:
Кластеризованные индексы. Кластеризованный индекс всегда работает лучше, когда база данных может просто добавить к нему - в противном случае БД должна выполнить разделение страницы . Следует отметить, что это применимо только в том случае, если клавиша имеет значение sequential , т.е. последовательность автоприращения или последовательный GUID. Произвольные GUID, вероятно, будут намного хуже для производительности.
Отношения. Если ваш ключ имеет длину 3, 4 5 столбцов, включая символьные типы и другие некомпактные данные, вы теряете огромное пространство и впоследствии снижаете производительность, если вам приходится создавать связи внешнего ключа с этим ключом во 20 других таблицах.
Уникальность. Иногда у вас нет истинного естественного ключа. Может быть, ваш стол - это какой-то журнал, и вы можете получить два одних и тех же события одновременно. Или, может быть, ваш реальный ключ - это что-то вроде материализованного пути, который может быть определен только после того, как строка уже вставлена. В любом случае, вы всегда хотите, чтобы ваш кластеризованный индекс и/или первичный ключ был уникальным, поэтому, если у вас нет другой действительно уникальной информации, у вас нет другого выбора, кроме как использовать суррогатный ключ.
Совместимость. Большинству людей никогда не придется иметь дело с этим, но если естественный ключ содержит что-то вроде
hierarchyid, возможно, что некоторые системы даже не могут его прочитать. В этом случае снова необходимо создать простой автоматически созданный суррогатный ключ для использования этими приложениями. Даже если у вас нет каких-либо «странных» данных в естественном ключе, у некоторых библиотек БД есть много проблем с многоколонными первичными ключами, хотя эта проблема быстро исчезает.
Причины использования много-натуральные ключи столбцов
Место хранения. Многие люди, которые работают с базами данных, никогда не работают с достаточно большими, чтобы заботиться об этом факторе. Но когда в таблице есть миллиарды или триллионы строк, вы захотите сохранить абсолютный минимум данных в этой таблице, который вы, возможно, можете.
Репликация. Да, можно использовать GUID или последовательный GUID. Но GUID имеют свои собственные компромиссы, и если вы не можете или не хотите использовать GUID по какой-то причине, многоколонный естественный ключ является гораздо лучшим выбором для сценариев репликации, потому что он по сути глобально уникален - то есть вам не нужен специальный алгоритм, чтобы сделать его уникальным, он уникален по определению . Это очень упрощает анализ распределенных архитектур.
Вставить/обновить производительность . Суррогатные ключи не бесплатны. Если имеется набор столбцов, которые являются уникальными и часто запрашиваются, и поэтому для этих столбцов необходимо создать индекс покрытия; индекс становится почти таким же большим, как таблица, что приводит к растрате пространства и , что требует обновления второго индекса при каждом внесении изменений. Если вы когда-либо можете иметь только один индекс (кластеризованный индекс) в таблице, вы должны сделать это!
Вот что приходит в голову прямо с летучей мыши. Я обновлю, если вдруг вспомню что-нибудь еще.
Несколько примеров...
Соответствующие:
- Системы OLTP, в большинстве ситуаций при реализации большинства много-многочисленных отношений.
Неправильно:
Для таблиц размерности в OLAP-системах -- вы хотите сделать ваш ключ размерности как можно меньше, чтобы ваша таблица фактов была как можно меньше (и быстрее).
Для случаев, когда вы не уверены, является ли комбинация уникальной. Конечно, это довольно плохой пример, но таблица "Человек" была бы плохим выбором для многоколоночной PK.
Я думаю, что почти всегда лучше (по крайней мере, с точки зрения разработчика приложений) сделать первичный ключ автоматически сгенерированным ключом и создать ограничение UNIQUE и индекс для нескольких столбцов.
- С помощью одного автоматически сгенерированного первичного ключа вы сможете легко добавлять ссылки на эту таблицу из других таблиц.
- Автоматически сгенерированные первичные ключи проще работать с библиотеками ORM.
- Кроме того, если ваши ограничения уникальности изменятся в будущем, вам не нужно менять существующие первичные ключи.
Я столкнулся с несколькими ситуациями, вызывающими головную боль, потому что администратор базы данных считал, что первичный ключ с несколькими столбцами всегда будет достаточным, и будущие изменения требований доказали, что это неверно.
Вам почти всегда нужен первичный ключ, поэтому я предполагаю, что выбор будет между выбором двух существующих столбцов в качестве первичного ключа или созданием нового автоматически увеличивающегося PK и наложением вместо этого обычного уникального ограничения на два столбца.
Если вам нужен первичный ключ из двух столбцов:
- Если у вас есть промежуточная таблица, которая ссылается на две другие таблицы, и она состоит только из двух внешних ключей, то есть отношения «многие ко многим», тогда нет смысла добавлять дополнительный столбец, чтобы быть первичным ключом. Используйте два столбца, которые у вас уже есть, в качестве первичного ключа.
Если вам нужен автоинкрементный первичный ключ:
- Если вы ссылаетесь на таблицу из другой таблицы, вы хотите, чтобы первичный ключ целевой таблицы был небольшим, потому что эти данные будут повторяться как внешний ключ в ссылающаяся таблица. Вы также хотите, чтобы это было быстро для сравнения.
- Каждый индекс, который вы добавляете в таблицу, включает копию ключа кластеризации (который обычно совпадает с первичным ключом). Если ваш ключ кластеризации больше, чем он должен быть, каждый индекс в этой таблице также будет больше, чем должен быть.
Одним из примеров, когда это уместно, является наличие таблицы связей с полями с инородными ключами, соединяющими различные таблицы.
В общем, вероятно, будет хорошей идеей использовать существующие, идентифицируя поля в качестве первичного ключа, когда это возможно. Если у вас нет естественного поля id, и вам придется комбинировать множество полей, чтобы получить уникальный PK, то, вероятно, лучше использовать автоматический номер. Первичные ключи с более чем 2 полями могут быть запутанными.
Иногда составные естественные ключи имеют интуитивный смысл. Например. Предположим, у вас есть таблица для компании (PK - это ComapnyId) с некоторыми сведениями о компании в столбцах. У вас также есть требование хранить имя генерального директора компании на протяжении всей ее истории. Естественный инвариант состоит в том, что в одной компании одновременно может быть только один генеральный директор. Затем интуитивно понятно создание таблицы CompanyCeo с составным PK из CompanyId (от FK до CompanyId в таблице Company) + FromDate. Другие столбцы в этой таблице могут быть ToDate и CeoName. Таким образом, вы можете гарантировать, что один и только один генеральный директор может начать работу в определенный день.
Мы разработали vbscript 'launcher' для наших приложений доступа. Это то, что связано с в меню запуска пользовательских компьютеров и он делает следующее.
- Он проверяет файл version.txt, расположенный в сетевом общем ресурсе, чтобы проверить, содержит ли он текст, отличный от локально сохраненной копии
- Если текст отличается, он копирует mdb доступа и новый version.txt на жесткий диск пользователя.
- Наконец, запускается mdb в access
Для распространения обновления на ПК пользователя необходимо изменить текст в файле version.txt на сетевом общем ресурсе.
Возможно, можно реализовать нечто подобное
-121--3643145-Вы хотели бы использовать это, чтобы охватить ситуацию «что, если пользователь не указывает ни истинного, ни ложного?»
Это просто способ охватить все возможные результаты.
-121--2739764-При использовании многоколонных индексов и ключей мы обнаружили значительное повышение производительности нашего приложения. Это позволило нам создать индекс по нашим наиболее распространенным запросам, и главная таблица даже не была доступна, так как в индексе может быть все предложение select. Однако это зависит от вашего приложения и набора данных.