5.1 Giriş

İnternet, ilişkisel veritabanlarında anahtarların nasıl seçilmesi ve kullanılması gerektiğine dair dogmatik ilkelerle doludur. Bazen anlaşmazlıklar bayramlara bile dönüşüyor: doğal mı yoksa yapay anahtarlar mı kullanılmalı? Otomatik artan tamsayılar veya UUID'ler?

Altmış dört makale okuduktan, beş kitabın bölümlerini karıştırdıktan ve IRC ve StackOverflow hakkında tonlarca soru sorduktan sonra, ben (orijinal makalenin yazarı Joe "begriffs" Nelson) yapbozun parçalarını bir araya getirmiş gibiyim ve artık düşmanları uzlaştırabilir. Birçok kilit anlaşmazlık aslında başka birinin bakış açısının yanlış anlaşılmasından kaynaklanır.

Sorunu parçalara ayıralım ve sonunda tekrar birleştirelim. İlk önce şu soruyu soralım - "anahtar" nedir?

Bir an için birincil anahtarları unutalım, daha genel bir fikirle ilgileniyoruz. Anahtar, bir sütun (sütun) veya satırlarda yinelenen değerlere sahip olmayan sütunlardır . Ayrıca, sütunlar indirgenemez şekilde benzersiz olmalıdır, yani sütunların hiçbir alt kümesi bu benzersizliğe sahip değildir.

Ama önce, biraz teori:

birincil anahtar

Birincil anahtardoğrudan bir tablodaki satırları tanımlamak için kullanılır. Aşağıdaki kısıtlamalara uymalıdır:

  • Birincil anahtar her zaman benzersiz olmalıdır .
  • Her zaman tabloda bulunmalı ve bir değere sahip olmalıdır .
  • Değerini sık sık değiştirmemelidir. İdeal olarak, değeri hiç değiştirmemelidir .

Tipik olarak birincil anahtar, bir tablonun tek bir sütununu temsil eder, ancak birden çok sütundan oluşan bileşik bir anahtar da olabilir.

Bileşik anahtar

Özel Anahtar- her bir tablo satırını benzersiz şekilde tanımlayan özniteliklerin (sütunlar) bir kombinasyonu. Tüm sütunlar, birkaç ve bir olabilir. Bu durumda bu niteliklerin değerlerini içeren satırlar tekrarlanmamalıdır.

Potansiyel Anahtar

aday anahtar- ilişkinin (tablonun) minimum bileşik anahtarını, yani bir dizi koşulu karşılayan bir dizi niteliği temsil eder:

  • İndirgenemezlik : İndirgenemez, mümkün olan en az özellik kümesini içerir.
  • Benzersizlik : Satır değişikliğinden bağımsız olarak benzersiz değerlere sahip olmalıdır.
  • Bir değerin varlığı : Boş bir değere sahip olmamalıdır, yani bir değere sahip olmalıdır.

5.2 Birincil anahtarların ilginç durumu

Önceki bölümde az önce "anahtarlar" olarak adlandırdığımız şeyler genellikle "aday anahtarlar" olarak adlandırılır. "Aday" terimi, bu tür tüm anahtarların "birincil anahtarın" (birincil anahtar) onursal rolü için rekabet ettiğini ve geri kalanına "alternatif anahtarlar" (alternatif anahtarlar) atandığını ima eder.

SQL uygulamalarının anahtarlar ile ilişkisel model arasındaki uyuşmazlığı aşması biraz zaman aldı ve ilk veritabanları düşük seviyeli bir birincil anahtar kavramına yönelikti. Bu tür veritabanlarındaki birincil anahtarlar, sıralı depolama ortamındaki bir satırın fiziksel konumunu belirlemek için gerekliydi. Joe Celko bunu şöyle açıklıyor:

"Anahtar" terimi, sıralı bir dosya sisteminde herhangi bir işleme işlemini gerçekleştirmek için gerekli olan bir dosya sıralama anahtarı anlamına geliyordu. Bir dizi delikli kart tek ve yalnızca bir sırayla okundu; geri dönmek imkansızdı. İlk teyp sürücüleri aynı davranışı taklit ediyor ve çift yönlü erişime izin vermiyordu. Yani, önceki satırı okumak için tabloyu başa "geri sarmak" için gereken orijinal Sybase SQL Sunucusu.

