Simpan profil pengguna dan pengguna di tabel yang berbeda?


26

Saya telah melihat dalam beberapa proyek bahwa pengembang lebih suka menyimpan informasi pengguna yang penting dalam satu tabel (email / login, kata sandi hash, nama layar) dan sisa profil pengguna yang tidak penting di yang lain (tanggal pembuatan, negara, dll). Yang tidak penting maksud saya bahwa data ini hanya diperlukan sesekali. Manfaat yang jelas adalah bahwa jika Anda menggunakan kueri ORM, bidang yang kurang jelas baik. Tapi kemudian Anda dapat memiliki dua entitas yang dipetakan ke tabel yang sama dan ini akan menyelamatkan Anda dari pertanyaan hal-hal yang tidak Anda butuhkan (sambil lebih nyaman) Adakah yang tahu ada manfaat lain dari menyimpan semua ini dalam dua tabel?



1
@Michael, terima kasih! Menarik bahwa tidak ada konsensus di semua pertanyaan terkait.
Andrey

Itu sebabnya saya memilih daftar pertanyaan yang terhubung daripada mencoba menjawabnya sendiri. Itu benar-benar bermuara pada kasus per kasus dan bagaimana aplikasi tertentu sedang dirancang. Ingat, Anda selalu dapat menggunakan tampilan untuk menggabungkan kedua bit jika perlu. Pertimbangkan juga kemungkinan untuk membatalkan tautan satu (menghapus akun), tetapi menjaga yang lain di sekitar (pertanyaan harus ditautkan ke akun, tetapi akun tidak selalu memiliki profil ...). Mungkin pertanyaan yang menarik untuk dilemparkan ke dalam Chat Rekayasa Perangkat Lunak atau menuju ke DBA.SE dan bertanya dalam obrolan mereka.

1
@MichaelT Saya sedang berpikir tentang membuat semacam kerangka kerja umum yang akan menyediakan model Pengguna.
Andrey

Dalam beberapa proyek sebelumnya saya sengaja memindahkan kolom yang diharapkan untuk dituliskan sangat sering ke tabel mereka sendiri untuk tujuan melindungi tabel utama jika file database menjadi rusak atau rusak.
GrandmasterB

Jawaban:


11

Itu tergantung pada ukuran dan persyaratan proyek Anda.

Saya dapat melihat satu cara di mana data tentang pengguna dapat dibagi menjadi dua set, dengan tujuan dan persyaratan yang berbeda:

  • Data identitas: nama pengguna, kata sandi hash, alamat email, waktu login terakhir, dll.
  • Data profil pengguna, yang mencakup preferensi pengguna, aktivitas terbaru, pembaruan status, dll.

Perhatikan bahwa ada beberapa atribut tentang pengguna yang dapat jatuh dalam kategori baik (misalnya tanggal lahir pengguna). Perbedaan antara kedua set ini adalah bahwa yang pertama dikontrol dengan ketat dan hanya melalui alur kerja tertentu yang dapat dimodifikasi. Misalnya, mengubah kata sandi mungkin memerlukan penyediaan kata sandi yang ada, mengubah email mungkin memerlukan verifikasi email, dan itu akan digunakan jika pengguna lupa kata sandi.

Preferensi tidak memerlukan ACL seperti itu, dan secara teoritis dapat dimodifikasi oleh pengguna atau aplikasi lain selama pengguna menyetujuinya. Taruhannya rendah jika aplikasi jahat atau karena bug merusak data atau mencoba memodifikasinya (dengan asumsi langkah-langkah keamanan lain diambil.) Namun, biasanya akan menjadi bencana jika nama pengguna, kata sandi, atau email dapat dimodifikasi karena mereka dapat digunakan untuk mengambil identitas pengguna atau menolak layanan atau menyebabkan biaya dukungan, dll. untuk admin.

Dengan demikian, biasanya data disimpan dalam dua jenis sistem:

  • Data identitas biasanya masuk dalam direktori atau solusi IAM.
  • Data preferensi akan berakhir di basis data.

Karena itu, dalam praktiknya, orang akan melanggar aturan-aturan ini dan menggunakan satu atau yang lain (misalnya SQL server di belakang penyedia keanggotaan ASP.NET).

