тверскойzeon11Ну, и насчёт GUID:
1.Очевидно, что ожидать ускорения работы БД и уменьшения размера БД в случае использования GUID не приходится.
2.При использовании целочисленного РК вы получаете в качестве бонуса лёгкий способ определения старшинства записи, контроль целостности данных.
3. РК рано или поздно при проектировании БД войдёт в другую таблицу в качестве FK,
и таких внешних ключей в одной таблице может быть не один, а достаточно много. Представьте, как будет выглядеть такая таблица при прямом просмотре?

по 1.
Что очевидно? да, 16 байт GUID в два раза больше, чем 8 байн BigInt, но в масштабах БД это будут копейки

Начиная с того, что абсолютная уникальность GUID, собственно, не очень-то и гарантируется (т.е., могут быть дубликаты и не только теоретически), и заканчивая тем, что GUID по сути - случайное число, последовательная вставка которых в индексы приводит, мягко говоря, к тихому страху и ужасу для дисковой подсистемы при работе с большими объемами данных...
Если GUID-поле входит еще и в кластерный индекс (в стиле MSSQL) - туши свет, пиши письма...
тверскойпо 2.
Определение старшинства записи по значению PK - это, мягко говоря, бред. Подобный метод применяется в БД "на коленке", где данные добавляет только один пользователь и всегда только "по старшинству".

Не вопрос... Но тут такое дело... Например, есть задача, в котоой достаточно часто (раз в несколько секунд) требуется выбрать последние N вставленных записей в таблицу (что-то под десяток млн. записей в месяц, примерно 20 ГБ данных на диске)... Данные в таблицу вставляются несколькими "тупыми железяками"... Прикажете делать еще одно поле с датой/временем вставки и индексировать его? вариант, конечно, но вот только в случае с целочисленным автоинкрементным суррогатным ключом это даже не просто, а ОЧЕНЬ просто - выбрать последние записи по индексу... Без всяких дополнительных накладных расходов...