uuidv7 | rfc 9562 | zamana göre sıralanabilir

> uuidv7 generator <

// Zamana göre sıralı, sıralanabilir UUID'ler (RFC 9562, 2024) — 48 bit Unix ms zaman damgası + 74 rastgele bit, yerel olarak oluşturulur

// BİR UUIDV7'Yİ ÇÖZ / İNCELE

Gömülü zaman damgasını, sürümünü ve varyantını çıkarmak için aşağıya herhangi bir UUID yapıştırın. v7 ile çalışır ve giriş farklı bir UUID sürümüyse bunu bildirir.

Zaman damgası (ms): // çözülen alanlar burada görünür
ISO 8601 UTC: // çözülen alanlar burada görünür
Yaş: // çözülen alanlar burada görünür
Sürüm: // çözülen alanlar burada görünür
Varyant: // çözülen alanlar burada görünür
rand_a (12 bit): // çözülen alanlar burada görünür
rand_b (62 bit): // çözülen alanlar burada görünür
[RFC 9562]

Şartnameye Uygun UUIDv7

RFC 9562'deki (Mayıs 2024) zamana göre sıralı UUID biçimini uygular: 48 bit Unix milisaniye zaman damgası, 4 bit sürüm 7, 12 bit rand_a, 2 bit varyant, 62 bit rand_b. Şartname test vektörlerine karşı doğrulanmıştır.

[SORTABLE]

Kronolojik Sıralama Düzeni

Sayısal veya sözlükbilimsel olarak sıralayın ve ekleme sırasını elde edin — B-ağacı birincil anahtarları, zaman serisi dizinleri ve günlük korelasyonu için mükemmel. Artık rastgele v4 sayfa bölünmeleri veya parçalanmış dizinler yok.

[MONOTONIC]

Aynı Milisaniye İçinde Monotonluk

Birkaç UUID bir milisaniyeye düştüğünde, çıktının o ms içinde sıralı kalması için rastgele kısım sıkı şekilde artırılır. İsterseniz düz RFC 9562 Yöntem 1 (rastgele doldurma) için kapatın.

[DECODER]

Herhangi Bir UUIDv7'yi İnceleyin

Bir v7 UUID yapıştırın; çözücü gömülü zaman damgasını (ms + ISO 8601), sürüm bitlerini, varyant bitlerini ve rand_a / rand_b alanlarını çıkarır. Hata ayıklama, günlük arkeolojisi ve denetim izleri için kullanışlıdır.

// UUIDV7 HAKKINDA

UUIDv7 Nasıl Çalışır:

Bir UUIDv7, unix_ts_ms (48) | ver (4) | rand_a (12) | var (2) | rand_b (62) şeklinde düzenlenmiş 128 bit bir tanımlayıcıdır. İlk 48 bit, milisaniye cinsinden geçerli Unix zaman damgasıdır, big-endian, bu da UUID'yi zaman içinde monoton artan yapar. Sonraki 4 bit sürümü kodlar (ikili 0111 = ondalık 7), bu nedenle tirelerle ayrılmış üçüncü grup her zaman 7 hanesiyle başlar. rand_a, alt milisaniye çözünürlüğü için veya ek entropi olarak kullanılan 12 rastgele bittir. 2 bit varyant alanı 10 olarak sabittir (bu nedenle dördüncü grubun ilk karakteri her zaman 8, 9, a veya b'dir). Kalan 62 bit (rand_b), her oluşturmada crypto.getRandomValues()'ten gelir. UUID başına toplam entropi 74 rastgele bittir; bu, herhangi bir gerçekçi oluşturma hızı için çakışmaya dayanıklıdır.

Örnek:

018f5c2e-90c0-7a4f-b6ee-8dfe3c2b0a55 (ts=2024-05-08T15:00:00.000Z)

Standartlar ve Referanslar:

  • >RFC 9562 — Universally Unique IDentifiers (UUIDs), Mayıs 2024 (RFC 4122'yi geçersiz kılar, v6/v7/v8'i tanımlar)
  • >RFC 4122 — 2005'teki özgün UUID şartnamesi (v1-v5 için hâlâ yetkili)
  • >Web Crypto API (W3C) — 74 rastgele bit için kullanılan crypto.getRandomValues() CSPRNG
  • >PostgreSQL gen_random_uuid() davranışı (varsayılan olarak v4, pgcrypto uzantılarında / çatallarında v7)
  • >draft-peabody-dispatch-new-uuid-format — RFC 9562 hâline gelen özgün v6/v7/v8 önerisi

