Gunakan alamat email sebagai kunci utama?

Apakah alamat email kandidat yang buruk untuk primer jika dibandingkan dengan nomor yang bertambah secara otomatis?

Aplikasi web kami membutuhkan alamat email untuk menjadi unik dalam sistem. Jadi, saya berpikir untuk menggunakan alamat email sebagai kunci utama. Namun kolega saya menyarankan bahwa perbandingan string akan lebih lambat daripada perbandingan integer.

Apakah itu alasan yang sah untuk tidak menggunakan email sebagai kunci utama?

Kami menggunakan PostgreSQL.

Perbandingan string lebih lambat dari perbandingan int. Namun, ini tidak masalah jika Anda hanya mengambil pengguna dari basis data menggunakan alamat email. Tidak masalah jika Anda memiliki kueri kompleks dengan beberapa gabungan.

Jika Anda menyimpan informasi tentang pengguna di beberapa tabel, kunci asing ke tabel pengguna akan menjadi alamat email. Itu berarti Anda menyimpan alamat email beberapa kali.

Saya juga akan menunjukkan bahwa email adalah pilihan yang buruk untuk membuat bidang yang unik, ada orang dan bahkan usaha kecil yang berbagi alamat email. Dan seperti nomor telepon, email dapat digunakan kembali. Jsmith@somecompany.com dapat dengan mudah menjadi milik John Smith satu tahun dan Julia Smith dua tahun kemudian.

Masalah lain dengan email adalah mereka sering berubah. Jika Anda bergabung ke tabel lain dengan itu sebagai kuncinya, maka Anda harus memperbarui tabel lain juga yang bisa menjadi hit kinerja ketika seluruh perusahaan klien mengubah email mereka (yang saya lihat terjadi.)

kunci primer harus unik dan konstan

alamat email berubah seperti musim. Berguna sebagai kunci sekunder untuk pencarian, tetapi pilihan yang buruk untuk kunci utama.

Kerugian menggunakan alamat email sebagai kunci utama:

1. Lebih lambat saat melakukan join.