Ketika data identitas menjadi lebih besar atau organisasi yang menggunakannya menjadi lebih besar, berbagai jenis masalah merayap masuk. Misalnya, dalam kasus direktori, itu akan mencoba mereplikasi perubahan kata sandi segera ke semua server dalam lingkungan multi-server. Namun, preferensi pengguna hanya membutuhkan konsistensi akhirnya. (FYI: Keduanya adalah optimasi yang berbeda dari teorema CAPS.)

Akhirnya, direktori (khususnya direktori online / cloud) juga akan mengeluarkan token akses untuk sumber daya lain menggunakan protokol seperti OAUTH (mis. Pertimbangkan Facebook, Google, Akun Microsoft, ADFS), sedangkan database tidak memerlukannya. Basis data akan mendukung gabungan dan struktur kueri yang cukup rumit, yang direktori tidak perlu.

Untuk lebih jelasnya, beberapa pencarian di direktori identitas vs database akan membantu.

Akhirnya tergantung pada apa skenario Anda dan diharapkan di masa depan, termasuk integrasi dengan pihak ketiga (dan apa yang mereka gunakan). Jika ini adalah proyek yang lengkap dan Anda yakin dapat mengamankan data identitas pengguna dan mengotentikasi dengan benar, maka Anda bisa mencari basis data. Kalau tidak, mungkin perlu menyelidiki direktori identitas.

Jika Anda menggunakan DB, IMO, menggunakan satu DB vs dua akhirnya akan turun ke kontrol akses, baik untuk pengguna dan aplikasi.


3

Ada, setidaknya, tiga kasus ketika memiliki tabel orang untuk atribut dasar dan tabel kedua untuk atribut lain dengan hubungan satu-ke-satu, diinginkan:

  • BLOB data seperti gambar. Tabel terpisah memungkinkan data disimpan secara terpisah karena alasan kinerja, misalnya dalam ruang tabel terpisah.
  • Data yang tidak berlaku untuk semua orang atau yang hanya berlaku untuk seseorang yang memainkan peran tertentu. Anggap saja sebagai kolom yang akan menjadi nol di banyak baris jika mereka adalah bagian dari tabel utama. Dalam database klinik, Anda dapat memiliki tabel orang, tabel pasien dan tabel medis, di yang pertama Anda akan memiliki atribut dasar, di yang kedua hanya atribut yang terkait ketika orang tersebut adalah pasien seperti pertanggungan asuransi, di tabel ketiga (ketika orang tersebut adalah tenaga medis) Anda bisa memiliki spesialisasi medis dan data lain yang hanya berlaku untuk tenaga medis. Jelas seorang tenaga medis bisa menjadi pasien.
  • Tabel yang mewujudkan hubungan dengan entitas di sistem jarak jauh. Dalam hal ini tabel menetapkan kesetaraan antara pengidentifikasi unik dalam database terpisah untuk alasan interoperabilitas.

Saya pikir case yang Anda paparkan cocok dalam case kedua.


1

Alasan utama saya untuk memisahkan mereka adalah untuk mencoba dan menghindari apa yang dikenal dalam pemrograman Berorientasi Objek sebagai 'kelas dewa'. ORM menghubungkan tabel dan bidang dengan kelas dan atribut, sehingga menjadi relevan sebagai level SQL juga (bahkan tanpa ORM ada prinsip yang sama pada umumnya).

Kelas Pengguna (dan berdasarkan asosiasi tabel pengguna) sering tabel yang menjadi kelas dewa dengan ratusan atribut / bidang, puluhan atau ratusan metode dan definisi kelas (untuk metode) lebih dari 1000 baris. Aku sudah melihat semuanya. Lebih dari sekali.

Jadi pemisahan dari pengguna mencoba untuk mengatasinya. Mungkin ada orang, pengguna, akun dan pemisahan kekhawatiran mungkin tampak sedikit buatan tetapi untuk mencoba dan menghindari kerumitan dan memastikan bahwa setiap objek hanya memperhatikan 1 aspek data.


2
Bahkan kelas pengguna yang membengkak masih belum tentu Kelas Dewa. Mungkin membengkak dengan logika terkait pengguna (yang mungkin menjadi rumit dalam proyek-proyek besar), tetapi jika itu tidak memasukkan logika yang tidak terkait saya tidak melihat masalah besar. Saya tidak yakin bagaimana memecahkan 1 kelas menjadi 2 akan menyelesaikan masalah kelas dewa tersebut.
Andrey
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.