Haruskah kunci pengganti pernah terpapar ke pengguna?

14

Seringkali dalam tabel yang tidak memiliki kunci alami, masih berguna bagi pengguna untuk dapat memiliki pengidentifikasi yang dihasilkan secara unik. Jika tabel memiliki kunci utama pengganti (dan dalam kasus seperti itu Anda tentu mengharapkannya) haruskah kunci itu diekspos kepada pengguna atau haruskah bidang lain digunakan untuk tujuan itu?

Salah satu alasan untuk tidak mengekspos kunci pengganti adalah bahwa sekarang Anda tidak dapat melakukan operasi yang menjaga hubungan antara catatan, tetapi mengubah nilai-nilai kunci, seperti beberapa jenis penghapusan / penyisipan ulang, banyak metode menyalin data dari satu database ke lain, dll.

Keuntungan utama dari mengungkap kunci pengganti adalah kesederhanaan menggunakan bidang yang Anda miliki.

Dalam keadaan apa yang lebih baik untuk secara langsung mengekspos kunci pengganti kepada pengguna?

— psr
sumber

Bagian dari pertanyaan ini adalah Anda perlu mendefinisikan 'pengguna.' Pengguna dapat menjadi konsumen API yang Anda paparkan atau manusia berdaging. Jawabannya tidak akan sama untuk keduanya.

— James Snell

1

Manusia berdaging.

— psr

Setiap situasi di mana data dapat diidentifikasi secara berbeda harus memiliki pengidentifikasi yang berbeda. Jadi, jika sistem baru terhubung dengan data Anda, harapkan itu memiliki PK sendiri dan menambahkannya ke data Anda. Visibilitas ke "kantong jelek yang sebagian besar berisi air" dianggap sebagai 'sistem' untuk skenario ini. Solusi pilihan saya adalah menyimpan kunci dan stempel waktu (tambah dan ubah dan hapus) untuk entitas dalam tabel khusus. Dengan cara ini, data dapat didistribusikan dengan mudah.

10

Anda harus siap untuk setiap pengidentifikasi yang terpapar ke pengguna / pelanggan yang perlu diubah, dan mengubah identitas baris dalam database dan menyebarkan bahwa perubahan ke semua kunci asing hanya meminta untuk memecah data.

Jika data tidak memiliki kunci bisnis alami, Anda dapat menambahkan bidang tambahan untuk "pengidentifikasi bisnis". Ini harus dioptimalkan untuk proses yang digunakan. Entri keypad telepon hanya berarti angka. Melalui telepon / verbal berarti menghindari simbol suara yang serupa (B / D, M / N, dll). Anda bahkan dapat membuat sendiri beberapa frasa yang mudah diingat ("jeli hijau").

Efeknya adalah bahwa bisnis nanti dapat mengubah cara mereka ingin merujuk ke catatan, dan satu-satunya perubahan skema data adalah menambahkan kolom baru untuk gaya id itu atau mengubah id yang sudah ada di sana. Perubahan tidak menyebar melalui seluruh database, dan Anda masih memiliki satu id (pengganti) yang valid dari waktu ke waktu.

Singkatnya, saya akan menghindari memperlihatkan kunci pengganti kepada pengguna. Seperti yang ditunjukkan komentar, kunci pengganti hampir tidak pernah berubah. Sebaliknya, bisnis ingin mengubah segalanya. Jika kunci pengganti dibuka, tinggal menunggu waktu sebelum bisnis ingin mengubahnya.

Sebagai catatan tambahan, ketika saya mengatakan "mengekspos" di sini, saya bermaksud memberikan kunci kepada pengguna dengan harapan bahwa mereka menggunakannya secara langsung (seperti menelepon untuk mendukung dengan nomor pesanan mereka).

— Chris Pitman
sumber

5

Jawaban ini tidak masuk akal. Kunci pengganti tidak pernah berubah, dan Anda belum membuat kasus untuk tidak mengeksposnya kepada pengguna.

— Robert Harvey

1

tidak pernah berkata tidak. bagaimana jika desain yang terakhir mengarah pada rekaman konsolidasi? bagaimana jika Anda perlu memperbesar dan mengkonversi dari identitas?

— DougM

3

@ DougM: Lalu tulis catatan ke tabel gabungan baru dengan kunci pengganti sendiri, dan simpan kunci asli di bidang terpisah di tabel baru (dan bidang yang mengidentifikasi tabel sumber asli) sebagai referensi, jika diperlukan. Konsolidasi semacam itu seharusnya sangat langka, dan hanya sebagai hasil dari desain yang gagal. Ulangi setelah saya: Pengganti. Kunci. Tidak pernah. Perubahan. Itu sebabnya mereka pengganti.

— Robert Harvey

2

@ RobertTarvey Saya setuju bahwa kunci pengganti tidak boleh berubah, itulah sebabnya saya pikir mereka membuat pengidentifikasi eksternal yang buruk. Akhirnya, seorang pelanggan ingin mengubah cara mereka merujuk pada catatan. Pada titik itu Anda telah membangun seluruh sistem Anda di sekitar kunci pengganti yang tidak dapat diubah atau Anda berpikir ke depan dan menempatkan tingkat tipuan antara pengidentifikasi bisnis dan kunci pengganti.