Neden UUIDv7 Kullanmalı:

  • >Ekleme yerelliğine sahip veritabanı birincil anahtarları — sayfalar dolu kalır, dizinler parçalanmaz
  • >Bir dizi + UUID çiftinin yerini alır: tek bir sütun, sıralanabilir VE genel olarak benzersiz
  • >Rastgele ekleme sayfa bölünmesi sorununu düzeltmek için yazma yoğun tablolardaki v4 birincil anahtarlarının yerini alır
  • >Ayrı bir zaman damgası sütununa gerek kalmadan oluşturma zamanına göre sıralanan günlük korelasyon kimlikleri
  • >Birden fazla yazıcının bir koordinatör olmadan sıralı kimliklere ihtiyaç duyduğu dağıtık sistemler
  • >Kronolojik sıranın doğal dizin olduğu olay kaynaklı (event sourcing) / yalnızca-ekleme günlükleri
  • >Önek sıralamasının ekleme sırasıyla eşleştiği S3 / nesne depolama anahtarları
  • >Standart bir biçimin tercih edildiği yerlerde Snowflake / KSUID / ULID'in yerini alır

İlgili Araçlar:

// ÖRNEK ÇIKTILAR

Şimdi oluşturulan tek bir UUIDv7

config: count=1, format=standard, timestamp=current

output:

018f5c2e-90c0-7a4f-b6ee-8dfe3c2b0a55

Aynı milisaniyede monotonlukla toplu yığın

config: count=5, format=standard, monotonic=on

output:

018f5c2e-90c0-7a4f-b6ee-8dfe3c2b0a55
018f5c2e-90c0-7a4f-b6ee-8dfe3c2b0a56
018f5c2e-90c0-7a4f-b6ee-8dfe3c2b0a57
018f5c2e-90c0-7a4f-b6ee-8dfe3c2b0a58
018f5c2e-90c0-7a4f-b6ee-8dfe3c2b0a59

Özel geçmiş zaman damgası — bir geçişi geriye doldurma

config: count=1, timestamp=custom, value=1577836800000 (2020-01-01)

output:

016f5e66-e800-7c9a-b403-2f1d4a7c91ee

URL'ler / dosya adları için kompakt biçim

config: count=1, format=no-hyphens

output:

018f5c2e90c07a4fb6ee8dfe3c2b0a55

Çözülmüş UUIDv7 — gömülü alanları inceleyin

config: input = 018f5c2e-90c0-7a4f-b6ee-8dfe3c2b0a55

output:

ts_ms = 1715180400000
ISO   = 2024-05-08T15:00:00.000Z
ver   = 7
var   = 10 (RFC 4122)
rand_a = 0xa4f
rand_b = 0x36ee8dfe3c2b0a55

// KENDİNİZ UYGULAYIN

RFC 9562'nin 2024'te yayımlanmasından bu yana çoğu dilin UUIDv7 için ya bir standart kütüphane yardımcısı ya da tek dosyalık bir uygulaması var. Aşağıda kod tabanınıza ekleyebileceğiniz kanonik tarifler bulunuyor — tarayıcı JS'i, Node.js, Go, Python ve PostgreSQL'de.

[JavaScript]

Saf tarayıcı/Node JS'inde UUIDv7 — RFC 9562 düzeni

function uuidv7() {
  const ts = BigInt(Date.now());
  const rand = new Uint8Array(10);
  crypto.getRandomValues(rand);
  const b = new Uint8Array(16);
  b[0] = Number((ts >> 40n) & 0xFFn);
  b[1] = Number((ts >> 32n) & 0xFFn);
  b[2] = Number((ts >> 24n) & 0xFFn);
  b[3] = Number((ts >> 16n) & 0xFFn);
  b[4] = Number((ts >> 8n)  & 0xFFn);
  b[5] = Number( ts          & 0xFFn);
  b[6] = (rand[0] & 0x0F) | 0x70;   // version = 7
  b[7] =  rand[1];
  b[8] = (rand[2] & 0x3F) | 0x80;   // variant = RFC 4122
  for (let i = 9; i < 16; i++) b[i] = rand[i - 6];
  const h = Array.from(b, x => x.toString(16).padStart(2,'0')).join('');
  return `${h.slice(0,8)}-${h.slice(8,12)}-${h.slice(12,16)}-${h.slice(16,20)}-${h.slice(20)}`;
}

