Kolom ulang identitas: kapan diperlukan?

Dalam salah satu pelajaran terakhir di universitas (saya seorang mahasiswa), dosen meminta kami untuk mengembangkan database (MySQL Server jika itu penting) dan aplikasi klien kecil yang akan menggunakan database sebagai sumber data.

Salah satu syarat adalah kolom identitas (yang merupakan PK di setiap tabel) harus berurutan, karena ini adalah praktik yang baik (sesuai kata-kata dosen). Yaitu, ketika baris tabel dihapus, PK harus digunakan kembali pada sisipan berikutnya. Saya memiliki pengetahuan rata-rata di RDBMS, PK, dan kolom identitas. Dari apa yang saya mengerti, kolom identitas itu hanya cara untuk membiarkan DB menghasilkan PK secara otomatis saat memasukkan baris dan tidak lebih. Dan nilai kolom identitas tidak boleh dikaitkan dengan atribut baris dengan cara apa pun (selama itu bukan kunci alami).

Persyaratan ini (kolom identitas berurutan ketat) mencurigakan bagi saya. Saya mencoba untuk bertanya kepada dosen apa yang salah jika identitas tidak berurutan (dengan kesenjangan yang disebabkan oleh penghapusan), tetapi mendapat jawaban yang sangat abstrak seperti "itu mudah bagi pengguna dan berguna untuk administrator DB yang memelihara database". Tidak ada contoh spesifik. Argumen "nyaman bagi pengguna" terdengar konyol, karena tidak memiliki arti dalam domain bisnis.

Karena itu saya ingin tahu apakah alasan ini nyata? Saya hanya bisa memikirkan satu kasus ketika kolom identitas dibuka kembali diperlukan - ketika ruang identitas habis. Tapi ini masalah desain lebih ketika jenis kolom identitas dipilih secara tidak benar, katakan sederhana intbukan bigintatau uniqueidentifierketika tabel berisi miliar baris. Misalkan, kolom identitas adalah indeks berkerumun: dapatkah celah dalam kolom identitas memengaruhi kinerja indeks? Mungkin ada alasan dunia nyata lainnya untuk mengunggah ulang kolom identitas otomatis setelah setiap penghapusan yang tidak saya ketahui?

Terima kasih sebelumnya!

Yaitu, ketika baris tabel dihapus, PK harus digunakan kembali pada sisipan berikutnya.

Dari mana asal dosen Anda ??

Itu sangat tidak efisien. Jika Anda mencoba melakukan itu, Anda akan mengurangi prospek kinerja Anda dengan faktor 10.

Jika Anda membutuhkan angka tanpa celah untuk alasan audit, buat secara eksplisit, bukan langsung dari alat basis data. Dan jangan pernah menghapus baris, tetapi tandai sebagai "dihapus". Ini akan menambah kekacauan permintaan, karena mereka harus mengabaikan baris tersebut.

Di MySQL, InnoDB membutuhkan keberadaan yang unik PRIMARY KEYuntuk setiap tabel. Tapi itu sejauh persyaratan. Kuncinya bahkan bisa menjadi string.

Kesenjangan adalah kenyamanan bagi pengguna dan DBA, bukan ketidaknyamanan.

Saya bisa memikirkan satu kasus di mana gapless akan nyaman - memotong ke dalam kelompok 100 baris sekaligus. Tetapi ada solusi sederhana menggunakan LIMIT 100,1.

Kesenjangan tidak memiliki dampak pada kinerja. Itu termasuk indeks non-numerik. Dan indeks non-unik. Dan indeks komposit.

Tentu, Anda bisa kehabisan id. Saya pikir saya telah melihatnya terjadi dua kali dalam hampir 2 dekade menggunakan MySQL. Saya mungkin juga khawatir dihantam oleh asteroid. Rendah dalam hal hal-hal yang membuat saya tetap terjaga di malam hari.

Kesenjangan terjadi dari (setidaknya): INSERT IGNORE, IODKU, REPLACE, DELETE, ROLLBACK(eksplisit, atau karena kecelakaan), Multi-master replikasi (termasuk Galera dan Grup Replikasi). Apakah Anda benar-benar ingin membuat solusi untuk itu ?!

Jangan ragu untuk meminta kami memeriksa kewarasan apa pun yang menurut dosen mencurigakan.

Menggunakan kembali nilai identitas, secara umum harus berkecil hati. Entah nilai digunakan seluruhnya secara internal, dalam hal ini nilai aktualnya tidak material, atau juga digunakan secara eksternal di mana kasus menggunakan kembali nilai sangat mungkin akan menyebabkan kesalahan identifikasi.

Ambil contoh faktur atau nomor pesanan pembelian yang jelas, ini mungkin dengan mudah berasal dari kolom identitas dan diekspos secara eksternal, tetapi Anda tidak akan pernah ingin menggunakannya kembali karena alasan itu. Keduanya merujuk pada transaksi tertentu yang Anda tidak ingin bingung.

Menyelesaikan masalah seperti itu bisa menjadi masalah besar ketika perusahaan bergabung atau diakuisisi. Menciptakan masalah seperti itu dengan sengaja? Tidak bijak.

Penggunaan kembali nilai-nilai PK id memiliki masalah dan umumnya harus dihindari.

Pertama, implementasi kolom auto_increment tidak memberikan jaminan tidak ada celah. Memang kesenjangan akan terjadi jika Anda mengembalikan sebuah insert pada kolom kenaikan otomatis.

Kedua ID celah dapat merujuk pada data yang ada yang belum dihapus (karena kendala FK yang hilang). Jika mereka menerjemahkan ke nomor anggota yang dikomunikasikan di luar sistem maka itu berpotensi menimbulkan risiko identitas bisnis.

Ketiga, bigint unsignedtidak akan kehabisan ID untuk waktu yang signifikan bahkan diberikan tingkat insert yang sangat besar.

Rasa sakit terbesar dengan kesenjangan datang di auditor yang bersikeras itu kelemahan audit. Untuk DBA mereka tahu ada kesenjangan dan mengapa.

Saya tidak akan menggemakan komentar orang lain bahwa menggunakan kembali PK adalah ide yang buruk, tetapi saya telah menemukan waktu di mana kolom identitas perlu diunggulkan kembali.

Korupsi dari indeks PK itu sendiri.

Memang ini menggunakan MS-SQL dan banyak, bertahun-tahun yang lalu tetapi masih relevan. Bertahun-tahun yang lalu untuk perusahaan tempat saya bekerja, seseorang berpikir itu akan menjadi ide yang baik untuk menggunakan kembali PC sebagai server di 150+ lokasi terpencil kami setelah mereka terlalu tua untuk digunakan oleh klien dan kemudian menaruhnya di lemari tanpa ventilasi. Ketika tidak ada Karena kita semua tahu bahwa setumpuk sampah komputer berusia 10 tahun di sebuah ruangan kecil dengan temps 120+ menjalankan database misi kritis hanya dapat menghasilkan hal-hal yang baik. Seperti tingkat kegagalan 40% dan saya memikirkan kembali pilihan karier saya. Kami akan mereplikasi data kembali ke markas besar perusahaan, tetapi lebih sering daripada tidak, kegagalan ini akan mengakibatkan hal-hal buruk terjadi pada basis data. Salah satunya adalah database yang memiliki indeks rusak yang akan merebut database dan proses replikasi. Dua kali dalam lingkungan yang hebat ini, satu-satunya solusi untuk memperbaiki replikasi adalah dengan memasang kembali indeks dan kemudian membangun kembali replikasi. Kami memang mengganti server kemudian sebelum membuangnya sepenuhnya.