Мне не раз приходилось слышать от некоторых разработчиков программного обеспечения, что их таблице не нужен первичный ключ.
Иногда эти программисты хотят избежать воображаемых трудностей по поддержке уникального индекса, или у них есть таблицы без столбцов, которые можно было использовать для этой цели.
Ограничение первичного ключа важно, когда требуется достичь следующих целей: предотвращение появления дублированных строк в таблице; ссылка на отдельные строки в запросах; поддержка ссылок внешних ключей.
Если ограничения первичного ключа не используются, возникает необходимость в рутинной работе по проверке дубликатов строк.
SELECT bug_id FROM Bugs GROUP BY bug_id HAVING COUNT(*) > 1;
Как часто следует выполнять эту проверку? Что необходимо делать с дубликатом при его обнаружении?
Таблица без первичного ключа подобна упорядочиванию коллекции МРЗ-музыки без названий песен. Вы прослушиваете музыку, но не можете найти желаемую песню или исключить дублирование в коллекции.
Псевдоключи не были стандартизованы до SQL:2003, так что каждая база данных использовала свое собственное расширение SQL для реализации псевдоключей. Даже терминология, касающаяся псевдоключей, зависит от разработчика базы данных, как показано в нижеследующей таблице:
Функция Базы данных, которыми поддерживается функция
AUTO_INCREMENT MySQL
GENERATOR Firebird, InterBase
IDENTITY DB2, Derby, Microsoft SQL Server, Sybase
ROW ID SQLite
SEQUENCE DB2, Firebird, Informix, Ingres, Oracle, PostgreSQL
SERIAL MySQL, PostgreSQL
Псевдоключи — полезная функция, но они не представляют собой единственный способ объявления первичного ключа.
Опубликовал vovan666
June 18 2013 12:25:22 ·
0 Комментариев ·
3573 Прочтений ·
• Не нашли ответ на свой вопрос? Тогда задайте вопрос в комментариях или на форуме! •
Комментарии
Нет комментариев.
Добавить комментарий
Рейтинги
Рейтинг доступен только для пользователей.
Пожалуйста, залогиньтесь или зарегистрируйтесь для голосования.
Нет данных для оценки.
Гость
Вы не зарегистрированны? Нажмите здесь для регистрации.