2. Catatan lain dengan kunci asing yang diposkan sekarang memiliki nilai lebih besar, mengambil lebih banyak ruang disk. (Mengingat biaya ruang disk saat ini, ini mungkin masalah sepele, kecuali sejauh catatan sekarang membutuhkan waktu lebih lama untuk dibaca. Lihat # 1.)

3. Alamat email dapat berubah, yang memaksa semua catatan menggunakan ini sebagai kunci asing untuk diperbarui. Karena alamat email tidak terlalu sering berubah, masalah kinerja mungkin kecil. Masalah yang lebih besar adalah Anda harus memastikan untuk menyediakannya. Jika Anda harus menulis kode, ini lebih banyak pekerjaan dan memperkenalkan kemungkinan bug. Jika mesin basis data Anda mendukung "pada pembaruan kaskade", itu adalah masalah kecil.

Keuntungan menggunakan alamat email sebagai kunci utama:

1. Anda mungkin dapat sepenuhnya menghilangkan beberapa gabungan. Jika semua yang Anda butuhkan dari "catatan utama" adalah alamat email, maka dengan kunci integer abstrak, Anda harus melakukan join untuk mengambilnya. Jika kuncinya adalah alamat email, maka Anda sudah memilikinya dan bergabung tidak perlu. Apakah ini membantu Anda tergantung pada seberapa sering situasi ini muncul.

2. Saat Anda melakukan kueri ad hoc, mudah bagi manusia untuk melihat catatan master apa yang dirujuk. Ini bisa sangat membantu ketika mencoba melacak masalah data.

3. Anda hampir pasti akan memerlukan indeks pada alamat email, jadi menjadikannya kunci utama menghilangkan satu indeks, sehingga meningkatkan kinerja sisipan karena mereka sekarang hanya memiliki satu indeks untuk memperbarui, bukan dua.

Menurut pendapat saya, itu bukan slam-dunk. Saya cenderung lebih suka menggunakan kunci alami ketika yang praktis tersedia karena mereka hanya lebih mudah untuk dikerjakan, dan kerugiannya cenderung tidak terlalu penting dalam banyak kasus.

Ini sangat buruk. Anggap beberapa penyedia email keluar dari bisnis. Pengguna kemudian ingin mengubah email mereka. Jika Anda telah menggunakan email sebagai kunci utama, semua kunci asing untuk pengguna akan menduplikasi email itu, membuatnya sangat sulit untuk diubah ...

... dan saya bahkan belum mulai berbicara tentang pertimbangan kinerja.

Saya tidak tahu apakah itu mungkin menjadi masalah dalam pengaturan Anda, tetapi tergantung pada RDBMS Anda, nilai kolom mungkin peka terhadap huruf besar-kecil . Dokumen PostgreSQL mengatakan: "Jika Anda mendeklarasikan kolom sebagai UNIQUE atau PRIMARY KEY, indeks yang dihasilkan secara implisit adalah case-sensitive". Dengan kata lain, jika Anda menerima input pengguna untuk pencarian di tabel dengan email sebagai kunci utama, dan pengguna memberikan "John@Doe.com", Anda tidak akan menemukan "john@doe.com".

Sepertinya tidak ada yang menyebutkan masalah yang mungkin terjadi bahwa alamat email dapat dianggap pribadi. Jika alamat email adalah kunci utama, URL halaman profil kemungkinan besar akan terlihat seperti itu ..../Users/my@email.com. Bagaimana jika Anda tidak ingin mengekspos alamat email pengguna? Anda harus menemukan cara lain untuk mengidentifikasi pengguna, mungkin dengan nilai integer unik untuk membuat URL seperti ..../Users/1. Maka Anda akan berakhir dengan nilai integer unik.

Pada level logis , email adalah kunci alami. Di fisik tingkat , mengingat Anda menggunakan basis data relasional, kunci alami tidak cocok dengan kunci primer. Alasan utamanya adalah masalah kinerja yang disebutkan oleh orang lain.

Untuk alasan itu, desainnya bisa disesuaikan. Kunci alami menjadi kunci alternatif (UNIK, BUKAN NULL), dan Anda menggunakan kunci pengganti / buatan / teknis sebagai kunci utama, yang dapat menjadi peningkatan otomatis dalam kasing Anda.

systempuntoout bertanya,

Bagaimana jika seseorang ingin mengubah alamat emailnya? Apakah Anda akan mengubah semua kunci asing juga?

Itulah gunanya cascading .

Alasan lain untuk menggunakan kunci pengganti numerik sebagai kunci utama terkait dengan cara kerja pengindeksan di platform Anda. Dalam InnoDB MySQL, misalnya, semua indeks dalam sebuah tabel memiliki kunci primer yang sudah ditentukan sebelumnya, jadi Anda ingin PK sekecil mungkin (untuk kecepatan dan ukurannya). Juga terkait dengan ini, InnoDB lebih cepat ketika kunci primer disimpan secara berurutan, dan sebuah string tidak akan membantu di sana.

Hal lain yang perlu dipertimbangkan ketika menggunakan string sebagai kunci alternatif, adalah menggunakan hash string aktual yang Anda inginkan mungkin lebih cepat, melewatkan hal-hal seperti huruf besar dan kecil pada beberapa huruf. (Aku benar-benar mendarat di sini sambil mencari referensi untuk mengkonfirmasi apa yang baru saja aku katakan; masih mencari ...)

Ya, ini adalah kunci utama yang buruk karena pengguna Anda ingin memperbarui alamat email mereka.

ya, lebih baik jika Anda menggunakan bilangan bulat sebagai gantinya. Anda juga dapat mengatur kolom email Anda sebagai batasan unik.

seperti ini:

CREATE TABLE myTable(
    id integer primary key,
    email text UNIQUE
);

Alasan lain mengapa integer primary key lebih baik adalah ketika Anda merujuk ke alamat email di tabel yang berbeda. Jika alamat itu sendiri adalah kunci utama maka di tabel lain Anda harus menggunakannya sebagai kunci. Jadi, Anda menyimpan alamat email beberapa kali.

Saya tidak terlalu terbiasa dengan postgres. Kunci Utama adalah topik besar. Saya telah melihat beberapa pertanyaan dan jawaban yang bagus di situs ini (stackoverflow.com).

Saya pikir Anda mungkin memiliki kinerja yang lebih baik dengan memiliki kunci primer numerik dan menggunakan INDIK UNIK pada kolom email. Panjang surel cenderung bervariasi dan mungkin tidak sesuai untuk indeks kunci utama.

beberapa bacaan di sini dan di sini.

Secara pribadi, saya tidak menggunakan informasi apa pun untuk kunci primer saat merancang basis data, karena sangat mungkin saya perlu mengubah informasi apa pun nanti. Satu-satunya alasan yang saya berikan kunci utama adalah, itu adalah kemudahan untuk melakukan sebagian besar operasi SQL dari sisi klien, dan pilihan saya untuk itu selalu merupakan tipe integer kenaikan otomatis.

Kolega Anda benar: Gunakan bilangan bulat peningkatan otomatis untuk kunci utama Anda.

Anda dapat menerapkan keunikan email baik di tingkat aplikasi, atau Anda dapat menandai kolom alamat email Anda sebagai unik, dan menambahkan indeks pada kolom itu.

Menambahkan bidang sebagai unik hanya akan dikenakan biaya perbandingan string saat menyisipkan ke dalam tabel itu, dan bukan saat melakukan pemeriksaan gabungan dan kunci asing.

Tentu saja, Anda harus perhatikan bahwa menambahkan kendala apa pun ke aplikasi Anda di tingkat basis data dapat menyebabkan aplikasi Anda menjadi tidak fleksibel. Selalu berikan pertimbangan sebelum Anda membuat bidang apa pun "unik" atau "tidak nol" hanya karena aplikasi Anda memerlukannya unik atau tidak kosong.

Gunakan GUID sebagai kunci utama ... dengan cara itu Anda dapat menghasilkannya dari program saat Anda melakukan INSERT dan Anda tidak perlu mendapatkan respons dari server untuk mengetahui apa kunci utama itu. Ini juga akan menjadi tabel dan basis data unik dan Anda tidak perlu khawatir tentang apa yang terjadi jika Anda memotong tabel suatu hari dan kenaikan otomatis akan diatur ulang ke 1.

Saya tahu ini sedikit entri yang terlambat tetapi saya ingin menambahkan bahwa orang-orang meninggalkan akun email dan penyedia layanan memulihkan alamat yang memungkinkan orang lain untuk menggunakannya.

Sebagaimana @HLGEM tunjukkan, "Jsmith@somecompany.com dapat dengan mudah menjadi milik John Smith satu tahun dan Julia Smith dua tahun kemudian." dalam hal ini seandainya John Smith menginginkan layanan Anda, Anda harus menolak untuk menggunakan alamat emailnya atau menghapus semua catatan Anda yang berkaitan dengan Julia Smith.

Jika Anda harus menghapus catatan dan itu berkaitan dengan sejarah keuangan bisnis tergantung pada hukum setempat Anda dapat menemukan diri Anda dalam air panas.

Jadi saya tidak akan pernah menggunakan data seperti alamat email, plat nomor, dll. Sebagai kunci utama karena tidak peduli seberapa unik mereka tampaknya berada di luar kendali Anda dan dapat memberikan beberapa tantangan menarik yang mungkin Anda tidak punya waktu untuk berurusan.

Anda mungkin perlu mempertimbangkan peraturan perundang-undangan data yang berlaku. Email adalah informasi pribadi, dan jika pengguna Anda adalah warga negara UE misalnya, maka berdasarkan GDPR mereka dapat menginstruksikan Anda untuk menghapus informasi mereka dari catatan Anda (ingat ini berlaku terlepas dari negara mana Anda berada).

Jika Anda perlu menyimpan catatan itu sendiri dalam database untuk integritas referensial atau alasan historis seperti audit, menggunakan kunci pengganti akan memungkinkan Anda untuk hanya NULL semua bidang data pribadi. Ini jelas tidak mudah jika data pribadi mereka adalah kunci utama

Anda dapat meningkatkan kinerja dengan menggunakan kunci primer integer.

Anda harus menggunakan kunci utama integer. jika Anda ingin kolom email menjadi unik, mengapa Anda tidak mengatur indeks unik pada kolom itu saja?

Jika Anda memiliki nilai non int sebagai kunci utama maka penyisipan dan pengambilan akan sangat lambat pada data besar.

primary key harus dipilih atribut statis. Karena alamat email tidak statis dan dapat dibagikan oleh banyak kandidat, maka bukan ide yang baik untuk menggunakannya sebagai kunci utama. Selain itu alamat email adalah string yang biasanya memiliki panjang tertentu yang mungkin lebih besar dari id unik yang ingin kami gunakan [len (email_address)> len (unique_id)] ​​sehingga akan membutuhkan lebih banyak ruang dan bahkan terburuk mereka disimpan beberapa kali sebagai kunci asing . Dan akibatnya itu akan menurunkan kinerja.

Itu tergantung pada tabel. Jika baris di tabel Anda mewakili alamat email, maka email adalah ID terbaik. Jika tidak, maka email bukan ID yang baik.

Jika itu hanya masalah mengharuskan email menjadi unik maka Anda bisa membuat indeks unik dengan kolom itu.

Email adalah kandidat indeks unik yang bagus, tetapi tidak untuk kunci primer, jika itu adalah kunci utama, Anda tidak akan dapat mengubah alamat email kontak misalnya. Saya pikir permintaan bergabung Anda akan lebih lambat juga.

jangan gunakan alamat email sebagai kunci utama, simpan email sebagai unik tetapi jangan gunakan itu sebagai kunci utama, gunakan id pengguna atau nama pengguna sebagai kunci utama