Modern SQL'de, bilgilerin fiziksel temsiline, tablo model ilişkilerine odaklanmanıza gerek yoktur ve satırların iç düzeni hiç önemli değildir. Bununla birlikte, şimdi bile, SQL sunucusu varsayılan olarak birincil anahtarlar için kümelenmiş bir dizin oluşturur ve eski geleneğe göre satırların sırasını fiziksel olarak düzenler.

Çoğu veritabanında, birincil anahtarlar geçmişte kaldı ve bir yansıma veya fiziksel konumdan biraz daha fazlasını sağlıyor. Örneğin, bir PostgreSQL tablosunda, bir birincil anahtarın bildirilmesi, otomatik olarak bir kısıtlama uygular NOT NULLve varsayılan bir yabancı anahtar tanımlar. Ayrıca birincil anahtarlar operatör için tercih edilen sütunlardır JOIN.

Birincil anahtar, diğer anahtarları bildirme olasılığını geçersiz kılmaz. Aynı zamanda, birincil olarak hiçbir anahtar atanmamışsa, tablo yine de iyi çalışacaktır. Yıldırım, her durumda, size çarpmayacak.

Java university

5.3 Doğal anahtarları bulma

Yukarıda tartışılan anahtarlara "doğal" denir, çünkü bunlar, kimse onlardan bir anahtar çıkarmak istemese bile, modellenen nesnenin kendi içlerinde ilginç olan özellikleridir.

Olası doğal anahtarlar için bir tabloyu incelerken hatırlanması gereken ilk şey, çok akıllı olmamaya çalışmaktır. StackExchange'teki kullanıcı sqlvogel aşağıdaki tavsiyeleri verir:

Bazı insanlar, belirli bir anahtarın benzersiz olmayabileceği varsayımsal durumlar buldukları için "doğal" bir anahtar seçmekte güçlük çekerler. Görevin anlamını anlamıyorlar. Anahtarın anlamı, herhangi bir zamanda niteliklerin belirli bir tabloda benzersiz olması gerektiği ve her zaman benzersiz olacağı kuralı tanımlamaktır. Tablo, belirli ve iyi anlaşılmış bir bağlamda ("konu alanı" veya "söylem alanı" içinde) veriler içerir ve tek anlamı, kısıtlamanın o belirli alanda uygulanmasıdır.

Uygulama, sütun mevcut değerlerle benzersiz olduğunda ve olası senaryolarda öyle kalacağı zaman bir anahtar kısıtlama getirmenin gerekli olduğunu göstermektedir. Ve gerekirse kısıtlama kaldırılabilir (bu sizi rahatsız ediyorsa, aşağıda anahtar istikrar hakkında konuşacağız.)

Örneğin, hobi kulübü üyelerinden oluşan bir veritabanı iki sütunda benzersiz olabilir - first_name, last_name. Az miktarda veri ile kopyalar olası değildir ve gerçek bir çatışma ortaya çıkmadan önce böyle bir anahtarı kullanmak oldukça mantıklıdır.

Veritabanı büyüdükçe ve bilgi hacmi arttıkça, doğal bir anahtar seçmek daha zor hale gelebilir. Sakladığımız veriler, dış gerçekliğin basitleştirilmiş halidir ve zamanla değişen koordinatları gibi dünyadaki nesneleri ayırt eden bazı yönleri içermez. Bir nesnenin herhangi bir kodu yoksa, iki kutu içeceği veya iki kutu yulaf ezmesini mekansal düzenlemelerinden veya ağırlık veya ambalajdaki küçük farklılıklardan nasıl ayırt edebilirsiniz?

Bu nedenle standardizasyon kuruluşları ürünlere ayırt edici işaretler yaratır ve uygular. Araçlar bir Araç Kimlik Numarası (VIN) ile damgalanır , kitaplar ISBN'lerle basılır ve gıda ambalajlarında UPC'ler bulunur . Bu sayıların doğal görünmediğini söyleyerek itiraz edebilirsiniz. Öyleyse neden onlara doğal anahtarlar diyorum?

Bir veritabanındaki benzersiz özelliklerin doğallığı veya yapaylığı, dış dünyaya göredir. Bir standart kuruluşunda veya devlet kurumunda yaratıldığında yapay olan bir anahtar, tüm dünyada bir standart haline geldiği ve/veya nesnelerin üzerine basıldığı için bizim için doğal hale gelir.

