Jimmy Nilsson omawia swoją koncepcję przewodnika COMBtutaj. Koncepcja ta jest popularna w NHibernate, między innymi, ze względu na jej rzekomą wartość wydajności w stosunku do standardowych GUID, które są zazwyczaj znacznie bardziej losowe.

Jednak w testach wydaje się, że tak nie jest. Czy czegoś mi brakuje?

Przypadek testowy:

Mam tabelę o nazwie temp (nie tabelę tymczasową, tylko tabelę o nazwie „temp”) z 55,000 wierszy. Mam nową tabelę o nazwie Kody i chcę skopiować wszystkie 585 000 wartości kodu z tabeli tymczasowej do tabeli kodów. Test SQL, który wykonałem, był:

set statistics time on;

truncate table codes;
DBCC DBREINDEX ('codes', '', 90);

insert into codes (codeid, codevalue)
select newid(), codevalue from temp

truncate table codes;
DBCC DBREINDEX ('codes', '', 90);

insert into codes (codeid, codevalue)
select CAST(CAST(NEWID() AS BINARY(10)) + CAST(GETDATE() AS BINARY(6)) AS UNIQUEIDENTIFIER), codevalue from temp

Wydajność przy użyciu standardowych wartości GUID:

Czasy wykonania SQL Server: czas procesora = 17250 ms, czas, który upłynął = 15735 ms.

(Dotyczy 585000 wierszy)

Wydajność z wartościami GUID COMB:

Czasy wykonania SQL Server: czas procesora = 17500 ms, czas, który upłynął = 16419 ms.

(Dotyczy 585000 wierszy)

czego mi brakuje? wartości GUID COMB spowodowały nieco dłuższe czasy, prawdopodobnie z powodu dodatkowych konwersji. Pomyślałem, że chodzi o skrócenie czasu wstawiania przez pół-uporządkowanie GUIDS przy użyciu daty dla ostatnich 6 bajtów, ale przyrost wydajności wydaje się nieistniejący.