DynamoDB yabancı anahtarları destekliyor mu?

Hayır. DynamoDB'de yabancı anahtar, başvuru bütünlüğü kısıtı ya da art arda silme yoktur — bir NoSQL veritabanı olarak öğeler ya da tablolar arasındaki ilişkileri asla zorunlu kılmaz. Bunun yerine ilişkileri kendiniz modellersiniz: ilgili veriyi tek bir öğeye denormalize edin ya da tek tablo tasarımıyla ilgili öğeleri paylaşılan bir bölüm anahtarı altında bir araya toplayın. Modellenen bu ilişkileri görmek ve üzerlerinde gezinmek için DynoTable Smart Table özelliği, iki tablo arasındaki ilişkiyi bir tuval üzerinde çizer ve birleştirilmiş satırlara göz atmanızı sağlar.

Neden yabancı anahtar yok

Bir yabancı anahtar, normalleştirilmiş tablolar genelinde join'leri desteklemek ve bütünlüğü zorunlu kılmak için vardır. DynamoDB, JOIN işlecini bilinçli olarak dışarıda bırakır (AWS bunun yerine denormalizasyonu önerir), dolayısıyla bir yabancı anahtar kısıtı, sorgu modelinin hiç yararlanmadığı bir ilişkiyi denetlemiş olurdu. Başka bir öğenin anahtarını bir öznitelik olarak depolamanıza hiçbir şey engel değildir — DynamoDB yalnızca onu doğrulamaz ya da art arda uygulamaz.

İlişkiler bunun yerine nasıl modellenir

Gömün — küçük ve sınırlı alt veri, üst öğenin içinde bir liste ya da map olarak yaşar.
Bir araya toplayın — üst ve alt öğeler farklı sıralama anahtarlarıyla bir bölüm anahtarını paylaşır, böylece tek bir Query ilişkinin tamamını döndürür; bu, tek tablo tasarımının kalbidir.
Çoğaltın — her erişim deseninin ihtiyaç duyduğu alanları, ihtiyaç duyan öğelere kopyalayın; tek istekli okumalar karşılığında yazma zamanı bakımı kabul edin.

Bire-çok ve çoka-çok kılavuzları her biçimi derinlemesine anlatır.

Bütünlük önemli olduğunda onu zorunlu kılmak

Bir kısıta yaslanacağınız durumlar için DynamoDB size yapı taşları verir: koşul ifadeleri bir yazmayı, yazılan öğenin durumuna göre korur ve bir işlemin ConditionCheck'i, aynı ya-hep-ya-hiç işlem içinde farklı bir öğenin (diyelim ki üst öğenin) var olduğunu doğrulayabilir. Art arda silmeler ise açık uygulama mantığına ya da Streams güdümlü bir temizliğe dönüşür.

Çalıştırdığınızda bu neye benziyor

pk = "CUSTOMER#1" altına bir PROFILE öğesi ve iki ORDER# öğesi koyduk, profili sildik ve bölümü yeniden sorguladık:

Count: 2
[{"sk":{"S":"ORDER#1"},"pk":{"S":"CUSTOMER#1"}},
 {"sk":{"S":"ORDER#2"},"pk":{"S":"CUSTOMER#1"}}]

Silme başarı döndürdü. İki öksüz, uyarı yok, yakalanacak hata yok. PostgreSQL'de aynı silme, hangi kısıtı bildirdiğinize bağlı olarak başarısız olur, art arda uygulanır ya da alt başvuruyu null yapar.

Sonra en yakın ikame: üçüncü bir siparişi yazmadan önce üst öğeyi koşul denetiminden geçiren bir TransactWriteItems.

TransactionCanceledException: Transaction cancelled, please refer cancellation
reasons for specific reasons [ConditionalCheckFailed, None]

CancellationReasons: [
  {"Code":"ConditionalCheckFailed","Message":"The conditional request failed."},
  {"Code":"None"}
]

Dizi konumları TransactItems konumlarınızla eşleşir, dolayısıyla [ConditionalCheckFailed, None], eylem 0'ın (üst öğe denetimi) başarısız olduğunu ve eylem 1'in (alt öğe yazması) sorunsuz olduğunu söyler. Tek korumayla bu düz okunur; sekiz eylemle o dizi, hangisinin bozulduğunu öğrenmenin tek yoludur.

Fatura da çıkarır. İşlemsel bir yazma öğe başına iki yazma birimi tüketir ve AWS açıkça belirtir: "this capacity is consumed even when the transaction is canceled". Reddedilen her yazma, kabul edilen bir yazmayla aynı fiyattadır.

Daha derine inin

Tek tablo tasarımıyla başlayın, koruyucu koşulları ifade oluşturucuda kurun ve bu ilişkilere görsel olarak göz atmak için DynoTable'ı indirin — Smart Table özelliği, üst ve alt tabloları bir tuval üzerinde birleştirir, böylece öğe koleksiyonunun tamamını tek bir görünümde görürsünüz.

Kaynaklar

En son 2026-07-13 tarihinde yukarıda bağlantısı verilen resmi AWS belgelerine karşı doğrulandı.

Öksüz kalan alt öğeler sorgusu ve iptal çıktısı, 2026-07-28 tarihinde Node v24.18.0 üzerinde @aws-sdk/client-dynamodb 3.1095.0 ile DynamoDB Local 3.3.0'a karşı yeniden üretildi.