Para birimleri, diller, finansal araçlar, kimyasallar ve tıbbi teşhisler dahil olmak üzere çeşitli konularda birçok endüstri, kamu ve uluslararası standart vardır. Genellikle doğal anahtar olarak kullanılan değerlerden bazıları şunlardır:

  • ISO 3166 ülke kodları
  • ISO 639 dil kodları
  • ISO 4217'ye göre para birimi kodları
  • Hisse senedi sembolleri ISIN
  • UPC/EAN, VIN, GTIN, ISBN
  • oturum açma adları
  • e-mail adresleri
  • oda numaraları
  • ağ mac adresi
  • Dünya yüzeyindeki noktalar için enlem, boylam

Mümkün olduğunda ve makul olduğunda, hatta tablo başına birden fazla anahtar bildirmenizi öneririm. Ancak yukarıdakilerin hepsinin istisnaları olabileceğini unutmayın.

  • Bazı veritabanı koşullarında bu kabul edilebilir olsa da, herkesin bir e-posta adresi yoktur. Ayrıca, insanlar zaman zaman e-posta adreslerini değiştirirler. (Daha sonra anahtar kararlılığı hakkında daha fazla bilgi.)
  • ISIN hisse senedi sembolleri zaman zaman değişir, örneğin GOOG ve GOOGL sembolleri, şirketin Google'dan Alphabet'e yeniden yapılanmasını doğru bir şekilde tanımlamaz. TWTR ve TWTRQ'da olduğu gibi, bazen kafa karışıklığı ortaya çıkabilir, bazı yatırımcılar yanlışlıkla ikincisini Twitter halka arzı sırasında satın aldı.
  • Sosyal Güvenlik numaraları yalnızca ABD vatandaşları tarafından kullanılır, mahremiyet kısıtlamaları vardır ve ölümden sonra yeniden kullanılır. Ayrıca belgelerin çalınmasından sonra kişiler yeni numaralar alabilirler. Son olarak, aynı numara hem bir kişiyi hem de bir gelir vergisi tanımlayıcısını tanımlayabilir.
  • Posta kodları şehirler için kötü bir seçimdir. Bazı şehirlerin ortak bir indeksi vardır veya tam tersi, bir şehirde birkaç indeks vardır.

5.4 Yapay anahtarlar

Anahtarın her satırda benzersiz değerlere sahip bir sütun olduğu göz önüne alındığında, onu oluşturmanın bir yolu hile yapmaktır - her satıra hayali benzersiz değerler yazabilirsiniz. Bunlar yapay anahtarlardır: verilere veya nesnelere atıfta bulunmak için kullanılan icat edilmiş kod.

Kodun veri tabanından üretilmesi ve veri tabanı kullanıcıları dışında kimse tarafından bilinmemesi çok önemlidir. Yapay anahtarları standartlaştırılmış doğal anahtarlardan ayıran şey budur.

Doğal anahtarlar bir tablodaki yinelenen veya tutarsız satırlara karşı koruma avantajına sahipken, yapay anahtarlar yararlıdır çünkü insanların veya diğer sistemlerin satıra başvurmasını kolaylaştırır ve kullanmadıkları için aramaları ve birleştirmeleri hızlandırırlar. dizi (veya çoklu sütun) karşılaştırmaları.

Suretler

Yapay anahtarlar çapa olarak kullanılır - kurallar ve sütunlar nasıl değişirse değişsin, bir satır her zaman aynı şekilde tanımlanabilir. Bu amaçla kullanılan yapay anahtara "vekil anahtar" adı verilir ve özel dikkat gerektirir. Aşağıda vekilleri ele alacağız.

Yedek olmayan yapay anahtarlar, veritabanının dışından bir satıra başvurmak için kullanışlıdır. Yapay bir anahtar kısaca bir veriyi veya nesneyi tanımlar: URL olarak belirtilebilir, faturaya eklenebilir, telefonla dikte ettirilebilir, bir bankadan alınabilir veya bir araç plakasına yazdırılabilir. (Bir arabanın plakası bizim için doğal bir anahtardır, ancak devlet tarafından yapay bir anahtar olarak tasarlanmıştır.)

Sentetik anahtarlar, yazım hatalarını ve hataları en aza indirmek için olası iletim araçları dikkate alınarak seçilmelidir. Anahtarın konuşulabileceği, yazdırılabileceği, SMS ile gönderilebileceği, el yazısıyla okunabileceği, klavyeden girilebileceği ve bir URL'ye gömülebileceği unutulmamalıdır. Ek olarak, kredi kartı numaraları gibi bazı yapay anahtarlar, belirli hatalar oluşursa en azından tanınabilmeleri için bir sağlama toplamı içerir.