// usage:
const id = uuidv7();
console.log(id);   // -> '018f5c2e-90c0-7a4f-b6ee-8dfe3c2b0a55'

// generate a batch and verify chronological sort:
const batch = Array.from({ length: 5 }, uuidv7);
batch.sort();      // sorts by creation time without a separate timestamp
[Node.js]

Node.js v26.1.0+ — yerleşik crypto.randomUUIDv7()

import { randomUUIDv7 } from 'node:crypto';

// Added in Node.js v26.1.0 (2026-05-07).
// Returns an RFC 9562 version 7 UUID. The first 48 bits encode a
// millisecond Unix timestamp; the rest is CSPRNG output.
const id = randomUUIDv7();
// -> '018f5c2e-90c0-7a4f-b6ee-8dfe3c2b0a55'

// The CSPRNG output is cached for performance: Node generates enough
// entropy upfront for the next ~128 UUIDs. Pass disableEntropyCache: true
// when you need each call to draw fresh randomness, e.g. directly after
// a fork() or in tight high-security loops.
const freshId = randomUUIDv7({ disableEntropyCache: true });

// IMPORTANT: per the Node docs, "the embedded timestamp relies on a
// non-monotonic clock and is not guaranteed to be strictly increasing."
// If two UUIDs land in the same millisecond OR the system clock steps
// backwards, the IDs may not sort in creation order. Use a userland
// monotonic-v7 library (e.g. uuidv7 on npm) when strict ordering matters.
[Go]

Go — google/uuid v1.6+ UUIDv7'yi yerel olarak sunar

package main

import (
    "fmt"
    "github.com/google/uuid"
)

func newID() uuid.UUID {
    id, err := uuid.NewV7()
    if err != nil {
        panic(err)
    }
    return id
}

func main() {
    id := newID()
    fmt.Println(id.String())  // 018f5c2e-90c0-7a4f-b6ee-8dfe3c2b0a55
    fmt.Println(id.Time())    // embedded creation timestamp
}
[Python]

Python 3.13+ — standart kütüphane uuid.uuid7()

import uuid

# Python 3.13 added uuid7() and uuid8() to the standard library.
uid = uuid.uuid7()
print(uid)            # 018f5c2e-90c0-7a4f-b6ee-8dfe3c2b0a55
print(uid.version)    # 7

# For older Python use the 'uuid7' or 'uuid-utils' PyPI packages, or:
# from uuid_extensions import uuid7
[PostgreSQL]

PostgreSQL 18+ — yerel uuidv7() işlevi

-- PG 18 ships uuidv7() natively. Use it as a primary key default:
CREATE TABLE events (
    id   uuid PRIMARY KEY DEFAULT uuidv7(),
    body jsonb,
    ts   timestamptz NOT NULL DEFAULT now()
);

-- For older Postgres, install the pg_uuidv7 extension or generate client-side.
-- Migration tip: keep INDEX on (id) only — v7 already sorts chronologically,
-- so a separate (created_at) index is usually redundant.

// YAYGIN TUZAKLAR

> UUIDv7 oluşturma zamanını sızdırır — onu opak belirteçler için kullanmayın

Her v7'nin ilk 48 biti bir Unix milisaniye zaman damgasıdır. UUID'yi gören herkes, kaydın ne zaman oluşturulduğunu, kimliklerin verilme hızını ve (birden fazla örnekle) sunucu saatini yaklaşık olarak çözebilir. Bu, dahili veritabanı birincil anahtarları ve günlük kimlikleri için sorun değildir, ancak parola sıfırlama URL'leri, paylaşım bağlantıları, oturum kimlikleri veya davet kodları için bunun yerine UUIDv4 veya CSPRNG ile oluşturulmuş rastgele bir dize kullanın.

> Saat gerilemesi monotonluğu bozar

Sistem saati geriye giderse (NTP adımı, VM geçişi, artık saniye), naif şekilde oluşturulan v7 UUID'ler daha önce verilmiş kimliklerin önüne sıralanan değerler üretebilir. RFC 9562 §6.2, Yöntem 2'yi (monoton rastgele) önerir: en son oluşturulan UUID'yi izleyin ve zaman damgası ilerlemediğinde bunun yerine rastgele kısmı artırın. Bu aracın Monoton anahtarı tam olarak bunu yapar.

> v7, güvenliğe duyarlı bağlamlarda v4'ün doğrudan yerine geçmez

