Классика баз данных - статьи
то ничего страшного, можно написать
FROM stores A, sales B
WHERE state = 'CA' AND A.stor_id = B.stor_id
GROUP BY A.stor_id, A.stor_name, A.stor_address
В общем- то ничего страшного, можно написать и так. Но, во-первых,
это неестественно: мы вторично сообщаем системе то, что уже было
сказано при создании таблицы stores. Во-вторых, если совершенно
очевиден способ выполнения операции группирования по столбцу
stores.stor_id (поскольку это первичный ключ, то в любой СУБД для
столбца stor_id будет создан уникальный индекс), то не очень
понятно, как будет выполняться модифицированный запрос
(оптимизатор сможет выбирать стратегии сортировки соединенной
таблицы по значениям всех трех полей группирования, а также
использования одного из трех индексов; поскольку мы объявили
stor_name и stor_address возможными ключами, то для этих столбцов
тоже вполне вероятно будут созданы уникальные индексы).
И последнее в этой заметке наблюдение. Если классики реляционной
теории говорят, что в любом отношении должен существовать хотя бы
один возможный ключ, а первичный ключ выбирается неформализуемым
образом из набора возможных ключей, то в языке SQL это не так. В
соответствии со стандартом, первичный ключ не может содержать
неопределенных значений, а ключи, объявляемые с использованием
спецификации UNIQUE, - могут содержать неопределенные значения.
Следовательно, вообще говоря в таблице SQL-ориентированной базы
данных может существовать возможный ключ и одновременно не
существовать первичного ключа. Кстати, именно так обстоит дело в
исходным вариантом таблицы discounts (если еще раз внимательно
посмотреть на ее определение, то можно убедиться, что возможный
ключ в смысле языка SQL в этой таблице существует).
Вывод, который мне хотелось бы сделать, совпадает с призывом
одного из прогрессивных деятелей: "Люди, будьте бдительны!" (даже
если вы пользуетесь стандартным языком баз данных SQL).
