Normalisasi Database vs dependensi

Saya mengembangkan 3-4 program yang saling tergantung. Sebut mereka foo bar baz dan auth. Saya ingin mereka mandiri satu sama lain. Bayangkan jika saya melisensikan setiap program ke perusahaan lain. Beberapa perusahaan mungkin menginginkan foo dan bar, yang lain mungkin hanya ingin baz, dll. Ini juga tampak seperti praktik yang baik untuk menjaga independensi juga.

Konteks: auth menjaga otentikasi untuk semua sistem. Tabel pengguna utama dalam auth memiliki user_id, email, kata sandi, pertama, terakhir

foo juga memiliki tabel pengguna yang memiliki bidang khusus untuk aplikasi: user_id, role_id, dll.

Setiap sistem memiliki database sendiri. Di masa lalu saya telah membuat kunci asing dari setiap aplikasi ke db auth. Saya menghapus izin pembaruan dari dbs lain tetapi memberikan akses pilih ke bidang tertentu yang relevan. Ini sepertinya solusi yang buruk karena menciptakan ketergantungan yang ketat, tetapi memungkinkan saya untuk menormalkan db sehingga saya tidak perlu menyimpan nama pengguna dan email di database foo, bar, atau baz.

Apakah lebih baik menyimpan informasi di semua basis data? Atau lebih baik menyimpan Auth Id di foo bar dan baz dan menggunakan api untuk mendapatkan info pengguna menggunakan authId?

Demikian pula, saya mungkin memiliki pelanggan di ketiga sistem. Tentu sepertinya buruk untuk membuat ketergantungan menjadi auth db, tapi bagaimana dengan pelanggan dbs di ketiganya?

Atau solusi terbaik untuk memiliki satu pusat db. Satu tabel pengguna.

Saran Lainnya?

Jika Anda memiliki 4 layanan independen, maka mereka harus independen. Tidak ada data yang harus dibagikan dalam DB umum atau serupa, karena Anda hanya membuatnya tergantung!

Sekarang sementara OK untuk berbagi DB tunggal dalam produksi, layanan harus menggunakan skema mereka sendiri untuk DB hanya ada sebagai wadah umum, mirip dengan bagaimana server Linux tunggal dapat menjalankan semua 4 layanan.

Setiap layanan harus memiliki API sendiri, dan ini adalah satu-satunya cara untuk mendapatkan data masuk dan keluar dari masing-masing. Jadi layanan auth Anda akan menyimpan pengguna dan melakukan otentikasi, tetapi akan mengembalikan beberapa token untuk mengidentifikasi pengguna. Token ini adalah apa yang digunakan layanan lain untuk mengingat pengguna mana yang - tetapi sebaliknya mereka seharusnya tidak memiliki pengetahuan tentang otentikasi pengguna sama sekali.

Cara termudah untuk memikirkan penerapan ini adalah dengan memikirkan apa yang akan Anda lakukan jika Anda memutuskan untuk menggunakan layanan pihak ke-3 alih-alih yang Anda tulis - jika Anda menggunakan layanan OpenID StackExchange untuk pengguna alih-alih milik Anda. Jika Anda dapat menggantinya dengan arsitektur Anda, maka Anda memiliki desain yang bagus dan independen.

Teladan Anda sedikit abstrak, tetapi biarkan saya menelusuri pikiran saya.

Opsi A: Dalam pengalaman saya ini Selalu Buruk terlepas dari alasan Anda. yakin DB seperti MSSQL dapat memiliki database teman dll, tetapi jika datanya ditautkan, itu harus dalam DB yang sama

Opsi B: Tidak yakin apa yang terjadi di sini, Anda menambahkan API yang menanyakan semua DB dan menyatukan hasilnya? Ini lebih baik, tetapi jika Anda memiliki aplikasi di atas API itu maka bagian dari datalayer untuk mereka dan mereka benar-benar hanya menggunakan salah satu DB, jadi mengapa mereka punya yang lain di lapisan data mereka?

Opsi C: Ya ini berfungsi, tetapi tidak baik untuk memiliki satu database besar dengan data yang tidak terkait di dalamnya. Anda ingin program independen satu sama lain, kan? dosnt ini membantu dengan itu.

Opsi D

Saran saya adalah mengabstraksi otentikasi dari konsep userId. Aplikasi Auth Anda harus peduli dengan pengguna dan peran (atau janji dll jika Anda semua modern) data ini harus ada dalam DB Auth

Setiap Aplikasi perlu memiliki userId untuk mengelompokkan data berdasarkan pengguna, dengan beberapa data terkait untuk melakukan panggilan auth dan mengidentifikasi pengguna ke manusia. ini akan menjadi userId (unik untuk aplikasi), nama asli, nama pengguna, layanan auth untuk digunakan. Data ini harus ada di aplikasi DB

Basis data tidak boleh memiliki koneksi di antara mereka, secara konseptual Anda harus dapat menggunakan facebook sebagai layanan auth Anda daripada aplikasi auth Anda

Anda mungkin memerlukan informasi lebih lanjut yang menghubungkan pengguna jika Anda ingin menghubungkan pengguna foo dengan pengguna bar

Saya akan merekomendasikan menerapkan Single Sign On (SSO), misalnya dengan LDAP. Pelanggan Anda yang lebih besar mungkin akan mendapat manfaat darinya juga, karena mereka akan dapat mengganti aplikasi auth bawaan Anda dengan database pengguna mereka sendiri yang sudah ada. Untuk pelanggan Anda yang lebih kecil yang tidak mendukung SSO, Anda dapat menyederhanakan penerapan dengan mengirimkan aplikasi Anda dengan aplikasi auth default.