Örnekler:

  • ABD plakaları için, O ve 0 gibi belirsiz karakterlerin kullanımına ilişkin kurallar vardır.
  • Doktorların el yazısı göz önüne alındığında, hastaneler ve eczaneler özellikle dikkatli olmalıdır.
  • Kısa mesajla onay kodu gönderiyor musunuz? GSM 03.38 karakter setinin ötesine geçmeyin.
  • Rastgele bayt verilerini kodlayan Base64'ün aksine, Base32, insanların eski bilgisayar sistemlerinde kullanması ve işlemesi için uygun olan sınırlı bir karakter kümesi kullanır.
  • Proquint'ler okunabilir, yazılabilir ve telaffuz edilebilir tanımlayıcılardır. Bunlar, kesin olarak anlaşılan ünsüzlerin ve ünlülerin PRO-nouncable QUINT-uplet'leridir.

Yapay anahtarınızı dünyaya tanıttığınız anda insanların garip bir şekilde ona özel ilgi göstermeye başlayacağını unutmayın. Sadece "hırsızlar" plakalarına veya rezil otomatik lanet üreteci haline gelen telaffuz edilebilir tanımlayıcılar oluşturma sistemine bakın.

Kendimizi sayısal tuşlarla sınırlasak bile on üçüncü kat gibi tabular var. Proquint'ler konuşulan hece başına daha yüksek bir bilgi yoğunluğuna sahipken, sayılar da birçok yönden uygundur: alıcı anahtarın yalnızca sayılar olduğunu bildiği sürece URL'lerde, pin klavyelerde ve el yazısı notlarda.

Ancak, kaynakları (/videos/1.mpeg, /videos/2.mpeg vb.) karıştırmanıza izin verdiği ve aynı zamanda numara hakkında bilgi sızdırdığı için genel sayısal anahtarlarda sıralı sıra kullanmamanız gerektiğini lütfen unutmayın. veri. Bir sayı dizisinin üzerine bir Feistel ağı yerleştirin ve sayıların sırasını gizlerken benzersizliği koruyun.

Ek anahtarların bildirilmesine karşı tek argüman, her yeni anahtarın beraberinde başka bir benzersiz dizin getirmesi ve tabloya yazma maliyetini artırmasıdır. Elbette, verilerin doğruluğunun sizin için ne kadar önemli olduğuna bağlıdır, ancak büyük olasılıkla anahtarların yine de bildirilmesi gerekir.

Varsa, birkaç yapay anahtar bildirmeye değer. Örneğin, bir kuruluşun iş adayları (Başvuru Sahipleri) ve çalışanları (Çalışanlar) vardır. Her çalışan bir zamanlar adaydı ve adayları, aynı zamanda çalışanın anahtarı olması gereken kendi tanımlayıcılarına göre ifade ediyor. Başka bir örnek olarak, Çalışanlar'da çalışan kimliğini ve oturum açma adını iki anahtar olarak ayarlayabilirsiniz.

5.5 Yedek anahtarlar

Daha önce bahsedildiği gibi, önemli bir yapay anahtar türü "vekil anahtar" olarak adlandırılır. Diğer yapay anahtarlar gibi kısa ve öz olması gerekmez, ancak her zaman dizeyi tanımlayan dahili bir etiket olarak kullanılır. SQL'de kullanılır, ancak uygulama ona açıkça erişmez.

PostgreSQL'in sistem sütunlarına aşina iseniz, suretleri neredeyse bir veritabanı uygulama parametresi (ctid gibi) olarak düşünebilirsiniz, ancak bu asla değişmez. Yedek değer her satırda bir kez seçilir ve bundan sonra asla değişmez.

ON UPDATE RESTRICTVekil anahtarlar, yabancı anahtarlar kadar harikadır ve vekilin değişmezliğine uyması için kademeli kısıtlamalar belirtilmelidir .

ON UPDATE CASCADEÖte yandan, genel olarak paylaşılan anahtarların yabancı anahtarları maksimum esneklik sağlamak için ile işaretlenmelidir . Basamaklı bir güncelleme, çevreleyen işlemle aynı yalıtım seviyesinde çalışır, bu nedenle eşzamanlılık sorunları konusunda endişelenmeyin - katı bir yalıtım düzeyi seçerseniz veritabanı sorunsuz olacaktır.

