Pemodelan Data

Di sinilah DynamoDB paling jauh menyimpang dari SQL. Anda tidak menormalkan ke dalam satu tabel per entitas — Anda mulai dari pola akses Anda dan merancang key yang melayaninya, sering kali mengemas setiap entitas ke dalam satu tabel tunggal. Dilakukan dengan benar, Anda mengambil induk dan anak-anaknya dalam satu Query, tanpa join.

Dilakukan dengan salah, Anda mendapat tabel yang tidak bisa di-query dan migrasi yang tidak bisa dijalankan. Jadi trade-off-nya penting, dan bagian ini jujur tentang kasus-kasus di mana single-table design adalah pilihan yang salah.

0 dari 7 dibacaKuis

Single-Table Design di DynamoDB

Single-table design di DynamoDB — mengapa satu tabel dengan key yang ditumpangi mengalahkan satu tabel per entitas, dengan contoh order/customer konkret dan pola overloading GSI.

Menengah4 menit baca

Cara Memodelkan Data di DynamoDB

Cara memodelkan data di DynamoDB dengan cara mengutamakan pola akses — panduan langkah demi langkah yang mengubah query sebuah leaderboard multiplayer menjadi partition dan sort key.

Menengah8 menit baca

Kapan TIDAK Menggunakan Single-Table Design di DynamoDB

Kapan TIDAK menggunakan single-table design di DynamoDB — beban kerja di mana multiple table menang (analitik berat, CRUD sederhana, scaling independen), dengan contoh konkret.

Menengah6 menit baca

Atribut Type di DynamoDB

Atribut Type DynamoDB — mengapa Anda menstempel tipe entitas pada setiap Item untuk mengidentifikasi baris, memfilter sebuah GSI menjadi satu entitas, dan bertahan dari migrasi di masa depan.