GUID: varchar (36) w porównaniu uniqueidentifier

Question

Pracuję z bazy danych starszego typu, który przechowuje wartości GUID jako varchar typu (36) danych:

CREATE TABLE T_Rows (
    RowID VARCHAR(36) NOT NULL PRIMARY KEY, 
    RowValue INT   NOT NULL 
) 

INSERT T_Rows (RowID, RowValue) VALUES (NEWID(), 1) 

Przypuszczam, że przechowywanie GUID jako uniqueidentifier będzie preferowane, ponieważ ma tylko 16 bajtów, a nie 36.

Czy przechowywanie GUID jako varcharu ma jakieś zalety?

Answer 1

Być może tylko fakt, że można je "odczytać" z instrukcji SELECT (chociaż nie sądzę, że jest to szczególnie przydatne, ponieważ można użyć funkcji w selekcji, aby wyświetlić Uniqueidentifiers).

Jeśli tabela jest duża, oszczędność 20 bajtów na wiersz jest znaczna.

Answer 2

Absolutnie nie, ponieważ jestem pewien, że wiesz, że starsze bazy danych często cierpią z powodu wad projektowych: P Ponieważ identyfikator GUID ma 16 bajtów, równie dobrze może zająć 16 bajtów w bazie danych. Otrzymasz 20 bajtów na wpis

Answer 3

Wierzę, że UNIQUEIDENTIFIER został dodany w SQL Server 2000, więc możliwe jest, że ta aplikacja została pierwotnie napisana dla SQL Server 7, który go nie obsługiwał. Ale to tylko przypuszczenie, oczywiście ...

Answer 4

pójdę z uniqueidentifier z wielu powodów, takich jak

zajmie mniej miejsca; jest unikalny, więc nie można go powielić. Znacznie lepiej dla porównań i problemów związanych z wydajnością, a także łatwo uzyskać unikalną wartość domyślną, itp.

Użyłbym uniqueidentifier, chyba że potrzebuję użyć varchar z bardzo konkretnego powodu.

Answer 5

Jeśli twoją bazą danych jest Oracle, to wydajność indeksów dla surowych danych w starszej wersji Oracle (9) była o wiele, dużo gorsza niż indeksowanie pola varchar (36). Na szczęście to się zmieniło w Oracle 10 i 11.