|
18.01.2023, 10:33 | #1 |
Участник
|
Цитата:
Для понимания, можете рассказать чем плохи или не удобны идентификаторы GUID?
|
|
|
За это сообщение автора поблагодарили: ena_ax (1). |
18.01.2023, 10:43 | #2 |
Участник
|
|
|
|
За это сообщение автора поблагодарили: Pandasama (3), ena_ax (1). |
18.01.2023, 11:08 | #3 |
Moderator
|
Вообще в SQL Server есть функция, которая возрастающие GUID генерирует. (NewSequentialId()), по которым проблемы фрагментации индекса не возникает. Тут правда вопрос - как разработчики GUIDы в своей логике генерируют...
Плюс - мне кажется что сейчас почти все индексы сжимаются, при этом с учетом того что они пишут что у них таблица в режиме append only, особо большого оверхида при обновлениях не будет, а при чтении за счет сжатия выигрыш будет существенным. |
|
|
За это сообщение автора поблагодарили: ena_ax (1), Logger (5). |
18.01.2023, 13:27 | #4 |
Участник
|
Цитата:
Но если их инкрементно выделять, то пропадают все вкусности GUID и он становится ничем не лучше обычного RecId. Даже хуже, так как RecId всего 8 байт занимает. |
|
18.01.2023, 14:11 | #5 |
Moderator
|
GUID проще выделить до записи в БД. То есть - в принципе UnitOfWork или махинации с suspendRecId() решают проблему, но MkGuid() все равно проще написать.
|
|
01.03.2023, 11:28 | #6 |
Участник
|
Цитата:
\Data Dictionary\Tables\EventInbox\Methods\nextEventId или свой системный счетчик 64-битных идентификаторов сделать один раз по аналогии. И вести его в разрезе TableId. |
|
|
За это сообщение автора поблагодарили: fed (5). |
12.09.2023, 14:32 | #7 |
Участник
|
Цитата:
https://habr.com/ru/articles/658855/ Комменты, как обычно, еще интереснее. |
|
|
За это сообщение автора поблагодарили: S.Kuskov (2). |