Rastgele görünen kimlikler (v4) genellikle yanlışlıkla bearer belirteçleri olarak kullanılır: «UUID'yi biliyorsanız satırı okuyabilirsiniz». v7'nin yalnızca 74 rastgele biti ve tahmin edilebilir bir zaman damgası öneki vardır; bu hâlâ çakışmaya dayanıklıdır ancak v4'ün 122 rastgele bitine kıyasla çok daha az öngörülemezlik sağlar. Bir şey bir yetenek (capability) olarak ele alınıyorsa, v7 birincil anahtarını yeniden kullanmak yerine ayrı bir kriptografik belirteç oluşturun.

> Dize karşılaştırması yalnızca küçük harfli, tireli biçimde çalışır

v7'nin kronolojik sıralaması, kanonik 36 karakterlik küçük harfli dizenin sözlükbilimsel karşılaştırmasına — veya temeldeki 16 baytlık değerin bayt bayt karşılaştırmasına — dayanır. Büyük ve küçük harfleri karıştırmak, yarı yolda tireleri çıkarmak ya da bazı satırları {...} parantezli, bazılarını parantezsiz saklamak, her durumda artık oluşturma zamanıyla eşleşmeyen bir sıralama düzeni üretir. Sütun başına tek bir kanonik biçim seçin ve bunu bir CHECK kısıtlamasıyla zorunlu kılın.

> 48 bit zaman damgası 10889 yılında devreder

2^48 milisaniye, Unix dönemi sonrası kabaca 8.925 yıldır — zaman damgası alanı 02-08-10889 UTC'de taşar. Kodunuz gömülü zaman damgasının makul bir aralıkta olduğunu öne sürüyorsa, bir yüzyıl içinde yanlış olacak yakın gelecekteki bir yılı sabit kodlamak yerine üst sınırı 281.474.976.710.655 ms olarak ayarlayın (48 bit işaretsiz bir tam sayının tutabileceği maksimum değer).

>> sıkça sorulan sorular

S: UUIDv7 nedir?

C: UUIDv7, RFC 9562'de (Mayıs 2024) tanımlanan, 48 bit Unix milisaniye zaman damgasını 74 bit rastgelelik ve standart sürüm + varyant bitleriyle birleştiren 128 bit bir tanımlayıcıdır. Sonuç, oluşturma zamanına göre kronolojik olarak da sıralanan genel olarak benzersiz bir kimliktir — her iki dünyanın en iyisi. Özellikle, her eklemenin farklı bir B-ağacı sayfasına düştüğü ve büyük yazma yükseltmesine neden olduğu rastgele UUIDv4 birincil anahtarlarının yol açtığı veritabanı dizini sorununu çözmek için tasarlanmıştır.

S: UUIDv7, UUIDv4'ten nasıl farklıdır?

C: UUIDv4 tamamen rastgeledir (122 rastgele bit) ve sürüm + varyant alanlarının ötesinde bir yapısı yoktur. Bir mikrosaniye arayla oluşturulan iki v4, çok farklı konumlara sıralanır; bu, öngörülemezlik için harika ancak B-ağacı dizinleri için korkunçtur. UUIDv7 başa 48 bit Unix milisaniye zaman damgası koyar, böylece zaman olarak yakın oluşturulan v7'ler depolamada da yakın sıralanır. Ödünleşim: v7 oluşturma zamanını açığa çıkarır ve 122 yerine yalnızca 74 rastgele biti vardır — hâlâ çakışmaya dayanıklı ancak gizli belirteç olarak uygun değildir.

S: UUIDv4'ten UUIDv7'ye geçmeli miyim?

C: Yazma yoğun tablolardaki dahili veritabanı birincil anahtarları için — evet, neredeyse her zaman. v4'ün neden olduğu dizin parçalanması, özellikle InnoDB kümelenmiş dizinlere sahip PostgreSQL veya MySQL'de, sorguların kendisinin maliyetini gölgede bırakabilir. Kullanıcılara açık olan, URL'lere gömülen veya yetenek olarak ele alınan belirteçler için («UUID'yi biliyorsanız kaynağa erişebilirsiniz»), v4'ü koruyun veya ayrı bir rastgele belirteç kullanın — v7 oluşturma zamanını sızdırır. Yaygın bir desen, dahili birleştirmeler için v7 birincil anahtarları artı herkese açık URL için ayrı bir rastgele slug'dır.

S: UUIDv7, ULID, KSUID veya Snowflake ile aynı mı?

