Здравствуйте, Merle, Вы писали:
iT>>Чтобы совсем не волноваться — надо int64 брать M>GUID — вот решение всех проблем!
Щаз. Нормальный кластерный индекс на нем не построишь. Да и уникальность у гуидов заканчивается, AFAIR, где-то в райне 2026 года. До этого времени и bigint прекрасно потянет. Единственное, когда GUID реально бывает нужен — при необходимости распределенной генерации ключей (например, при репликации). В остальных случаях, ИМХО, GUID — must die.
M>Если статью Синклера на ночь не читать...
Здравствуйте, Lexey, Вы писали:
L>Щаз. Нормальный кластерный индекс на нем не построишь.
Ну во-первых очень даже построишь, а во вторых строить кластерный индекс по идентификационному полю — в принципе занятие сомнительное..
L>Да и уникальность у гуидов заканчивается, AFAIR, где-то в райне 2026 года.
AFAIK — еще лет на 100 хватит...
L>Единственное, когда GUID реально бывает нужен — при необходимости распределенной генерации ключей (например, при репликации).
Как правило, идентификаторы на тех объемах, когда int'а не хватает — в одну таблицу уже не лезут...
L>В остальных случаях, ИМХО, GUID — must die.
Да откуда это пошло, что страшнее GUID'а — зверя нет?
Во многих случаях гораздо лучше GUID пользовать, а не identity... Не когда нельзя быть уверенным заранее, что не потребуется две одинаковых таблицы слить...
Здравствуйте, Merle, Вы писали:
M>Здравствуйте, Lexey, Вы писали:
L>>Щаз. Нормальный кластерный индекс на нем не построишь. M>Ну во-первых очень даже построишь, а во вторых строить кластерный индекс по
Я имел в виду, что не эффективно. Вставка будет с большой вероятностью между уже существующими значениями. И обычные индексы будут сильно пухнуть.
M>идентификационному полю — в принципе занятие сомнительное..
Так, давай сюда Влада позовем. Мне он уже когда-то доказал, что по identity полям кластерный индекс строить — самое то.
L>>Да и уникальность у гуидов заканчивается, AFAIR, где-то в райне 2026 года. M>AFAIK — еще лет на 100 хватит...
Где-то я тем не менее эт цифру видел. Хотя вот тут вообще пишут, что до 3400 года хватит.
L>>Единственное, когда GUID реально бывает нужен — при необходимости распределенной генерации ключей (например, при репликации). M>Как правило, идентификаторы на тех объемах, когда int'а не хватает — в одну таблицу уже не лезут...
Это конечно верно, если забыть про возможные удаления.
L>>В остальных случаях, ИМХО, GUID — must die. M>Да откуда это пошло, что страшнее GUID'а — зверя нет? M>Во многих случаях гораздо лучше GUID пользовать, а не identity... Не когда нельзя быть уверенным заранее, что не потребуется две одинаковых таблицы слить...
См. выше. Производительность с GUID будет хуже, чем int или bigint.
Здравствуйте, Lexey, Вы писали:
L> Вставка будет с большой вероятностью между уже существующими значениями.
И ничего в этом страшного...
L> И обычные индексы будут сильно пухнуть.
Вот это единственный, относительно серьезный аргумент, но и то.....
L>Так, давай сюда Влада позовем.
Да бога ради..
L> Мне он уже когда-то доказал, что по identity полям кластерный индекс строить — самое то.
Не, он тебе что-то не то доказал...
Кластерный индекс по identity крайне редко бывает оптимальным выбором, то есть это лучше чем отсутствие кластерного индекса вообще, но не более того..
L>См. выше. Производительность с GUID будет хуже, чем int или bigint.
На таблицах с количеством записей порядка нескольких десятков миллионов (на меньших размерах производительность GUID'ов от identity мало отличается) GUID'ы проигрывают identity от 5% до 20%, но во-первых это все равно надо на конкретной задаче мерять, а во вторых такой проигрыш в должной мере компенсируется отсутствием геморроя при различного рода репликациях...
Здравствуйте, Merle, Вы писали:
L>> Вставка будет с большой вероятностью между уже существующими значениями. M>И ничего в этом страшного...
Это тоже плохо, т.к. вставка с большой вероятностью будет приводить к лишним модификациям кластерного индекса.
L>> И обычные индексы будут сильно пухнуть. M>Вот это единственный, относительно серьезный аргумент, но и то.....
И что?
M>Не, он тебе что-то не то доказал...
Именно это. Причем весьма убедительно.
M>Кластерный индекс по identity крайне редко бывает оптимальным выбором, то есть это лучше чем отсутствие кластерного индекса вообще, но не более того..
Все, пошел звать Влада.
L>>См. выше. Производительность с GUID будет хуже, чем int или bigint. M>На таблицах с количеством записей порядка нескольких десятков миллионов (на меньших размерах производительность GUID'ов от identity мало отличается) GUID'ы проигрывают identity от 5% до 20%, но во-первых это все равно надо на конкретной задаче мерять, а во вторых такой проигрыш в должной мере компенсируется отсутствием
При таких объемах на конкретной задаче это уже поздо будет мерять. Менять структуру уже работающей базы — мало радости. Мне вполне достаточно, что GUID'ы медленнее, чтобы от них отказаться, там где это возможно.
M> геморроя при различного рода репликациях...
А кроме репликаций? В варианте с репликациями я в общем-то ничего против GUID'ов не имею.
Здравствуйте, Lexey, Вы писали:
L>Это тоже плохо, т.к. вставка с большой вероятностью будет приводить к лишним модификациям кластерного индекса.
Нет не будет, более того, при интенсивной вставке с индексом по монотонному полю производительность будет даже хуже чем с индексом по GUID'ам..
L>И что?
Есть масса встречных возражений...
L>Именно это. Причем весьма убедительно.
Хм.. Я, в свое время доказал ему обратное..
L>Все, пошел звать Влада.
Зови..
L>При таких объемах на конкретной задаче это уже поздо будет мерять.
Ха, бить надо по башке, того, кто позволил разрастись базе до таких размеров не померяв..
L>Мне вполне достаточно, что GUID'ы медленнее, чтобы от них отказаться, там где это возможно.
20% — это не медленнее...
L>А кроме репликаций? В варианте с репликациями я в общем-то ничего против GUID'ов не имею.
А там где репликаций нет, никто не может утверждать, что они не появятся...
Ладно, давай разбираться..
L>Это тоже плохо, т.к. вставка с большой вероятностью будет приводить к лишним модификациям кластерного индекса.
Не совсем так... К модификациям кластерного индекса это не приведет, внутри страницы записи не упорядчены. А вот при частой вставке, при наличии монотонного индекса возможет следующий любопытный эффект: При модификации индекса, в частности при добавлении нового ключа, для обеспечения согласованности, блокируется вся страница индекса, куда этот ключ добавляется. Блокировка (latch) накладывается только на время вставки и в обычном режиме сколь либо заметного эффекта на производительность она не оказывает, но если каждый последующий ключ больше (меньше) предыдущего, то все ключи попадают на последнюю страницу индекса и возникает драка за эту страницу между конкурирующими транзакциями и выстраивается совершенно не нужная очередь на ресурс. И ничего хорошего в этом нет. В случае же GUID'ов нагрузка размажется по всей таблице и чем больше таблица, тем меньше вероятность пересечения.
L>Именно это. Причем весьма убедительно. M>>Кластерный индекс по identity крайне редко бывает оптимальным выбором, то есть это лучше чем отсутствие кластерного индекса вообще, но не более того.. L>Все, пошел звать Влада.
В чем вообще весь цымус кластерного индекса? Это механизм позволяющий с некоторой долей вероятности управлять физическим размещением записей в таблице. В случае кластеризации по identity бонусов с этого можно получить довольно мало.
Пусть у нас есть табличка с PK identity, идентификатором пользователя, и большим количеством других полей с данными.. Пусть каждый пользователь большую часть времени работает только со своими данными. Нагрузка достаточно высокая и данных надо обработать достаточно много.
Что получется, если мы кластеризуем таблицу по identity? Данные конкретного пользователя окажутся размазанными по всей таблице, записи нужные для обработки, с очень высокой вероятностью окажутся физически на разных страницах, что приведет к совершенно не нужному ползанью по диску. Пользователи постоянно мешали бы друг-другу при страничных локировках и latch'ах захватывая чужие данные...
А вот если бы мы кластеризовали эту таблицу по ID пользователя, то картина была бы совершенно другой, получилось бы, что каждый пользователь фактически работал бы со своей частью таблицы и не лез бы к соседу, большинство данных поднималось бы за одно обращение к диску, поскольку с хорошей вероятностью они все окажутся на одной странице, в крайнем случае на соседних...
Если бы у нас была еще и подчиненная таблица с отношением один ко многим, то опять таки, ровно из тех же соображений, кластеризовать ее бы стоило не по PK, а по внешнему ключу...
Это все к тому, что выбор кластерного индекса — крайне важный стратегический вопрос, и выбирать его надо исходя из предстоящей нагрузки и характерных запросов, и крайне редко оптимальным выбором является identity.
L>>>См. выше. Производительность с GUID будет хуже, чем int или bigint.
См. выше
Единственный недостаток GUID'а — это большая длинна, что уменьшает количество записей влезающих в одну страницу индекса и, как следствие, увеличивает количество обращений к диску при прохождении по B+tree индексу. Но, как я уже говорил, сколь-либо заметный эффект это оказывает на таблицах размером как минимум в десяток миллионов записей.
Здравствуйте, Merle, Вы писали:
M>Здравствуйте, Lexey, Вы писали:
M>Ладно, давай разбираться..
L>>Это тоже плохо, т.к. вставка с большой вероятностью будет приводить к лишним модификациям кластерного индекса. M>Не совсем так... К модификациям кластерного индекса это не приведет, внутри страницы записи не упорядчены. А вот при частой вставке, при наличии монотонного
Откуда у тебя такие сведения. MS в BOL открытым текстом пишет, что clustered index задает физический порядок записей.
M> индекса возможет следующий любопытный эффект: При модификации индекса, в частности при добавлении нового ключа, для обеспечения согласованности, блокируется вся страница индекса, куда этот ключ добавляется. Блокировка (latch) накладывается только на время вставки и в обычном режиме сколь либо заметного эффекта на производительность она не оказывает, но если каждый последующий ключ больше (меньше) предыдущего, то все ключи попадают на последнюю страницу индекса и возникает драка за эту страницу между конкурирующими транзакциями и выстраивается совершенно не нужная очередь на ресурс. И ничего хорошего в этом нет. В случае же GUID'ов нагрузка размажется по всей таблице и чем больше таблица, тем меньше вероятность пересечения.
В описанное верится очень слабо. Даже если будет хоть какая-то драка за блокировки, то сам процесс вставки должен идти быстрее, т.к. нужная страница точно будет в кеше и скидывать его на диск придется меньшее число раз. Так же, скорее всего передраться могут только пишушие вставляющие транзакции (коих обычно гораздо меньше, чем читающих), а при вставке в середину еще придется драться с читателями.
L>>Именно это. Причем весьма убедительно. M>>>Кластерный индекс по identity крайне редко бывает оптимальным выбором, то есть это лучше чем отсутствие кластерного индекса вообще, но не более того.. L>>Все, пошел звать Влада. M>В чем вообще весь цымус кластерного индекса? Это механизм позволяющий с некоторой долей вероятности управлять физическим размещением записей в таблице. В случае кластеризации по identity бонусов с этого можно получить довольно мало.
С некоторой долей вероятности? Это как?
M>Пусть у нас есть табличка с PK identity, идентификатором пользователя, и большим количеством других полей с данными.. Пусть каждый пользователь большую часть времени работает только со своими данными. Нагрузка достаточно высокая и данных надо обработать достаточно много.
Блин, я же тебе не предлагаю ВСЕГДА кластерировать по идентити. Но во многих реальных случаях выбока идет по id записи, которая как раз и есть identity. И кластерный индекс по identity тут самое то.
В твоем пример, кстати, с большой долей вероятности identity в таблице вообще будет не нужен.
Здравствуйте, Merle, Вы писали:
M>Здравствуйте, Lexey, Вы писали:
L>>Это тоже плохо, т.к. вставка с большой вероятностью будет приводить к лишним модификациям кластерного индекса. M>Нет не будет, более того, при интенсивной вставке с индексом по монотонному полю производительность будет даже хуже чем с индексом по GUID'ам..
Тут у нас с тобой получаются одни голословные утверждения.
L>>И что? M>Есть масса встречных возражений...
Хоть одно приведи, pls.
L>>Именно это. Причем весьма убедительно. M>Хм.. Я, в свое время доказал ему обратное..
Не помню такого.
L>>Все, пошел звать Влада. M>Зови..
Уже, только он пока молчит.
L>>При таких объемах на конкретной задаче это уже поздо будет мерять. M>Ха, бить надо по башке, того, кто позволил разрастись базе до таких размеров не померяв..
ОК, приведи нормальный способ померять это на живой базе (меньшего размера), не уродуя ее структуру.
L>>Мне вполне достаточно, что GUID'ы медленнее, чтобы от них отказаться, там где это возможно. M>20% — это не медленнее...
Хм, а что же тогда медленнее? 200%?
L>>А кроме репликаций? В варианте с репликациями я в общем-то ничего против GUID'ов не имею. M>А там где репликаций нет, никто не может утверждать, что они не появятся...
А вот там никто не помешает добавить GUID для репликации в любой момент.
Здравствуйте, Lexey, Вы писали:
L>Я имел в виду, что не эффективно. Вставка будет с большой вероятностью между уже существующими значениями. И обычные индексы будут сильно пухнуть.
Незнаю как тухлсоть индексов, но из-за кластерной структуры индекса скорость вставки гуидов резко падает. Да и индекс по 128 битам значительно менее эффективен чем по интам. АВК как-то сделал тест (правда не по этому поводу, но все же) в котором сначала были инты, а потом стали гуиды. Тормоза были заметны на глаз. В общем, гуид — это удобно (иногда) но дороговато.
M>>идентификационному полю — в принципе занятие сомнительное..
L>Так, давай сюда Влада позовем. Мне он уже когда-то доказал, что по identity полям кластерный индекс строить — самое то.
Откровенно говря уже не помню, но это чистая правда. Кластерный индекс намного эффективнее заполняется последовательными значениями. Про это, если не ошибаюсь, и в БОЛ-е было написано.
L>>>Да и уникальность у гуидов заканчивается, AFAIR, где-то в райне 2026 года. M>>AFAIK — еще лет на 100 хватит...
Слыхал что МС изменял алгоритм генерации гуидов, но что-то в это не верится. Изначально их алгоритм учитывал маг-адрес сетевухи, так что он принципиально уникален в простнанстве (хотел бы я видеть сервер без сетевухи ), и если что начинает приращивать по ещеричке, так что на одной машине он тоже принципиально уникален. Переполнение 64-х разядных числе (врочем как и 32) вещь мало вероятная. Так что это не аргумент.
L>Где-то я тем не менее эт цифру видел. Хотя вот тут вообще пишут, что до 3400 года хватит.
Во-во.
L>>>Единственное, когда GUID реально бывает нужен — при необходимости распределенной генерации ключей (например, при репликации). M>>Как правило, идентификаторы на тех объемах, когда int'а не хватает — в одну таблицу уже не лезут...
L>Это конечно верно, если забыть про возможные удаления.
Да если не забывать тоже. Если вставлять/ужадять постоянно с частотой 0.1 секунды, то инта хватит на 7 лет. А если раз в секунду, то на 70 .
L>>>В остальных случаях, ИМХО, GUID — must die. M>>Да откуда это пошло, что страшнее GUID'а — зверя нет?
Он не страшен. Но относительно не эффективен. В реестре — это самое то. А в БД основанной на кластерных Б+-деревьях — это очень неэффективная форма генерации ID-ёв.
M>>Во многих случаях гораздо лучше GUID пользовать, а не identity... Не когда нельзя быть уверенным заранее, что не потребуется две одинаковых таблицы слить...
Ну, тогда еще есть смысл вместо типов данных строки использовать. Никогда не знаешь что прийдется пихать в колонки завтра.
L>См. выше. Производительность с GUID будет хуже, чем int или bigint.
100%. Особненно int (если речь о 32-х назрядных системах).
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Merle, Вы писали:
M>Не, он тебе что-то не то доказал... M>Кластерный индекс по identity крайне редко бывает оптимальным выбором, то есть это лучше чем отсутствие кластерного индекса вообще, но не более того..
И как ты это объяснишь?
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Merle, Вы писали:
L>>Это тоже плохо, т.к. вставка с большой вероятностью будет приводить к лишним модификациям кластерного индекса. M>Не совсем так... К модификациям кластерного индекса это не приведет, внутри страницы записи не упорядчены. А вот при частой вставке, при наличии монотонного индекса возможет следующий любопытный эффект: При модификации индекса, в частности при добавлении нового ключа, для обеспечения согласованности, блокируется вся страница индекса, куда этот ключ добавляется. Блокировка (latch) накладывается только на время вставки и в обычном режиме сколь либо заметного эффекта на производительность она не оказывает, но если каждый последующий ключ больше (меньше) предыдущего, то все ключи попадают на последнюю страницу индекса и возникает драка за эту страницу между конкурирующими транзакциями и выстраивается совершенно не нужная очередь на ресурс. И ничего хорошего в этом нет. В случае же GUID'ов нагрузка размажется по всей таблице и чем больше таблица, тем меньше вероятность пересечения.
Все так просто. Сделай эксперемент... Циклик в котором всавляй записи. Сначала с идентити, а потом с гуидами. Думаю, это тебя резко разубедит в своей правоте.
Там эффект такой. Гуид дает очнь большой разбром. Такой большой, что практически каждый раз вставка будет идти в разные стрницы. Это приводит к тому, что на примитивную операцию нужно:
1. Поднять практически всю таблицу в память.
2. Каждый раз изменять системную информацию.
3. Очень часто делить и объеденять кластры (страницы).
В итоге, все что ты говорил о блокировке просто меркнет по сравнению с левыми накладными расходами. В общем, тест тебе поможет.
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
1. В том что это не индекс. Это хранение отсортированной информации. У кластреного индекса (КИ) нижние страницы — это таблица. А сам кластер — это занятие памяти с запасом, в рассчете на то что в него будет производиться вставка. Если заполнение последовательное, то кластыры набиваются довольно плотно и поиск по ним будет шустрый.
2. Если на таблице есть кластерный индекс, то все ссылающиеся таблицы будут содержать в себе не что иное как значение ключа кластерного индекса. Таким образом замена 32-х бит на 128 — это нехилый удар и по другим таблицам.
M> Это механизм позволяющий с некоторой долей вероятности управлять физическим размещением записей в таблице.
Без каких либо вероятностей. КИ — это гарантия что твои данные упорядочены физически. Гуиды дают случайную упорядоченность, что приводит к лишним чтениям, так как связанные данные с боьшой долей вероятности лежат близко друг от друга. Гуиды же — это горантия того, что данные будут разбросаны по даблицам хаотически.
M>В случае кластеризации по identity бонусов с этого можно получить довольно мало.
Как раз наоборот:
1. Маленький ключ, а значит меньший объем как самой талблицы, так и ссылающихся на нее.
2. Совпадение с процессорным словом.
3. Последовательное заполнение.
M>Пусть у нас есть табличка с PK identity, идентификатором пользователя, и большим количеством других полей с данными.. Пусть каждый пользователь большую часть времени работает только со своими данными. Нагрузка достаточно высокая и данных надо обработать достаточно много. M>Что получется, если мы кластеризуем таблицу по identity? Данные конкретного пользователя окажутся размазанными по всей таблице,
Интересный вывод. С чего бы это?
M> записи нужные для обработки, с очень высокой вероятностью окажутся физически на разных страницах,
С точностью на оборот. Гуид — вот гарантия хаотического разноса данных.
M> что приведет к совершенно не нужному ползанью по диску. Пользователи постоянно мешали бы друг-другу при страничных локировках и latch'ах захватывая чужие данные...
Вот все это и отнеси к гуидам.
M>А вот если бы мы кластеризовали эту таблицу по ID пользователя, то картина была бы совершенно другой,
А что ID-пользователя не может быть идентети? Ты что под этим термином понимаешь?
M> получилось бы, что каждый пользователь фактически работал бы со своей частью таблицы и не лез бы к соседу, большинство данных поднималось бы за одно обращение к диску, поскольку с хорошей вероятностью они все окажутся на одной странице, в крайнем случае на соседних...
Ты вообще-то о гуидах говорил. Расскажи лучше как твоя теория на счет гуидов будет работать в этом случае.
Хотя если под ID-пользователя ты имешь в виду строку, то тоже ошибаешся.
M>Если бы у нас была еще и подчиненная таблица с отношением один ко многим, то опять таки, ровно из тех же соображений, кластеризовать ее бы стоило не по PK, а по внешнему ключу...
Вот это уже совсем крамола. ПК первый притендент на кластеризацию. Иначе любая ссылка будет букмарком, коий в скуле очень не хилый. К тому же любой джоин будет иметь стоимость в несколько раз выше. В общем, внешние ключи притенденты только если они используются значительно чаще чем ПК. Но это уже откровенно кривой дизайн БД. Таких таблиц в БД должно быть максимум 2-3 на сотню.
M>Это все к тому, что выбор кластерного индекса — крайне важный стратегический вопрос, и выбирать его надо исходя из предстоящей нагрузки и характерных запросов, и крайне редко оптимальным выбором является identity.
Почти всегда.
M>Единственный недостаток GUID'а — это большая длинна,
Если бы. Его хаотичность — это куда более серьезная проблема.
Кстати, красиво ты опять перешел с ID-пользователя на гуиды. Так в чем кайф гуидов в твоем примере?
M> что уменьшает количество записей влезающих в одну страницу индекса и, как следствие, увеличивает количество обращений к диску при прохождении по B+tree индексу.
Все с точностью до наоборот. В общем, тесты в студию!
M> Но, как я уже говорил, сколь-либо заметный эффект это оказывает на таблицах размером как минимум в десяток миллионов записей.
Уже на сотнях тысяч увидишь. Особенно если машика дохлая.
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Merle, Вы писали:
L>>Мне вполне достаточно, что GUID'ы медленнее, чтобы от них отказаться, там где это возможно. M>20% — это не медленнее...
Откуда дровишьки? Я вот точных цифр не скажу, но сам наблюдал видимые глазом тормоза после изменения БД на гуиды.
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Lexey, Вы писали:
L>Откуда у тебя такие сведения. MS в BOL открытым текстом пишет, что clustered index задает физический порядок записей.
От разработчиков сиквела и от собственных экспериментов...
L>В описанное верится очень слабо.
Тем не менее это так.
L> Так же, скорее всего передраться могут только пишушие вставляющие транзакции (коих обычно гораздо меньше, чем читающих), а при вставке в середину еще придется драться с читателями.
А из последней страницы никто не читает? Как раз при кластеризации по identity к последней странце будут лезть все подряд.
L>С некоторой долей вероятности? Это как?
Так, что физического упорядочивания записи нет, есть упорядоченность страниц и гарантия того, что запись "меньше" самой "большой" и "больше" самой маленькой записи страницы окажется на этой странице.
L> И кластерный индекс по identity тут самое то.
Нет, не то, другие выборки, как правило, выполняются чаще и более критичны к скорости.
Здравствуйте, VladD2, Вы писали:
VD>Все так просто. Сделай эксперемент... Циклик в котором всавляй записи. Сначала с идентити, а потом с гуидами. Думаю, это тебя резко разубедит в своей правоте.
Делал и не раз и в разных задачах.
VD>В итоге, все что ты говорил о блокировке просто меркнет по сравнению с левыми накладными расходами. В общем, тест тебе поможет.
Вообще, ты заблуждаешься..
Все напутал...
VD>Если заполнение последовательное, то кластыры набиваются довольно плотно и поиск по ним будет шустрый.
Поиск по кластеру более шустрый не из-за плотности заполнения — она всегда одинаковая, а из-за отсутствия bookmark lookups, ввиду того, что, как ты верно заметил, нижние узлы индекса содержат сами данные, ну и из-за относительной физической упорядоченности.
VD>2. Если на таблице есть кластерный индекс, то все ссылающиеся таблицы будут содержать в себе не что иное как значение ключа кластерного индекса.
Не таблицы, а другие индексы в этой таблице.
VD>Без каких либо вероятностей. КИ — это гарантия что твои данные упорядочены физически.
Не совсем. Это гарантия того, что физически будут упорядочены страницы, а данные внутри страницы не упорядочены.
VD>3. Последовательное заполнение.
Вот последовательное заполнение я бы как раз в минус записал, я уже писал ранее почему.
VD>Интересный вывод. С чего бы это?
Я имел ввиду данные разных пользователей.
VD>С точностью на оборот. Гуид — вот гарантия хаотического разноса данных.
Я немного о другом.
VD>Вот все это и отнеси к гуидам.
Ты меня не понял.
VD>А что ID-пользователя не может быть идентети? Ты что под этим термином понимаешь?
ID пользователя может быть любым, здесь я уже о том, что делать кластерный индекс по уникальному идентификатору вообще имеет мало смысла, не важно что это за идентификатор GUID или Identity.
VD>Ты вообще-то о гуидах говорил.
Да блин, здесь я уже о другом говорю.
VD>Вот это уже совсем крамола. ПК первый притендент на кластеризацию.
Нет. PK — последний кандидат на кластеризацию.
VD>Иначе любая ссылка будет букмарком, коий в скуле очень не хилый.
Не любая, а очень даже редкая.
VD>Если бы. Его хаотичность — это куда более серьезная проблема.
Его хаотичность в большинстве случаев вообще не роляет.
VD>Кстати, красиво ты опять перешел с ID-пользователя на гуиды. Так в чем кайф гуидов в твоем примере?
А читать внимательнее пробовал?
Мы уже победили, просто это еще не так заметно...
.
