Лично я не думаю, что наличие столбца RecordID следует рекомендовать ПРОТИВ.Скорее, я бы советовал, что часто это НЕОБХОДИМО.
- это случаи, когда наличие единственного значения для идентификации строки делает более простой код.Но они оплачиваются за счет дополнительного хранилища, часто дополнительных индексов и т. Д. На самом деле накладные расходы невелики, но также и преимущества.
С точки зрения выбораслучайные записи, наличие единственного уникального идентификатора может облегчить задачу если идентификаторы являются последовательными и последовательными.
ПричинаЯ говорю это потому, что ваше предлагаемое решение требует присвоения NEWID () каждой записи и сортировки всех записей, чтобы найти первую.По мере увеличения размера таблицы эта операция увеличивается и может стать относительно дорогой.Достаточно ли дорого стоит оптимизация, зависит от того, что еще происходит, как часто и т. Д.
Однако при наличии последовательных последовательных уникальных идентификаторов можно выбрать случайное значение между MIN (id) и MAX.(id), а затем ИСКАТЬ это значение.Требование, чтобы все значения были последовательными, однако, часто является слишком большим ограничением;вам никогда не разрешается удалять среднюю таблицу значений, например ...
Чтобы преодолеть это и в зависимости от индексов, вы можете найти следующий подход полезным.
DECLARE
@max_id INT
SELECT
@id = COUNT(*)
FROM
Images_Persons
SELECT
*
FROM
(
SELECT
*,
ROW_NUMBER() OVER (ORDER BY ImageID, PersonID) AS id
FROM
Images_Persons
)
AS data
WHERE
Images_Persons.id = CAST(@max_id * RAND() + 1 AS INT)
-- Assuming that `ImageID, PersonID` is the clustered index.
Недостатком является то, что RAND () печально известен своей случайностью.Тем не менее, он обычно идеально подходит, если выполняется в произвольное время относительно любого другого вызова RAND ().