— Chris Pitman

2

@sqlvogel: Apakah akan memperjelas jika saya menggunakan istilah "kunci primer yang dihasilkan sistem" alih-alih "pengganti?" Saya setuju bahwa Anda mungkin ingin mengubah algoritme yang menghasilkan kunci pengganti, tetapi itu tidak mengubah kualitas dasarnya yang tidak dapat diubah.

— Robert Harvey

4

Dalam beberapa kasus, kunci pengganti diharapkan dan masuk akal bagi pengguna. Contoh favorit saya adalah "nomor pesanan". Nomor pesanan bukan benar-benar kunci alami: kunci alami mungkin timestamp plus pengguna, atau mungkin lebih dari itu jika Anda mengharapkan pengguna untuk menghasilkan lebih dari satu pesanan dalam rincian dari cap waktu Anda.

Meskipun demikian, pengguna memahami dan mengharapkan kenyamanan nomor pesanan. Tidak ada salahnya, dan banyak nilai, jika Anda memberi tahu pengguna tentang mereka.

Di sisi lain, beberapa tombol pengganti tidak masuk akal bagi pengguna. Tentu, perusahaan asuransi kesehatan saya memiliki beberapa kunci pengganti yang mengidentifikasi saya berdasarkan id anggota saya, tanggal lahir, karier, dll, tetapi saya tidak peduli tentang itu, saya peduli dengan info pada kartu saya (yang sering termasuk id berdasarkan pada majikan saya dan tidak unik di seluruh dunia ... Oleh karena itu kunci pengganti di perusahaan asuransi).

— Alan Shutko
sumber

Jika pengguna memahaminya dan berharap untuk berinteraksi dengannya, maka itu bukan lagi kunci pengganti. Kunci pengganti didefinisikan sebagai tidak memiliki arti bisnis. Hanya karena ini nomor ID tidak selalu berarti itu pengganti. Juga, "beberapa kunci pengganti yang mengidentifikasi saya berdasarkan id anggota saya, tanggal lahir [...]" tidak masuk akal. Anda mengatakan bahwa kunci pengganti mereka (yang tidak memiliki arti bisnis) mengidentifikasi Anda berdasarkan hal-hal yang dapat menyusun kunci alami?

— Kyle McVay

Seringkali, yang terjadi adalah Anda diberi nomor id karyawan sehingga dalam sistem karyawan Anda dibedakan dari orang lain dengan nama yang sama. Pada kartu asuransi Anda, ini dapat mencantumkan id perusahaan dan karyawan Anda. Tetapi perusahaan asuransi kesehatan akan sering menghasilkan id internal sendiri yang dapat digunakan di semua sistemnya daripada menggunakan nama, tanggal lahir, dan id karyawan yang diterima dari majikan Anda. Apakah kunci yang dihasilkan ini pengganti atau kunci alami? Bergantung pada siapa yang Anda tanyakan (periksa 2 definisi alternatif di en.wikipedia.org/wiki/Surrogate_key )

— Alan Shutko

1

Anda seharusnya hanya mengekspos kunci pengganti jika itu adalah GUID / UUID * yang dihasilkan dengan benar. Mengungkap kunci pengganti sekuensial adalah nomor 4 pada OWASP Top 10 masalah keamanan.

* Dalam praktiknya, yang terbaik adalah mengasumsikan bahwa itu tidak dihasilkan dengan benar untuk tujuan ini kecuali Anda tahu bahwa itu dibuat oleh generator nomor acak atau pseudo-acak yang aman secara kriptografis.

— Peter Taylor
sumber

2

Tidak jelas dari jawaban Anda bagaimana GUID meningkatkan keamanan.

— Robert Harvey

1

@ RobertTarvey - Saya berasumsi karena mereka tidak berurutan dan tidak dapat ditebak.

— Bobson

1

security.stackexchange.com/q/38777

— Robert Harvey

@RobertHarvey, diklarifikasi.

— Peter Taylor

1

Jika sebuah tabel tidak memiliki kunci alami, tombol pengganti memungkinkan baris seperti ini.

surrogate_key  some_name
--
1              Wibble
2              Wibble
...
17             Wibble
...
235            Wibble

Saya akan memanggil kunci buatan ini alih-alih kunci pengganti, tetapi perbedaan itu tidak penting untuk pertanyaan ini.

Sekarang, dengan asumsi bahwa ada data penting yang merujuk kunci pengganti ini melalui kunci asing, bagaimana pengguna akhir tahu baris mana yang akan diperbarui jika mereka tidak tahu nilai kunci pengganti?

— Mike Sherrill 'Cat Recall'
sumber