Yedek anahtarları "doğal" yapmayın. Yedek anahtarın değerini son kullanıcılara gösterdiğinizde veya daha kötüsü, bu değerle çalışmasına izin verdiğinizde (özellikle bir arama aracılığıyla), anahtara etkili bir şekilde bir değer vermiş olursunuz. Ardından, veritabanınızdan gösterilen anahtar, başka birinin veritabanında doğal bir anahtar olabilir.

Harici sistemleri aktarım için özel olarak tasarlanmış diğer yapay anahtarları kullanmaya zorlamak, bu anahtarları değişen ihtiyaçları karşılamak için gerektiğinde değiştirmemize olanak tanırken, vekillerle dahili referans bütünlüğünü korur.

Otomatik artış INT/BIGINT

Yedek anahtarların en yaygın kullanımı, IDENTITY olarak da bilinen otomatik artan "bigserial" sütunudur . (Aslında PostgreSQL 10, Oracle gibi artık IDENTITY yapısını desteklemektedir, bkz. TABLO OLUŞTUR.)

Ancak, otomatik artan bir tamsayının vekil anahtarlar için kötü bir seçim olduğuna inanıyorum. Bu görüş popüler değil, o yüzden açıklayayım.

Seri anahtarların dezavantajları:

  • Tüm diziler 1'den başlar ve kademeli olarak artarsa, farklı tablolardaki satırlar aynı anahtar değerlere sahip olacaktır. Bu seçenek ideal değildir, yine de tablolarda ayrık anahtar kümelerinin kullanılması tercih edilir, böylece örneğin, sorgular kazara sabitleri karıştıramaz JOINve beklenmeyen sonuçlar döndürmez. (Alternatif olarak, kesişme olmadığından emin olmak için, her dizi farklı asal sayıların katlarından oluşturulabilir, ancak bu oldukça zahmetli olacaktır.)
  • Günümüzün dağıtılmış SQL'inde bir dizi oluşturma çağrısı, nextval() tüm sistemin iyi ölçeklenmemesine neden olur.
  • Sıralı anahtarlar da kullanan bir veritabanından veri tüketmek, sıralı değerler sistemler arasında benzersiz olmayacağından çakışmalara neden olacaktır.
  • Felsefi bir bakış açısından, sayıların ardışık olarak artması, satırların sırasının ima edildiği eski sistemlerle ilişkilendirilir. Şimdi satırları sıralamak istiyorsanız, bunu açıkça bir zaman damgası sütunu veya verilerinizde anlamlı olan bir şeyle yapın. Aksi takdirde birinci normal form bozulur.
  • Zayıf sebep, ancak bu kısa tanımlayıcılar birine söylemek için cazip geliyor.

UUID

