те которые суррогатные первычные ключи по котором затем обычно joinы для "
Не желательно делать такие ключи кластерными, а без кластерных ключей таблицы в современном SQL server работают хуже. Так что хорошо бы автоинкремент в pk и всё остальное guid
GUID Pros Unique across every table, every database and every server Allows easy merging of records from different databases Allows easy distribution of databases across multiple servers You can generate IDs anywhere, instead of having to roundtrip to the database, unless partial sequentiality is needed (i.e. with newsequentialid()) Most replication scenarios require GUID columns anyway GUID Cons It is a whopping 4 times larger than the traditional 4-byte index value; this can have serious performance and storage implications if you're not careful Cumbersome to debug (where userid='{BAE7DF4-DDF-3RG-5TY3E3RF456AS10}') The generated GUIDs should be partially sequential for best performance (eg, newsequentialid() on SQL Server 2005+) and to enable use of clustered indexes
Работают хуже в чем?
в работе индексов. Поддержка индексов не очень выгодная. Читать про непоследовательные вставки в кластерный индекс. Вот они происходят и страницы не целиком заполняются , увеличивается фрагментация индекса. Это конечно не страшно по сравнению с мировой революцией, но всё же.
Это как раз страшно, если нет регулярного maintenance
Ну, а я о чём?
Ну просто может сложиться ощущение, что прокатит как-нибудь. Не прокатит :)
Обсуждают сегодня