Agak kontradiktif dengan memberi label pada kolom "surrogate_key" tetapi kemudian mengatakan bahwa itu "kunci buatan bukan kunci pengganti". Jika Anda memanggil kunci buatan ini karena tidak memiliki makna bisnis dan hanya berfungsi sebagai pengidentifikasi unik, maka kunci ini harus dinaturalisasi (dibuka), dan kunci pengganti baru harus dibuat. yaitu, mengganti nama surrogate_key yang dinaturalisasi menjadi sesuatu dengan makna bisnis, memaparkannya kepada klien, dan membuat kolom serupa yang baru untuk menjadi pengganti yang sebenarnya untuk operasi internal. Kurang dari ideal, tetapi masih lebih baik daripada mengekspos pengganti yang benar.

— Kyle McVay

@KyleMcVay: Ini tidak kontradiktif. Ini menghormati arti pengganti , ide penting yang "menggantikan". Sebuah kunci pengganti pengganti untuk kunci alami. (Codd dan teori relasional pada umumnya menggunakan kunci pengganti dalam pengertian ini.) Sebuah tabel yang tidak memiliki kunci alami tidak dapat memiliki kunci pengganti dalam pengertian itu. Tapi itu bisa memiliki nilai arbitrer yang digunakan alih - alih yang lainnya. Itulah yang saya sebut kunci buatan.

— Mike Sherrill 'Cat Recall'

Definisi Anda tidak akurat, tetapi saya pikir kunci pengganti telah mengambil makna ekstra, spesifik industri di luar kata pengganti . Jika Anda akan mengekspos kunci ke klien, saya berpendapat bahwa kunci itu sekarang memiliki makna bisnis; telah dinaturalisasi , dan sekarang harus dianggap secara logis bagian dari entitas yang diwakilinya. Dengan logika ini, tidak ada yang namanya kunci pengganti yang terbuka. Jika Anda ingin mengekspos kunci buatan, itu bukan lagi kunci pengganti dan Anda perlu yang baru.

— Kyle McVay

0

Dalam kata-kata awam:

Pengganti harus disembunyikan dari pengguna.
Anda harus memaparkan beberapa kunci kandidat bisnis lain kepada pengguna.
Jika tidak ada kunci kandidat lain, Anda harus menunjukkan PK. Tetapi dalam hal ini PK tidak dianggap sebagai pengganti karena itu bukan pengganti kolom lainnya.

— Tulains Córdova
sumber

Mengapa PK harus ditunjukkan? Saya pikir itu adalah pertanyaan saya - apakah PK yang dihasilkan secara otomatis disebut sebagai kunci pengganti adalah tangensial.

— psr

1

@ psr Judul pertanyaan Anda mengatakan " kunci pengganti pernah diekspos". Aku berkata tidak. Tetapi Anda harus menunjukkan kunci lain. Jika tidak ada kunci lain yang ada maka Anda harus menunjukkan satu-satunya kunci yang Anda miliki. Secara garis besar saya mengklarifikasi bahwa dalam kasus-kasus itu kuncinya sebenarnya bukan pengganti karena itu bukan pengganti kolom lain.

— Tulains Córdova

Pertanyaannya adalah apakah Anda harus menambahkan kolom, atau menunjukkan kunci yang Anda miliki.

— psr

@psr saya ulangi jawaban saya untuk membuatnya lebih jelas.

— Tulains Córdova

1

Saya menemukan bahwa menjadi perbedaan material yang tidak signifikan. Jika aturan Anda adalah bahwa setiap meja memiliki kunci buatan (yang merupakan milik saya), dan bahwa hanya kunci buatan yang ikut serta (yang merupakan prinsip saya juga), maka gagasan bahwa kunci adalah pengganti karena kunci lain mungkin adalah tersedia tidak penting.

— Robert Harvey

0

Anda HANYA harus memaparkan bidang ke pengguna yang memberikan informasi bermanfaat kepada pengguna, baik secara langsung atau dalam melaporkan cacat kepada Anda.

sebaliknya, Anda harus SELALU mengekspos "kunci utama pengganti" ketika mereka merupakan sarana utama untuk mengidentifikasi catatan (sederhana atau kompleks) untuk interaksi yang dilakukan pengguna.

— DougM
sumber

0

Tidak masalah apakah Anda membuka kunci atau tidak kepada pengguna akhir. Aplikasi Anda harus melakukan otorisasi yang diperlukan sehingga hanya mengetahui id pesanan, misalnya, tidak dapat memungkinkan mereka mengakses sesuatu yang biasanya tidak dapat mereka akses.

peringatan: ini mengasumsikan aplikasi berbasis web atau n-tier di mana otorisasi sisi server mungkin / layak. Jika Anda memiliki aplikasi VB yang langsung mengeksekusi sql, itu adalah masalah keseluruhan.

— GrandmasterB
sumber

Bagaimana dengan tidak dapat menyisipkan lalu menghapus catatan, sambil mempertahankan hubungan kunci asing, seperti yang disebutkan dalam pertanyaan?

— psr

Apa hubungannya dengan mengekspos kunci kepada pengguna? Mungkin saya tidak mengerti penggunaan istilah 'mengekspos' Anda. Saya bekerja dari asumsi yang Anda maksudkan 'dapat dilihat oleh pengguna'.

— GrandmasterB