Başka bir seçeneğe bakalım: rastgele bir modele göre oluşturulmuş büyük tamsayıları (128 bit) kullanmak. Bu tür evrensel olarak benzersiz tanımlayıcılar (UUID'ler) oluşturmaya yönelik algoritmaların, aynı anda iki farklı işlemci üzerinde çalışırken bile aynı değeri iki kez seçme olasılığı son derece düşüktür.

Bu durumda, UUID'ler yedek anahtar olarak kullanmak için doğal bir seçim gibi görünüyor, değil mi? Satırları benzersiz bir şekilde etiketlemek istiyorsanız, benzersiz bir etiketi hiçbir şey yenemez!

Öyleyse neden herkes bunları PostgreSQL'de kullanmıyor? Bunun birkaç uydurma nedeni ve üzerinde çalışılabilecek bir mantıklı nedeni var ve ben de amacımı açıklamak için karşılaştırmalı değerlendirmeler sunacağım.

İlk olarak, abartılı sebeplerden bahsedeceğim. Bazı insanlar, UUID'lerin dizeler olduğunu düşünür çünkü bunlar geleneksel onaltılık gösterimde kısa çizgi ile yazılır: 5bd68e64-ff52-4f54-ace4-3cd9161c8b7f. Aslında, bazı veritabanlarının kompakt (128 bit) bir uuid türü yoktur, ancak PostgreSQL'in boyutu ikidir ve vardır, bigintyani, veritabanındaki diğer bilgilerin miktarına kıyasla, ek yük ihmal edilebilir düzeydedir.

UUID'ler ayrıca haksız yere hantal olmakla suçlanıyor, ancak onları kim telaffuz edecek, yazacak veya okuyacak? Yapay anahtarların gösterilmesinin mantıklı olduğunu ancak (tanım gereği) hiç kimsenin vekil UUID'yi görmemesi gerektiğini söyledik. Sistem hatalarını ayıklamak için psql'de SQL komutları çalıştıran bir geliştirici tarafından UUID ile ilgilenilmesi mümkündür, ancak hepsi bu kadar. Ayrıca geliştirici, verilirse daha uygun anahtarlar kullanarak dizelere başvurabilir.

UUID'lerle ilgili asıl sorun, yüksek oranda rastgele değerlerin, önden yazma günlüğüne (WAL) tam sayfa yazma nedeniyle yazma amplifikasyonuna yol açmasıdır . Ancak, performans düşüşü aslında UUID oluşturma algoritmasına bağlıdır.

Yazma amplifikasyonunu ölçelim . Gerçekte, sorun eski dosya sistemlerindedir. PostgreSQL diske yazdığında, diskteki "sayfayı" değiştirir. Bilgisayarın gücünü kapatırsanız, çoğu dosya sistemi, veriler güvenli bir şekilde diskte depolanmadan önce yine de başarılı bir yazma işlemi bildirir. PostgreSQL saf bir şekilde böyle bir eylemi tamamlanmış olarak algılarsa, bir sonraki sistem önyüklemesi sırasında veritabanı bozulur.

PostgreSQL, sürekliliği sağlamak için çoğu işletim sistemine/dosya sistemine/disk yapılandırmasına güvenemeyeceğinden, veritabanı değiştirilen disk sayfasının tam durumunu, olası bir çökmeden kurtarmak için kullanılabilecek bir önden yazma günlüğüne kaydeder. UUID'ler gibi yüksek oranda rasgele değerlerin indekslenmesi tipik olarak bir grup farklı disk sayfasını içerir ve her yeni giriş için tam sayfa boyutunun (genellikle 4 veya 8 KB) WAL'a yazılmasıyla sonuçlanır. Bu sözde tam sayfa yazmadır (tam sayfa yazma, FPW).

Bazı UUID oluşturma algoritmaları (Twitter'ın "snowflake" veya PostgreSQL'in uuid-ossp uzantısındaki uuid_generate_v1() gibi) her makinede monoton artan değerler üretir. Bu yaklaşım, yazma işlemlerini daha az disk sayfasında birleştirir ve FPW'yi azaltır.

5.6 Sonuçlar ve tavsiyeler

Artık farklı anahtar türlerini ve kullanımlarını gördüğümüze göre, bunları veritabanlarınızda kullanma önerilerimi sıralamak istiyorum.

Her tablo için:

  • Tüm doğal anahtarları tanımlayın ve bildirin.
  • varsayılan değeri olan UUID<table_name>_id türünde bir vekil anahtar oluşturun . Hatta birincil anahtar olarak işaretleyebilirsiniz. Tablonun adını bu tanımlayıcıya eklerseniz, bu basitleşecek , örn. yerine alın . Bu anahtarı istemcilere iletmeyin ve veritabanının dışında hiçbir şekilde göstermeyin.uuid_generate_v1()JOINJOIN foo USING (bar_id)JOIN foo ON (foo.bar_id = bar.id)
  • içinden geçen ara tablolar için JOIN, tüm yabancı anahtar sütunlarını tek bir bileşik birincil anahtar olarak bildirin.
  • İsteğe bağlı olarak, URL'de veya diğer dize referans göstergelerinde kullanılabilecek yapay bir anahtar ekleyin. Otomatik artan tamsayıları maskelemek için bir Feistel ızgarası veya pg_hashids kullanın .
  • ON UPDATE RESTRICTYedek UUID'leri yabancı anahtarlar olarak ve yapay yabancı anahtarlar için kullanarak kademeli bir kısıtlama belirtin ON UPDATE CASCADE. Kendi mantığınıza göre doğal anahtarları seçin.

Bu yaklaşım, doğal anahtarlara izin verirken ve hatta korurken dahili anahtarların kararlılığını sağlar. Ayrıca, görünür yapay anahtarlar hiçbir şeye eklenmez. Her şeyi doğru anladıktan sonra, yalnızca "birincil anahtarlara" takılıp anahtar kullanmanın tüm olanaklarını kullanamazsınız.