C: Kavramsal olarak benzer — dördü de zamana göre sıralı kimliklerdir — ancak bit düzenleri ve kodlamalar farklıdır. ULID, Crockford base32 ve farklı bir milisaniye düzeni kullanır. KSUID, 32 bit zaman damgası + 128 bit yükü 27 base62 karakteri olarak kodlar. Snowflake, worker kimliklerine sahip 64 bit Twitter'a özgü bir kimliktir. UUIDv7, kanonik 8-4-4-4-12 onaltılık biçiminde kodlanan IETF standart eşdeğeridir, böylece her UUID kütüphanesi, veritabanı UUID türü ve JDBC/ODBC sürücüsü onu zaten anlar. 2025 ve sonrasında sıfırdan başlıyorsanız v7'yi tercih edin — standart odur.

S: Çakışmalardan önce milisaniye başına kaç UUIDv7 oluşturabilirim?

C: Tek bir milisaniye içinde benzersizliği yalnızca 74 rastgele bit (12'si rand_a'da + 62'si rand_b'de) sağlar. Doğum günü çakışması sınırına göre, %50 çakışma olasılığından önce aynı ms içinde yaklaşık 2^37 ≈ 137 milyar v7 oluşturabilirsiniz — herhangi bir gerçekçi sistem için pratikte sınırsız. Milisaniyeler arasında zaman damgasının kendisi ayırt eder, bu nedenle bir sistemin ömrü boyunca küresel çakışma riski ihmal edilebilir. Monoton anahtarı açıkken, milisaniye içi çakışmalar tasarım gereği sıfırdır (rastgele kısım artırılır).

S: Bir UUIDv7'den zaman damgasını çıkarabilir miyim?

C: Evet — zaman damgası ilk 48 bittir; bu, tireler kaldırıldığında ilk 12 onaltılık karakterdir. İlk üç tire grubunu (8 + 4 = 12 hex digits) birleştirin, onaltılık bir tam sayı olarak ayrıştırın ve milisaniye cinsinden Unix zaman damgasını elde edersiniz. Bunu etkileşimli olarak yapmak için yukarıdaki çözücüyü kullanın veya kodda: parseInt(uuid.replace(/-/g,'').slice(0,12), 16). Sonuç, UUID'nin oluşturulduğu milisaniye anıdır; o andaki sistem saatine göre doğrudur.

S: UUIDv7'de sürüm hanesi nasıl görünür?

C: Tirelerle ayrılmış üçüncü grup her zaman 7 hanesiyle başlar. Örneğin: 018f5c2e-90c0-7a4f-b6ee-8dfe3c2b0a55. Dördüncü grup her zaman 8, 9, a veya b ile başlar — bunlar, en üstteki iki bitin 10 olduğu dört olası değerdir (RFC 4122 varyantı). Sürüm hanesi 7 değilse, UUID başka bir sürümdür (yaygın olarak rastgele için 4 veya zaman tabanlı v1 için 1) ve kronolojik olarak sıralanmaz.

S: PostgreSQL / MySQL, UUIDv7'yi yerel olarak destekliyor mu?

