Минимальное количество ключей-кандидатов для отношения?

Question

Мой вопрос заключается в том, необходимо ли для отношения / таблицы в базе данных иметь ключ-кандидат и, следовательно, первичный ключ? Возможно ли иметь отношение, при котором строка не может быть однозначно идентифицирована ни одной комбинацией атрибутов?

Если нет, почему? И если да, то как СУБД делает такие операции, как поиск, удаление и т. Д., Эффективными?

Answer 1

Отношения всегда имеют разные кортежи, что означает, что в реляционной СУБД таблица всегда имеет хотя бы один ключ-кандидат.

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

Последующими проблемами дублирующихся строк являются определенные неэффективности и сложности СУБД SQL и отсутствие ортогональности в их функциях. Механизмы СУБД SQL должны использовать внутренние структуры и поддерживать специальные функции в качестве предварительного условия для работы с дублирующимися строками. Некоторые поставщики СУБД пытаются обойти трудности, отключая определенные функции для таблиц, у которых нет ключей.

Answer 2

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

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

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

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

Answer 3

Да, это возможно.

Просто отметьте, что какой-то идентификатор существует за кулисами ( пример из SQL Server):

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

Как будут выполняться операции?

Сканирование таблицы понадобится практически для любой операции:

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