Игорь Акопян писал(а):Duncon, спокойнее.
не вижу почему не использовать последовательно возрастающее значение.
Вот пример ситуации.
Головной офис ежемесячно собирает с филиалов данные и сливает в единый массив. После их обработки, головной офис формирует изменения, которые должны быть добавлены в общий массив.
В головном офисе и филиале используется одно и тоже ПО. Другими словами структура база одинакова, изменить pk нельзя. Более того, проектировщик хорошо знающий теорию баз данных, не будет делать pk autoincrement'ным
В этой ситуации возрастающие значения для Pk нужно использовать в филиалах для добавления новых записей. А в головном офисе при добавлении изменений max()+1 не подходит.
Конечно, Вы можете искать свободные значения для pk min и max - классическое решение. Но когда таблица большая (>50 млн) и нужно добавить много (>1000) записей, то дешевле разыграть значения и сделать вставку.
На досуге можете потренироваться.
Кстати, ещё пример из повседневной практики
Лучше первого.
Есть такой метод сбора статистики по таблице ESTIMATE
ANALYZE TABLE x ESTIMATE STATISTICS
_Разыгрывается_ набор уникальных значений ROWID и на основе данных записей с этим ROWID (всего лишь!) формируется отчет со статданными.
Этот метод применяем для формирования ряда экспресс-отчетов. Очень хорошо себя зарекомендовал.
Попробуйте сформировать набор _уникальных_значений. Да такой, чтоб не помещался в конструкцию IN (больше 1024). Чтоб в таблице хранился. Очень полезное упражнение.
