Struktur Database SQL untuk API TENANG

11

Saya membuat API yang tenang. Saya berjuang untuk memutuskan cara terbaik untuk merancang tabel database saya di sekitar sumber daya saya.

Awalnya, saya pikir tabel per sumber daya akan menjadi cara yang baik untuk pergi, tetapi saya sekarang khawatir bahwa ini akan menghasilkan tabel secara eksponensial lebih besar semakin jauh ke bawah rantai sumber daya yang Anda tuju.

Sebagai contoh, bayangkan saya memiliki tiga sumber daya - pengguna, klien, penjualan. Pengguna adalah pelanggan api saya, klien adalah pelanggan pengguna, dan penjualan adalah pembelian yang dilakukan oleh setiap klien ke akun pengguna.

Sumber daya penjualan diakses sebagai berikut

GET /users/{userID}/clients/{clientID}/sales/{salesID}

Jadi jika ada 10 pengguna, masing-masing dengan 10 pelanggan, dan untuk setiap pelanggan ada 10 penjualan, ukuran tabel semakin besar semakin jauh ke bawah rantai sumber daya yang kami tuju.

Saya cukup yakin bahwa SQL dapat mengatasi tabel besar, tapi saya tidak yakin bagaimana membaca dan menulis akan memperlambat segalanya. Contoh di atas mungkin tidak menggambarkannya, tetapi api saya akan memiliki semakin banyak menulis dan membaca lebih lanjut di rantai sumber daya yang kita tuju. Karena itu saya punya skenario di mana tabel terbesar di database saya, akan dibaca dan ditulis lebih dari kali tabel kecil.

Gabungan tabel juga diperlukan sebelum menjalankan kueri. Alasannya adalah bahwa saya mengizinkan setiap pengguna untuk memiliki klien dengan nama yang sama. Untuk menghindari kesalahan data klien, tabel pengguna dan tabel klien digabungkan dengan {userID}. Ini juga berlaku untuk penjualan. Akankah bergabung dengan meja besar dan menjalankan membaca dan menulis memperlambat lebih lanjut?

database-design performance query-performance

— Gaz_Edge
sumber

31

Saya berjuang untuk memutuskan cara terbaik untuk merancang tabel database saya di sekitar sumber daya saya.

Jangan.

Rancang API Anda sesuai dengan prinsip RESTful , rancang basis data Anda sesuai dengan prinsip normalisasi . Yang satu tidak perlu berdampak pada yang lain.

Database Anda seharusnya tidak mengandung SaleResourcetabel, itu harus berisi tabel Sale(atau pembelian / pesanan). Tabel itu akan menyertakan kunci utama yang secara unik mengidentifikasi Penjualan dan kunci asing ke tabel Pengguna dan Pelanggan terkait.

Anda REST api akan menerjemahkan permintaan untuk sumber daya yang diidentifikasi oleh GET /users/{userID}/clients/{clientID}/sales/{salesID}ke permintaan basis data yang sesuai, mengambil baris, membangun sumber daya yang mewakili Penjualan dan mengembalikannya ke klien.

Berhati-hatilah bahwa saat ini Anda mengekspos apa yang tampak sebagai pengidentifikasi basis data internal (UserID / ClientId / SalesID) ke dunia luar. Ini mungkin sesuai untuk kasus Anda tetapi umumnya <entity>IDterasa tidak nyaman di API yang tenang.

— Mark Storey-Smith
sumber

Terima kasih. Jadi apa yang Anda katakan pada dasarnya adalah bahwa selama saya menormalkan database saya dan mengatur pengindeksan yang sesuai, dll, seharusnya tidak ada masalah kinerja untuk apa yang ingin saya capai

— Gaz_Edge

3

Iya. Tidak ada yang Anda sebutkan yang menyarankan penyimpangan dari skema normalisasi akan diperlukan.

— Mark Storey-Smith

9

Database relasional (karenanya SQL) sangat bagus untuk menemukan satu (atau beberapa) baris dari tabel besar. Inilah gunanya indeks. Mereka juga cukup hebat dalam menangani gabungan. Anda tidak benar-benar memiliki pertanyaan . Yang tersirat, Anda pada dasarnya bertanya tentang bagaimana melakukan desain basis data multi-tenant. Saya sarankan Anda membaca Arsitektur Data Multi-Tenant sebelum mengajukan pertanyaan lebih lanjut. Pilih salah satu pola (database terpisah, skema terpisah database bersama, skema berbagi database bersama) dan kemudian kami dapat mendiskusikan secara spesifik. Saat ini Anda hanya membayangkan pola terakhir, tetapi tidak mempertimbangkan pro dan kontra. Baca.

Sebagai catatan: Anda tidak perlu user/{userID}di URI. Anda mengetahui penyewa (userID) dari info otentikasi.

— Remus Rusanu
sumber

terima kasih- Ya saya perlu membaca lebih lanjut. Proyek saya sampai saat ini hanya memiliki sedikit pekerjaan basis data. Saya akan membaca sumber yang Anda rekomendasikan

— Gaz_Edge

Saya pikir shared-shared adalah cara untuk mengejar saya. 'Pengguna' saya bukan 'penyewa'. Mereka tidak memerlukan data yang terisolasi dan tidak akan pernah memerlukan akses langsung ke fungsi manajemen basis data apa pun. Dari apa yang saya baca, ini akan menyarankan berbagi-pakai yang terbaik? Bagaimana menurut anda?

— Gaz_Edge

2

berbagi adalah yang termudah. Anda harus menambahkan user_idsebagai kunci untuk setiap tabel dan menambahkan left.user_id = right.user_idke gabungan yang relevan (biasanya, semua). Beberapa ORM mendukung untuk menghentikan akses. Dan jangan tertipu, pengguna Anda adalah penyewa, karena Anda tidak ingin pengguna 'foo' melihat / memodifikasi penjualan 'bar' pengguna.

— Remus Rusanu

Terima kasih. Saya mulai melihat bahwa indeks adalah kunci untuk membuat struktur basis data saya.

— Gaz_Edge

0

Hanya untuk menambah apa yang telah dikatakan di sini - Anda mungkin ingin membangun antarmuka antara API aktual dan lapisan basis data Anda. Itu membuat menambahkan tabel caching dan ringkasan lebih mudah ...

— Matt Koskela
sumber

1

beberapa tautan atau penjelasan lebih lanjut akan membantu

— Gaz_Edge

Maaf, belum dapat berkomentar ..

— Matt Koskela