AI i bazy danych MySQL

Zauważalnym błędem jest to, że wiele schematów baz danych generowanych przez AI obecnie faworyzuje użycie VARCHAR(36) dla kolumny id.

Jest to zazwyczaj motywowane chęcią zapobiegania nieautoryzowanemu dostępowi przez złośliwych aktorów. Aby to osiągnąć, UUID (Universally Unique Identifiers) są często wykorzystywane jako środek bezpieczeństwa.

Weźmy WordPress jako przykład — typowo eksponuje ID postów w URL jako ?p=45. W porównaniu z formatem przyjaznym SEO jak /2025/05/sample-post, ten numeryczny ID pozwala użytkownikom potencjalnie odgadywać i uzyskiwać dostęp do sąsiadującej treści poprzez zmianę liczby (np. ?p=44). UUID z drugiej strony nie są sekwencyjne i są znacznie trudniejsze do odgadnięcia.

UUID to 36-znakowe ciągi, które następują standardowy format z pięcioma sekcjami oddzielonymi myślnikami: 8-4-4-4-12. Każda sekcja składa się z wartości szesnastkowych:

550e8400-e29b-41d4-a716-446655440000
f47ac10b-58cc-4372-a567-0e02b2c3d479
123e4567-e89b-12d3-a456-426614174000

Prosty regex do walidacji UUID wygląda tak:

^[a-fA-F0-9]{8}-[a-fA-F0-9]{4}-[a-fA-F0-9]{4}-[a-fA-F0-9]{4}-[a-fA-F0-9]{12}$

Podczas gdy UUID oferują bezpieczeństwo i przenośność, wiążą się z kompromisami. Są znacznie większe od liczb całkowitych, co może spowolnić wydajność bazy danych — szczególnie gdy używane jako klucze główne w relacyjnych bazach danych. Indeksowanie, użycie pamięci i prędkość zapytań cierpią z powodu rozmiaru i niesekwencyjnej natury UUID.

Rozmowa AI o strategii ID

Zaciekawiony tym wyborem projektowym, zadałem GitHub Copilot następujące pytanie:

Ja:
Dlaczego zdecydowałeś się zdefiniować kolumnę id jako VARCHAR(36) PRIMARY KEY w strukturze bazy danych?

GitHub Copilot:

Wybrałem VARCHAR(36) dla kolumn ID z kilku konkretnych powodów:

1. Przechowywanie UUID: 36-znakowa długość pomieści wartości UUID, które śledzą standardowy format.
2. Systemy Multi-tenant: UUID pomagają izolować najemców poprzez eliminację wycieków sekwencyjnych ID, upraszczanie migracji i poprawę bezpieczeństwa.
3. Przenośność danych: UUID zapewniają, że eksportowane dane nie doświadczą kolizji ID podczas importu do innego systemu.

Kompromisy:

• Większy rozmiar przechowywania (36 bajtów vs. 4 bajty dla INT)
• Wolniejsze indeksowanie i wydajność zapytań
• Większe zużycie pamięci

Alternatywy do rozważenia:

1. AUTO_INCREMENT INT/BIGINT
2. BINARY(16) do bardziej efektywnego przechowywania surowych bajtów UUID
3. Niestandardowa strategia generowania ID

Daj mi znać, jeśli wolisz inne podejście.

Ja:
Użyj BIGINT UNSIGNED dla wydajności, ale zachowaj pole guid w każdym rekordzie dla zewnętrznych odniesień.

GitHub Copilot:

Zaktualizuję schemat, aby użyć BIGINT UNSIGNED jako klucza głównego podczas dodawania kolumny guid dla zewnętrznych odniesień. To hybrydowe podejście łączy najlepsze z obu strategii:

• Wydajność: Efektywne indeksowanie i łączenia przez numeryczne klucze główne
• Bezpieczeństwo i przenośność: GUID eksponowane w API, zachowując wewnętrzne ID bezpieczne od wyliczania

Podsumowanie:

• BIGINT UNSIGNED: Szybki, kompaktowy, sekwencyjny
• GUID (VARCHAR): Unikalny, przenośny, bezpieczny zewnętrznie

Bazy danych NoSQL i ObjectIds MongoDB

Podczas gdy relacyjne bazy danych oferują elastyczność w wyborze między UUID, liczbami całkowitymi lub hybrydami, systemy NoSQL jak MongoDB idą inną ścieżką.

MongoDB używa wbudowanego typu zwanego ObjectId dla swojego pola _id. To jest 12-bajtowa wartość binarna, która koduje:

• 4 bajty – Timestamp (sekundy od epoki)
• 5 bajtów – Losowa wartość (często oparta na maszynie + ID procesu)
• 3 bajty – Licznik przyrostowy

Przykład:

507f1f77bcf86cd799439011

Dlaczego MongoDB wybiera ObjectId

1. Globalnie unikalny bez koordynacji
   Podobnie do UUID, ObjectIds nie wymagają centralnej władzy do zapewnienia unikalności, czyniąc je idealnymi dla środowisk rozproszonych.
2. Uporządkowany czasowo
   Wbudowany timestamp oznacza, że dokumenty są domyślnie uporządkowane chronologicznie, co może pomóc w wydajności w aplikacjach czasowych.
3. Kompaktowy i efektywny
   Przechowywane w formacie binarnym, ObjectIds zajmują tylko 12 bajtów — znacznie mniejsze niż UUID VARCHAR(36). Są także bardziej przyjazne dla indeksowania.

Porównanie strategii ID

Preferencje AI w kontekstach NoSQL

Wiele systemów generowanych przez AI domyślnie wykorzystuje konfiguracje NoSQL podobne do MongoDB, gdy:

• Oczekiwana jest wysoka przepustowość zapisu lub sharding
• Schematy muszą być elastyczne lub semi-strukturalne
• Przenośność danych i skalowanie rozproszone są priorytetami

W takich przypadkach używanie ObjectIds lub podobnych unikalnych, uporządkowanych czasowo identyfikatorów jest często rozsądnym domyślnym wyborem.

PrimeCRM