C: PostgreSQL 18 (Eylül 2025'te yayımlandı), yerleşik işlev olarak uuidv7()'yi sunar. Önceki sürümler pg_uuidv7 uzantısına veya istemci tarafı oluşturmaya ihtiyaç duyar. MySQL 8.x'in yerel v7'si yoktur; UUID_TO_BIN(uuid, 1) yardımcısını (sıralama düzeni için zaman damgası baytlarını değiştirir) yalnızca v1 için kullanın — v7 için istemci tarafında oluşturun. SQL Server, Oracle ve SQLite'ın tümü istemci tarafı v7 oluşturmayı bekler. Çoğu ORM (Hibernate, Entity Framework, Sequelize, Prisma, SQLAlchemy) artık v7'yi yerel olarak veya bir eklenti aracılığıyla destekler.

S: Monoton seçeneği RFC 9562 ile uyumlu mu?

C: Evet. RFC 9562 §6.2, milisaniye içi sıralamayı sağlamak için üç yöntemi açıkça tanımlar: (1) rastgele doldurma, (2) monoton rastgele — zaman damgası ilerlemediğinde bir sayacı artırma, (3) alt milisaniye zaman damgası hassasiyeti. Bu araçtaki Monoton onay kutusu yöntem 2'yi uygular: iki UUID aynı 48 bit zaman damgasını paylaştığında, ikincisinin rastgele kısmı yeniden çekilmek yerine previous_random + 1 olarak ayarlanır. Bu, toplu oluşturma için sıkı sıralamayı garanti ederken tamamen şartnameye uygun kalır.

S: Verilerim herhangi bir yere gönderiliyor mu?

C: Hayır. Tüm UUIDv7 oluşturma, çözme, sıralama, kopyalama ve indirme işlemleri tamamen tarayıcınızda saf JavaScript olarak gerçekleşir. OLUŞTUR, ÇÖZ, KOPYALA veya İNDİR'e tıkladığınızda sayfa hiçbir zaman bir ağ isteği yapmaz — bunu tarayıcınızın geliştirici araçları Ağ sekmesiyle doğrulayabilirsiniz. Zaman damgalarını, özel tohumları, oluşturulan UUID'leri veya çözülmüş çıktıları günlüğe kaydetmiyoruz. Sayfanın kendisi bir CDN'den sunulan statik HTML'dir, bu nedenle hiçbir giriş altyapımıza ulaşmaz. Bu, aracı üretim veritabanı kimlikleri, dahili günlükler veya üçüncü taraf bir sunucudan geçirmemeyi tercih edeceğiniz başka veriler için güvenli kılar.

S: UUIDv7'yi Java / .NET / Rust'ta kullanabilir miyim?

C: Evet. Java'da com.fasterxml.uuid:java-uuid-generator 5.0+ vardır ve JDK 21'de kütüphane yardımcıları aracılığıyla bulunur. .NET 9, BCL'de Guid.CreateVersion7()'yi sunar. Rust, v7 özellik bayrağının arkasında uuid crate'inin Uuid::now_v7()'sini kullanır. Diğer çoğu ekosistemin de (Elixir, Ruby, PHP, Swift, Kotlin) iyi bakımlı paketleri vardır — dilin paket kayıt defterinde «uuidv7» veya «uuid v7» aratın. Wire biçimi hepsinde aynıdır, bu nedenle Go'da oluşturulan bir v7, herhangi bir dönüşüm olmadan JavaScript tarafından ayrıştırılabilir ve zaman damgası çıkarılabilir.

S: Node.js'in yerleşik bir UUIDv7 oluşturucusu var mı?

C: Evet — Node.js v26.1.0'dan (2026-05-07'de yayımlandı) itibaren standart kütüphane crypto.randomUUIDv7([options])'yi sunar. Bunu import { randomUUIDv7 } from 'node:crypto' olarak içe aktarın ve RFC 9562 v7 UUID dizesi almak için argümansız çağırın. Desteklenen tek seçenek disableEntropyCache'tir (boole, varsayılan false); varsayılan olarak Node, sonraki ~128 UUID'yi oluşturmaya yetecek kadar rastgele veriyi önceden önbelleğe alır; bu, crypto.randomUUID() tarafından kullanılan optimizasyonun aynısıdır. Resmi dokümanlardan önemli bir uyarı: «gömülü zaman damgası monoton olmayan bir saate dayanır ve kesinlikle artan olması garanti edilmez». Başka bir deyişle, aynı milisaniyede oluşturulan iki UUID veya bir NTP adımı / VM saat kayması boyunca oluşturulan herhangi bir UUID, oluşturma sırasına göre sıralanmayabilir. Bir milisaniye içinde sıkı monotonluğa ihtiyacınız varsa, RFC 9562 §6.2 Yöntem 2'yi izleyen bir userland uygulaması kullanın (npm uuidv7 paketi veya bu araç Monoton anahtarı açıkken).

S: UUIDv7'yi bir veritabanında verimli şekilde nasıl saklarım?

C: 36 karakterlik bir dize yerine 16 baytlık ikili tür olarak saklayın — satır başına 20 bayt tasarruf edersiniz, dizin boyutunu yarıya indirirsiniz ve daha hızlı bir karşılaştırma yolu kazanırsınız. PostgreSQL'in uuid türünü, MySQL BINARY(16), SQL Server uniqueidentifier veya SQLite BLOB kullanın. Zorlama isterseniz sürüm nibble'ının 7'ye eşit olduğunu belirten bir CHECK kısıtlaması ekleyin. v7 ile satırlar doğal olarak oluşturma zamanına göre kümelenir, bu nedenle (uuid_pk) üzerinde kapsayan bir dizin genellikle yeterlidir — kronolojik sorgular için ayrı bir (created_at) dizinine ihtiyacınız yoktur.

// OTHER LANGUAGES