UUID Nedir, Ne Zaman Kullanılır?

UUID, bir kaydı benzersiz şekilde tanımlamak için üretilen uzun bir sayı dizisi; sıradan artan bir ID yerine bunu kullanmanın asıl sebebi, farklı sistemlerde aynı anda üretilse bile çakışma ihtimalinin pratikte sıfıra yakın olması.

Özet

Adım adım

Ne zaman gerektiğine karar ver: birden fazla sistem birbirinden habersiz kayıt üretiyorsa UUID mantıklı, tek merkezi veritabanınsa basit artan ID genelde yeterli.
Bir UUID üreticisiyle örnek bir kimlik oluştur, formatını (32 karakter, tire ile ayrılmış 5 grup) tanı.
UUID'nin sıralı olmadığını unutma; kayıtları oluşturulma sırasına göre listelemek istiyorsan ayrı bir tarih alanına ihtiyacın var.
Veritabanında UUID'yi metin yerine uygun ikili/UUID veri tipiyle saklamayı tercih et, performans farkı gerçek.

Neden önemli?

Artan bir ID ile çalışan bir sistemde kayıt numarası dışarıya da bilgi sızdırır. Adres çubuğunda /siparis/1042 gören biri, 1041 ve 1043 numaralı siparişleri de denemeyi düşünebilir ya da sitenizin kaç sipariş aldığını kabaca tahmin edebilir. UUID bu tahmini zorlaştırır. Ayrıca mobil uygulama gibi çevrimdışı çalışan bir istemci, sunucuya sormadan kendi kaydına kimlik verebilir. Kayıt daha sonra senkronize edildiğinde çakışma derdi olmaz.

Formatı biraz daha yakından tanıyın

Bir UUID, 32 onaltılık (hex) haneden oluşur. Tirelerle 8-4-4-4-12 gruplarına bölündüğünde toplam 36 karakter olur. Üçüncü grubun ilk hanesi sürümü gösterir. En yaygın kullanılan sürüm 4'tür ve neredeyse tamamen rastgele üretilir. Daha yeni olan sürüm 7 ise başına zaman bilgisi ekler. Bu sayede kayıtlar aşağı yukarı oluşturulma sırasıyla dizilir ve veritabanı indeksleri daha düzenli kalır. Hangisinin kullanıldığını UUID'nin içindeki sürüm hanesine bakarak anlayabilirsiniz.

Sık yapılan hatalar

UUID'yi gizli anahtar gibi kullanmak. Tahmin edilmesi zor olsa da UUID bir güvenlik belirteci olarak tasarlanmamıştır; şifre sıfırlama bağlantısı gibi yerlerde bu iş için üretilmiş rastgele belirteçler kullanın.
Yetki kontrolünü UUID'ye bırakmak. Adresi bilen herkes kayda erişebiliyorsa sorun ID türünde değil, yetkilendirmededir.
Büyük tablolarda rastgele UUID'yi birincil anahtar yapıp performans sorununu sonradan fark etmek. Rastgele değerler indeksin her yerine dağılır; zaman sıralı sürümler bu etkiyi azaltır.
Aynı sistemde büyük harfli ve küçük harfli UUID'leri karışık saklamak. Metin olarak karşılaştırıldığında aynı kimlik iki farklı kayıt gibi görünebilir.

Örnek bir senaryo

Bir randevu uygulaması, kullanıcıların internet yokken de randevu taslağı oluşturabilmesini istiyor. Artan ID kullanıldığında iki telefon aynı numarayı üretiyor ve senkronizasyonda kayıtlar birbirinin üzerine yazılıyor. Ekip, her taslağa cihazda üretilen bir UUID vermeye geçiyor. Sıralama için ayrı bir oluşturulma tarihi alanı tutuluyor, kullanıcıya gösterilen kısa randevu numarası ise sunucu tarafında ayrıca atanıyor.

Kullanıcıya göstermeniz gerekiyorsa

36 karakterlik bir kimliği telefonda okumak ya da müşteri hizmetlerine söylemek zordur. İç kimlik olarak UUID'yi tutup, kullanıcıya kısa ve okunabilir bir referans kodu göstermek iki ihtiyacı birden karşılar.