Mengapa penamaan kolom Kunci Utama tabel “Id” dianggap sebagai praktik yang buruk? [Tutup]


210

Guru t-sql saya memberi tahu kami bahwa memberi nama kolom PK kami "Id" dianggap praktik buruk tanpa penjelasan lebih lanjut.

Mengapa penamaan tabel PK kolom "Id" dianggap praktik yang buruk?


27
Yah, itu sebenarnya bukan deskripsi dan Id berarti "identitas" yang sangat jelas. Itu pendapat saya.
Jean-Philippe Leclerc

49
Saya yakin ada banyak toko yang menggunakan Id sebagai nama PK. Saya pribadi menggunakan TableId sebagai konvensi penamaan saya, tetapi saya tidak akan memberi tahu siapa pun tentang THE ONE TRUE WAY. Sepertinya guru Anda hanya mencoba menyajikan pendapatnya sebagai praktik terbaik yang diterima secara luas.

22
Jelas jenis praktik buruk yang tidak terlalu buruk. Intinya adalah untuk konsisten. Jika Anda menggunakan id, gunakan di mana-mana atau jangan gunakan.
deadalnix

57
Anda punya meja ... itu disebut People, punya kolom, disebut Id, menurut Anda Id itu? Mobil? Sebuah perahu? ... tidak, itu People Id, itu saja. Saya tidak berpikir itu bukan praktik yang buruk dan tidak perlu memberi nama kolom PK apa pun selain Id.
jim

38
Jadi, guru mendapat di depan kelas dan memberitahu Anda ini adalah praktik yang buruk tanpa satu alasan? Itu praktik yang lebih buruk bagi seorang guru.
JeffO

Jawaban:


247

Aku akan keluar dan mengatakan itu: Ini tidak benar-benar praktek yang buruk (dan bahkan jika itu, yang tidak yang buruk).

Anda bisa membuat argumen (seperti yang ditunjukkan Chad ) yang bisa menutupi kesalahan seperti dalam kueri berikut:

SELECT * 
    FROM cars car
    JOIN manufacturer mfg
        ON mfg.Id = car.ManufacturerId
    JOIN models mod
        ON mod.Id = car.ModelId
    JOIN colors col
        ON mfg.Id = car.ColorId

tetapi ini dapat dengan mudah dikurangi dengan tidak menggunakan alias kecil untuk nama tabel Anda:

SELECT * 
    FROM cars
    JOIN manufacturer
        ON manufacturer.Id = cars.ManufacturerId
    JOIN models
        ON models.Id = cars.ModelId
    JOIN colors
        ON manufacturer.Id = cars.ColorId

Praktek SELALU menggunakan singkatan 3 huruf tampaknya jauh lebih buruk bagi saya daripada menggunakan nama kolom id. (Contoh kasus: siapa yang sebenarnya akan menyingkat nama tabel carsdengan singkatan car? Apa manfaatnya?)

Intinya adalah: konsisten. Jika perusahaan Anda menggunakan Id dan Anda biasanya membuat kesalahan di atas, maka biasakan menggunakan nama tabel penuh. Jika perusahaan Anda mencekal kolom Id, tenang dan gunakan konvensi penamaan apa pun yang mereka sukai.

Berfokuslah pada mempelajari hal-hal yang benar-benar praktik buruk (seperti beberapa kueri yang berkorelasi bersarang) daripada memikirkan masalah seperti ini. Masalah penamaan kolom Anda "ID" lebih dekat menjadi masalah selera daripada menjadi praktik yang buruk.


A CATATAN UNTUK EDITOR: Kesalahan dalam kueri ini disengaja dan sedang digunakan untuk membuat poin. Harap baca jawaban lengkap sebelum mengedit.


1
@ Chad, itu adalah referensi ke fakta bahwa dalam permintaan tertentu Anda menggunakan 3 huruf untuk alias untuk nama tabel, bahkan ketika itu tidak masuk akal ( cars-> car. Terima kasih Tuhan - Anda telah menyelamatkan jari saya). Jangan membacanya terlalu dalam.
riwalk

3
lebih buruk dari nama alias saya, adalah campuran saya dari pluralitas carsdan manufacturer. Satu jamak, yang lain tidak. Jika orang ingin memilih di db, itu adalah praktik buruk yang harus diambil.
CaffGeek

3
Saya pikir ini adalah praktik yang buruk. Jelas, sejauh praktik buruk itu tidak buruk .. tapi sangat mudah untuk dihindari, mengapa tidak melakukannya? Sekarang, saya setuju, untuk kelas intro, apakah ini yang menjadi fokus? Mungkin tidak ....
user606723

2
@ user606723, sebenarnya, saya pikir untuk kelas intro itu adalah hal yang penting untuk dijadikan pokok bahasan. Mengajar praktik terbaik haruslah mendasar. Tidak sampai Anda mengalami bahwa Anda memahami konsekuensi, dan pengorbanan dan ketika Anda harus menyimpang dari praktik terbaik.
CaffGeek

5
@ Chad, Setuju untuk tidak setuju. Mencoba mengajari siswa "praktik terbaik" tanpa membiarkan mereka memahami mengapa itu adalah praktik terbaik adalah upaya yang sia-sia. Dan karena Anda tidak dapat menutupi semuanya, menutupi titik ini dengan "Anda seharusnya tidak melakukannya, Anda akan mencari tahu mengapa nanti" adalah pilihan yang cukup waras dari sudut pandang seorang profesor. Siswa yang ingin tahu dapat memposting di sini atau mudah-mudahan menemukan pertanyaan ini sudah dijawab. (Atau tanyakan setelah kelas)
user606723

123

Karena ketika Anda memiliki tabel dengan kunci asing, Anda tidak dapat menamai kunci asing itu "Id". Anda memiliki nama tabel itu TableId

Dan kemudian bergabung Anda terlihat seperti

SELECT * FROM cars c JOIN manufacturer m ON m.Id = c.ManufacturerId

Dan idealnya, kondisi Anda harus memiliki nama bidang yang sama di setiap sisi

SELECT * FROM cars c JOIN manufacturer m ON m.ManufacturerId = c.ManufacturerId

Jadi, meskipun tampak berlebihan untuk menyebut Id sebagai ManufacturerId, itu membuat Anda tidak memiliki banyak kesalahan dalam kondisi bergabung Anda karena kesalahan menjadi jelas.

Ini tampaknya sederhana, tetapi ketika Anda bergabung dengan beberapa tabel, semakin besar kemungkinan Anda akan membuat kesalahan, temukan yang di bawah ini ...

SELECT * 
    FROM cars car 
    JOIN manufacturer mfg
        ON mfg.Id = car.ManufacturerId
    JOIN models mod
        ON mod.Id = car.ModelId
    JOIN colors col
        ON mfg.Id = car.ColorId

Sedangkan dengan penamaan yang tepat, kesalahan muncul ...

SELECT * 
    FROM cars car 
    JOIN manufacturer mfg
        ON mfg.ManufacturerId = car.ManufacturerId
    JOIN models mod
        ON mod.ModelId = car.ModelId
    JOIN colors col
        ON mfg.ManufacturerId = car.ColorId

Alasan lain menamai mereka Id adalah "buruk" adalah bahwa ketika Anda meminta informasi dari beberapa tabel Anda perlu mengubah nama kolom Id sehingga Anda dapat membedakannya.

SELECT   manufacturer.Id as 'ManufacturerId'
        ,cars.Id as 'CarId'
        --etc
    FROM cars 
    JOIN manufacturer
        ON manufacturer.Id = cars.Id

Dengan nama yang akurat ini tidak terlalu menjadi masalah


174
Tidak yakin ini penjelasan yang cukup bagus untuk saya. Tidak ada yang salah dengan mengatakan SELECT * FROM cars c JOIN manufacturer m ON manufacturer.Id = c.ManufacturerId. Saya telah menggunakan idselama bertahun-tahun dan tidak pernah menemukan apa yang Anda gambarkan sebagai masalah nyata.
riwalk

61
Saya akan mengatakan bahwa praktik buruk di sini adalah dengan tabel alias dengan nama seperti mfg atau mod. manufacturers.id = cars.manufacturer_id sangat mudah dibaca dan kesalahan juga akan muncul.
deadalnix

5
@Chad> Saya sudah mendapat masalah dengan nama variabel yang bodoh. Berkali-kali. Untuk reccord, di sini apa yang akan saya katakan kepada seorang pengembang yang melakukan ini di tim saya «mfg tidak berarti produsen, itu berarti Anda harus malas mengetik produsen».
deadalnix

9
@ Stargazer712: Melakukan SELECT * dari 2 tabel memberikan 2 x kolom ID. ID sekarang ambigu: apakah Anda mereferensikan dengan ordinal atau nama? SELECT * juga bukan praktik yang baik. Argumen yang buruk. Kode rapuh. Chad benar: pada dasarnya pengkodean defensif
gbn

6
@ GBN, sekali lagi, semua ambiguitas hilang jika Anda melakukannya SELECT manufacturer.id FROM .... Setiap kesulitan yang dihasilkan iddapat diatasi dengan sangat mudah, menjadikannya hanya masalah selera.
riwalk

67

Pustaka ActiveRecord Ruby dan GORM Groovy menggunakan "id" untuk kunci pengganti secara default. Saya suka latihan ini. Duplikasi nama tabel di setiap nama kolom adalah mubazir, membosankan untuk ditulis, dan lebih membosankan untuk dibaca.


30
+1 untuk "dan lebih membosankan untuk dibaca." - konvensi penamaan seharusnya tidak dianggap sebagai band-aid untuk kode ceroboh, mereka harus meningkatkan keterbacaan sebagai perhatian utama.
ocodo

12
ID jauh lebih membosankan untuk dibaca
HLGEM

5
@HLGEM: Seseorang dapat selalu memenuhi syarat nama kolom dengan nama tabel.
kevin cline

2
Saya akan setuju kecuali yang lebih membosankan untuk dibaca. Saya sebenarnya lebih suka membaca nama kolom yang lebih deskriptif dan menghabiskan lebih sedikit waktu untuk mencari tahu apa sebenarnya kolom itu.
Devin Dixon

2
+1, Benci melihat tabel dengan kolom seperti Posts.postID, Posts.postName di mana cukup menggunakan post.id dan post.name jauh lebih cantik.
Doug

40

Nama kolom umum atau kunci seperti "Nama" atau "Id" harus diawali dengan TableName.

Ini menghilangkan ambiguitas, lebih mudah untuk mencari, berarti alias kolom jauh lebih sedikit ketika kedua nilai "Id" diperlukan.

Kolom atau non-kunci yang digunakan atau audit yang lebih rendah (katakanlah LastUpdatedDateTime) tidak masalah


57
Jika Anda melakukan ini, saya benci Anda karena membuat saya mengetik ekstra !!!! Nama tabelnya adalah Person, menurut Anda ID apa yang akan terjadi? Mobil? tidak, itu Person.
jim

16
@ Jim, saya tidak tahu tentang Anda, tetapi mengetik 6 karakter tambahan membutuhkan sekitar setengah detik. Dan mengingat saya jarang pernah memilih dari satu tabel, dan dengan demikian akan berakhir dengan dua kolom bernama 'Id' dan perlu menyertakan tabel / alias nama bagaimanapun, tidak ada penghematan dalam jumlah karakter yang diketik.
CaffGeek

21
@Chad, saya merasa berlebihan. jika saya melakukan join, c.id = m.manufacturerid, boleh saja dengan saya. Kolom-kolom ini biasanya "dipetakan" ke suatu kelas entah bagaimana, dan memiliki kelas dengan Person.PersonId membuat saya ingin muntah ... Ya, saya sepenuhnya sadar saya memiliki masalah.
jim

20
Saya juga tidak setuju dengan ini. Kenapa berhenti di namedan id? Mengapa tidak setiap kolom diawali dengan nama tabelnya? Tampaknya sewenang-wenang untuk memilih kedua nama untuk mengamanatkan awalan. Secara konseptual, Anda harus memiliki tabel untuk tetap memiliki konteks kolom. Mengapa tidak menggunakan nama tabel itu untuk mengklarifikasi kueri: Person.Name, Animal.Name, Part.Name, ...
Thomas

11
@ Bill Leeper, KERING tidak selalu sesuai dalam pengembangan basis data. Dalam database yang penting adalah kinerja dan membuat database melakukan pekerjaan ekstra untuk memenuhi prinsip KERING (seperti menggunakan fungsi skalar atau tampilan yang memanggil tampilan atau kueri yang mengembalikan terlalu banyak kolom atau menggunakan kursor untuk menambahkan 10.000 catatan untuk menggunakan proc yang ada) sering dikontraindikasikan. Jangan berpikir bahwa hanya karena ada sesuatu yang baik di dunia berorientasi objek yang sesuai dalam desain basis data. Downvote Anda tidak pantas. Menggunakan ID adalah antipattern SQL yang dikenal.
HLGEM

31

Utas ini sudah mati, tetapi saya ingin menambahkan bahwa IMO yang tidak digunakan Idadalah praktik yang buruk. The Idkolom khusus; itu adalah yang primary key. Setiap tabel dapat memiliki sejumlah kunci asing, tetapi hanya dapat memiliki satu kunci yang utama. Dalam database tempat semua kunci utama dipanggil Id, segera setelah Anda melihat tabel Anda tahu persis kolom mana yang merupakan kunci utama.

Percayalah, selama berbulan-bulan sekarang saya telah menghabiskan sepanjang hari setiap hari bekerja di banyak database besar (Tenaga Penjualan) dan hal terbaik yang dapat saya katakan tentang skema adalah bahwa setiap tabel memiliki kunci primer yang disebut Id. Saya dapat meyakinkan Anda bahwa saya sama sekali tidak pernah bingung tentang bergabung dengan kunci utama ke kunci asing karena PK disebut Id. Hal lain yang belum disebutkan orang adalah bahwa tabel dapat memiliki nama-nama konyol yang panjang seperti Table_ThatDoesGood_stuff__c; nama itu cukup buruk karena arsitek mengalami mabuk pada pagi hari dia memikirkan tabel itu, tetapi sekarang Anda mengatakan kepada saya bahwa itu adalah praktik yang buruk untuk tidak memanggil kunci utama Table_ThatDoesGood_stuff__cId (mengingat bahwa nama kolom SQL pada umumnya tidak peka huruf besar-kecil).

Sejujurnya, masalah dengan kebanyakan orang yang mengajar pemrograman komputer adalah bahwa mereka belum pernah menulis sederet kode produksi selama bertahun-tahun, jika pernah, dan mereka tidak tahu apa yang sebenarnya dilakukan oleh insinyur perangkat lunak yang berfungsi. Tunggu sampai Anda mulai bekerja dan kemudian putuskan sendiri apa yang menurut Anda merupakan ide bagus atau tidak.


2
Itu hanya terjadi jika tidak ada kunci utama Anda adalah kunci komposit, yang, sayangnya, terlalu sering terjadi. Seseorang harus benar-benar hanya menggunakan kunci pengganti dalam keadaan tertentu.
nicodemus13

6
Menggunakan Id seperti itu Anda berakhir dengan situasi di mana tanpa berpikir pengembang menambahkan id kunci utama untuk setiap tabel yang mereka buat. Salah satu dasar dari basis data relasional adalah penggunaan kunci primer yang bermakna dan agregat dan penggunaan id tidak membantu.
Pieter B

Jawaban ini sepertinya Anda mengatakan "Saya lebih suka Id" dengan argumen pendapat. Argumen Anda adalah Anda dapat langsung melihat kunci mana yang merupakan kunci utama dengan menemukan yang disebut Id. Yah, itu persis sama dengan tableID . Saya dapat menjamin Anda bahwa saya tidak pernah bingung kunci mana yang merupakan kunci utama. Saya hanya mencari yang memiliki nama tabel sebelum id. Tidak hanya itu, tetapi tabel kafir seperti apa yang Anda gunakan di mana kolom pertama bukan kunci utama? Saya merasa seperti semua argumen Anda dalam jawaban ini murni berdasarkan preferensi dan mirip dengan "tableId merasa salah bagi saya".
dallin

@allah semua jawaban sudah dikemukakan, jika tidak, seseorang hanya akan menautkan ke standar resmi, dan tidak ada satu!
James

@ James, saya merasa tujuan dari situs StackExchange adalah untuk mengurangi jawaban yang diajukan. Itu sebabnya pertanyaan ditutup karena terlalu banyak pendapat. Memang, saya pikir itulah sebabnya mengapa pertanyaan ini ditutup - karena memunculkan jawaban yang dikemukakan, tetapi saya merasa jawaban spesifik ini terlalu dikemukakan pendapat tanpa fakta atau argumen pendukung nyata berdasarkan fakta. Seluruh jawaban dapat diringkas dengan mengatakan, "Dalam Pendapat saya, Anda harus menggunakan ID, hanya karena itulah yang saya sukai ". Itu bukan jawaban yang berharga.
dallin

24

Saya tidak menganggapnya sebagai praktik buruk. Konsistensi adalah raja, seperti biasa.

Saya pikir ini semua tentang konteks. Dalam konteks tabel sendiri, "id" hanya berarti persis apa yang Anda harapkan, label untuk membantu mengidentifikasi secara unik terhadap orang lain yang mungkin (atau tampak) identik.

Dalam konteks gabungan, Anda bertanggung jawab untuk membuat gabungan sedemikian rupa agar dapat dibaca oleh Anda dan tim Anda. Seperti halnya membuat hal-hal tampak sulit dengan ungkapan atau penamaan yang buruk, juga memungkinkan untuk membuat kueri yang bermakna dengan penggunaan alias yang efektif dan bahkan komentar.

Dengan cara yang sama kelas Java yang disebut 'Foo' tidak memiliki propertinya diawali oleh 'Foo', jangan merasa berkewajiban untuk awalan ID tabel Anda dengan nama tabel. Biasanya jelas dalam konteks apa ID yang dimaksud.


5
Tabel database relasional bukan kelas .
Adam Robinson

1
Namun mereka adalah struktur data dan mereka analog dengan kelas PODO. Masalah penamaan yang sama berlaku.
ocodo

4
@ Slomojo: Tidak, mereka tidak analog dengan objek sederhana. Desain berorientasi objek dan desain database tidak sama, dan bahkan tidak terkait. Meskipun mereka dapat, dalam beberapa kasus, menghasilkan desain yang serupa (atau bahkan sama), itu tidak menunjukkan bahwa mereka terkait. Sebagai contoh, hubungan m: m adalah sepele di kelas, tetapi tidak mungkin memiliki antara dua tabel tanpa tabel asosiasi ketiga.
Adam Robinson

1
Cukup bagaimana ini berhubungan dengan strategi penamaan, saya tidak tahu. Analogi saya (jelas?) Hanya mencakup sampai sejauh itu.
ocodo

2
Maaf arti tersirat saya tidak begitu jelas, saya seharusnya mengatakan " dalam hal ini mereka analog dengan kelas". Either way, saya tidak berpikir terlalu berlebihan tentang hal ini sangat konstruktif. Dalam hal penamaan, tabel dan kelas memang memiliki banyak kesamaan. Praktik terbaik yang berkembang dalam cul-de-sac adalah permainan yang adil untuk revisi, atau paling tidak terbuka untuk diskusi. Ada banyak di dalam T&J ini yang menggambarkan ini secara efektif, saya tidak punya catatan lain untuk ditambahkan.
ocodo

24

Dari data.stackexchange.com

Id di Posting

BOOM, pertanyaan dijawab.
Sekarang, beri tahu guru Anda bahwa SO mempraktikkan desain basis data yang buruk.


8
Tebakan saya di FK, berdasarkan nama PostTypeId -> PostTypes.Id:; AcceptedAnswerId -> Answers.Id; OwnerUserId -> Users.Id. Mengapa praktik yang semudah itu dianggap 'buruk'?
Sjoerd

3
Bagaimana tepatnya hal ini membuktikan sesuatu tentang praktik terbaik?
GBa

5
Apakah sesuatu digunakan di stack atau tidak tidak membuktikan apakah itu praktik yang baik atau buruk.
Pieter B

2
Apa yang dibuktikannya adalah bahwa praktik ini sama sekali tidak melarang skalabilitas dan kegunaan aplikasi.
Cypher

1
Sebenarnya latihan SO tidak sempurna. Saya akan menggunakan penamaan ini: PostType -> PostType.Id; AcceptedAnswer -> Answer.Id; OwnerUser -> User.Id
alpav

17

Itu membuatnya sulit (dan membingungkan) untuk melakukan join alami di atas meja, oleh karena itu ya, itu buruk jika tidak terlalu buruk.

Natural Join adalah artefak kuno SQL Lore (yaitu aljabar relasional) yang mungkin pernah Anda lihat: ⋈ dalam buku database mungkin. Apa yang saya maksud adalah Natrual Join bukanlah ide SQL baru yang ketinggalan jaman, meskipun sepertinya butuh waktu lama bagi DBMS untuk mengimplementasikannya, oleh karena itu bukan ide ketinggalan jaman baru bagi Anda untuk mengimplementasikannya, bahkan mungkin tidak masuk akal bagi Anda untuk mengabaikannya keberadaannya saat ini.

Nah, jika Anda memberi nama semua ID kunci utama Anda, maka Anda kehilangan kemudahan dan kesederhanaan dari gabungan alami. select * from dudes natural join carsperlu ditulis select * from dudes inner join cars where cars.dudeid = dudes.idatau select * from dudes inner join cars where dudes.carid = cars.id. Jika Anda dapat melakukan join natural, Anda bisa mengabaikan apa sebenarnya relasinya, yang, saya percaya, cukup mengagumkan.


Kecuali jika Anda menulis prosedur tersimpan kapan terakhir kali sebagai pengembang aplikasi Anda benar-benar menulis pemilih SQL yang diformat sepenuhnya? Bahasa modern semua termasuk semacam fitur ORM yang mengelola hubungan ini untuk Anda. Nama kolom jauh lebih penting daripada mampu menulis SQL manual yang bersih.
Bill Leeper

4
@Bill I do all time, berkali-kali sehari, lebih tergantung pada basis kode Anda daripada bahasa yang Anda kembangkan. Dan, untuk diagnosa, jika Anda ingin melakukan hubungan yang baik dan mendalam, Anda dapat merangkai gabungan alami tersebut dan sepenuhnya menghindari mencari ID bidang. Dan, seperti kata St Jerome terkenal, "Ketidaktahuan SQL adalah ketidaktahuan database".
Peter Turner

Selain dari fakta bahwa bergabung secara alami tidak didukung secara universal, IMO, bergabung secara alami lebih sulit untuk dibaca. Apakah ada dua kolom dalam hubungan atau hanya satu? Jauh lebih baik untuk menjadi eksplisit dan menghindari penggabungan alami.
Thomas

1
@ Thomas, saya juga tidak akan memasukkan kode natural, tetapi untuk diagnostik, saya menemukan mereka cukup berguna ketika database dimodelkan sehingga mereka benar-benar berfungsi.
Peter Turner

16

Ada situasi di mana menempelkan "ID" di setiap tabel bukan ide terbaik: USINGkata kunci, jika didukung. Kami sering menggunakannya di MySQL.

Misalnya, jika Anda memiliki fooTabledengan kolom fooTableIddan barTabledengan kunci asing fooTableId, maka pertanyaan Anda dapat dibuat seperti itu:

SELECT fooTableId, fooField1, barField2 FROM fooTable INNER JOIN barTable USING (fooTableId)

Ini tidak hanya menghemat pengetikan, tetapi jauh lebih mudah dibaca dibandingkan dengan alternatif:

SELECT fooTable.Id, fooField1, barField2 FROM fooTable INNER JOIN barTable ON (fooTable.Id = barTable.foTableId)

Ini adalah jawaban yang paling menonjol bagi saya. Kata USINGkunci ini didukung oleh database postgres / mysql / sqlite, berarti lebih sedikit mengetik di mana beberapa dari daftar jawaban lainnya sebagai alasan untuk menggunakan id, dan akhirnya menurut pendapat subjektif saya lebih mudah dibaca.
Michael Barton

11

Mengapa tidak bertanya kepada gurumu saja?

Pikirkan tentang ini, ketika semua kolom tabel PK Anda dinamai IDitu menjadikannya sebagai kunci asing mimpi buruk.

Nama kolom harus signifikan secara semantik. IDadalah untuk generik.


8
terlalu generik untuk apa? id tabel?
jim

3
@ Jim meja yang mana? idsendiri tidak berarti apa-apa, terutama dalam konteks kunci asing ke tabel lain. Ini tidak ada hubungannya dengan classesdan semuanya berhubungan dengan desain basis data relasional dasar yang bagus.

10
Untuk menjadi sedikit bodoh, meja yang dimilikinya. table.idadalah cara yang bisa diterima untuk merujuk ke suatu idbidang. Awalan nama bidang dengan nama tabel berlebihan.
ocodo

2
@ Slomoj itu tidak lebih dari mengetik termasuk nama dalam kolom dan lebih menjelaskan ketika aliasing nama tabel untuk singkatan huruf tunggal atau ganda dalam monster bergabung.

6
Mimpi buruk apa yang Anda maksud? Misalkan Anda memiliki struktur referensi-sendiri karyawan dengan kolom yang mewakili manajer mereka. Apa yang Anda sebut kunci asing? Anda tidak dapat menyebutnya EmployeeId karena itu mungkin PK Anda. Nama FK tidak harus cocok dengan PK. Itu harus diberi nama untuk apa yang diwakilinya kepada entitas di mana ia terkandung.
Thomas

7

ID buruk karena alasan berikut:

Jika Anda melakukan banyak permintaan pelaporan, Anda harus selalu alias kolom jika Anda ingin melihat keduanya. Jadi itu menjadi buang-buang waktu ketika Anda bisa menyebutkannya dengan benar. Pertanyaan kompleks ini cukup sulit (saya menulis pertanyaan yang panjangnya ratusan baris) tanpa beban tambahan untuk melakukan pekerjaan yang tidak perlu.

Itu dapat menyebabkan kesalahan kode. Jika Anda menggunakan database yang memungkinkan penggunaan natural join (bukan berarti saya pikir Anda harus menggunakannya, tetapi ketika fitur tersedia, seseorang akan menggunakannya), Anda akan bergabung pada hal yang salah jika Anda mendapatkan pengembang yang menggunakannya.

Jika Anda menyalin gabungan untuk membuat kueri yang kompleks, mudah untuk lupa mengubah alias ke yang Anda inginkan dan mendapatkan salah bergabung. Jika setiap id diberi nama setelah tabel itu berada, maka Anda biasanya akan mendapatkan kesalahan sintaksis. Juga lebih mudah dikenali jika gabungan dalam kueri kompleks salah jika nama pPK dan nama FK cocok.


+1: Ini adalah alasan kuat menurut saya, sedangkan jawaban lain yang menentang IDtidak meyakinkan saya sama sekali.
phoog

Re: "Jika Anda menyalin bergabung untuk membuat permintaan yang kompleks" - jadi masalah Anda adalah salin & tempel. Hentikan salin & tempel dan Anda akan melihat betapa mudahnya penamaan car.id. Untuk bergabung dengan FK gunakan car.mfg = mfg.id, car.color = color.id, car.model = model.id - sangat sederhana dan cocok dengan apa yang akan Anda tulis di LINQ.
alpav

Cobalah menulis sesuatu dengan 30 bergabung dan Anda akan melihat mengapa itu adalah antipattern.
HLGEM

Mengasingkan diri adalah alasan pertama dan terpenting - sangat merepotkan saat melakukan laporan rumit yang besar. Gabungan alami hanyalah bonus manis. Sungguh menakjubkan bagaimana jawaban lain mengabaikan poin ini. Saya pikir menambahkan beberapa contoh akan membuat poin lebih jelas dan melompat jawaban ini lebih tinggi ke tempat seharusnya.
Lulu

5

Ada beberapa jawaban yang mendekati apa yang saya anggap sebagai alasan paling penting untuk tidak menggunakan "id" sebagai nama kolom untuk kunci utama dalam tabel: yaitu konsistensi dan mengurangi ambiguitas.

Namun, bagi saya manfaat utama disadari oleh programmer pemeliharaan, khususnya yang tidak terlibat dengan pengembangan asli. Jika Anda menggunakan nama "PersonID" untuk ID di tabel Person dan secara konsisten menggunakan nama itu sebagai kunci asing, itu sepele untuk menulis kueri terhadap skema untuk mengetahui tabel apa yang memiliki PersonID tanpa harus menyimpulkan bahwa "PersonID" adalah nama yang digunakan saat itu adalah kunci asing. Ingat, benar atau salah, hubungan kunci asing tidak selalu diberlakukan di semua proyek.

Ada kasus tepi di mana satu tabel mungkin perlu memiliki dua kunci asing ke tabel yang sama, tetapi dalam kasus seperti itu saya akan meletakkan nama kunci asli sebagai nama akhiran untuk kolom, sehingga pencocokan wildcard,% PersonID, dapat dengan mudah menemukan contoh-contoh itu juga.

Ya, banyak dari ini dapat dicapai dengan standar memiliki "id" dan mengetahui untuk selalu menggunakannya sebagai "tableNameID", tetapi itu membutuhkan keduanya mengetahui bahwa praktiknya sudah ada dan tergantung pada pengembang asli untuk menindaklanjuti dengan yang kurang praktik standar intuitif.

Sementara beberapa orang telah menunjukkan bahwa memang diperlukan beberapa stroke kunci tambahan untuk menuliskan nama kolom yang lebih panjang, saya berpendapat bahwa menulis kode hanya sebagian kecil dari kehidupan aktif program. Jika menyimpan penekanan tombol pengembang adalah tujuannya, komentar tidak boleh ditulis.

Sebagai seseorang yang telah menghabiskan bertahun-tahun mempertahankan proyek besar dengan ratusan tabel, saya akan lebih suka nama yang konsisten untuk kunci di seluruh tabel.


Misalkan sebuah Companiestabel memiliki 2 kunci asing ke sebuah Personstabel. Satu mewakili Presiden perusahaan; yang lain mewakili Bendahara perusahaan. Apakah Anda benar-benar memanggil kolom PersonID1dan PersonID2? Akan jauh lebih deskriptif untuk memanggil mereka PresidentIDdan TreasurerID. Saya merasa lebih mudah membaca inner join Person AS Presidents ON Company.PresidentID = Presidents.IDdaripadainner join Person AS Person1 ON Company.PersonID1 = Person1.PersonID
phoog

1
Tidak. Dalam contoh Anda, saya mungkin akan memiliki tabel CompanyOfficeratau CompanyPersonyang memungkinkan hubungan banyak-ke-banyak dengan antara Companydan Persondengan informasi tambahan tentang sifat hubungan. Jika saya mengimplementasikannya dalam Companytabel, saya akan menggunakan nama kolom PresidentPersonIDdan TreasurerPersonIDuntuk mempertahankan bagian * PersonID dari nama sambil menambahkan deskriptor tambahan. inner join Person as Presidents on Company.PresidentPersonID = Presidents.PersonID
Maleakhi

5

Praktek menggunakan Id sebagai bidang kunci utama mengarah ke praktik di mana id ditambahkan ke setiap tabel. Banyak tabel sudah memiliki informasi unik yang secara unik mengidentifikasi catatan. Gunakan ITU sebagai kunci utama dan bukan bidang id yang Anda tambahkan ke setiap dan setiap tabel. Itu salah satu dasar dari basis data relasional.

Dan itulah mengapa menggunakan id adalah praktik yang buruk: id seringkali bukan hanya informasi peningkatan otomatis.

pertimbangkan tabel berikut:

PK id | Countryid   | Countryname
    1 |         840 | United States
    2 |         528 | the Netherlands

Apa yang salah dengan tabel ini adalah bahwa hal itu memungkinkan pengguna untuk menambahkan baris lain: Amerika Serikat, dengan kode negara 840. Itu baru saja merusak integritas relasional. Ofcourse Anda dapat menerapkan keunikan pada masing-masing kolom, atau Anda bisa menggunakan kunci utama yang sudah tersedia:

PK Countryid   | Countryname
           840 | United States
           528 | the Netherlands

Dengan begitu Anda menggunakan informasi yang sudah Anda miliki sebagai kunci utama, yang merupakan jantung dari desain basis data relasional.


1
Anda akan mengerti mengapa orang menambahkan kolom kunci umum ke setiap tabel ketika Anda harus melakukan migrasi database antara sistem yang berbeda, atau telah senang menggabungkan database bersama.
Cypher

1
Ini kadang-kadang terjadi, tetapi dalam pengalaman saya itu sangat tidak biasa untuk memiliki kunci abadi unik yang bagus. Tetapi bahkan dalam contoh Anda, Anda memiliki nomor unik yang tidak berarti untuk mengidentifikasi negara, hanya satu yang dialokasikan oleh ISO bukan oleh basis data Anda.
CodesInChaos

Dan sekarang ketika nama negara berubah, Anda harus memperbaruinya di seluruh basis data Anda untuk memperbaikinya. Jika Anda hanya menggunakan kunci pengganti (seperti ... "id"), pembaruan akan sepele. Kunci alami bagus - ketika mereka benar-benar abadi, dan tidak pernah berubah. Sebenarnya ada sangat sedikit kasus di mana ini benar.
Gerrat

@ Gerrat: Jika nama negara berubah, kode angka ISO 3166-1 tetap sama, hanya kode ISO 3166-1 alpha-2 dan alpha-3 yang berubah. Ini terjadi dengan Burma / Myanmar, misalnya. Demikian juga, jika suatu negara mengubah wilayahnya tetapi tetap mempertahankan namanya, kode numerik ISO 3166-1 berubah, tetapi kode ISO 3166-1 alpha-2 dan alpha-3 tetap ada. Ini terjadi ketika Sudan Selatan berpisah dari Sudan dan Eritrea berpisah dari Ethiopia. Ketika Jerman Timur dan Barat bersatu kembali, mereka menyimpan kode alpha-2 dan alpha-3 dari Jerman Barat tetapi mendapat kode numerik baru. Ketika negara benar-benar bubar atau berubah (pikirkanlah ...
Jörg W Mittag

... hasil dari perang Balkan tahun 90-an), mereka mendapatkan kode numerik dan alpha-2 dan alpha-3 yang baru.
Jörg W Mittag

4

Saya selalu menggunakan 'id' sebagai nama kolom utama untuk setiap tabel hanya karena itu adalah konvensi kerangka kerja yang saya gunakan (Ruby on Rails, CakePHP), jadi saya tidak harus menimpanya setiap saat.

Itu tidak akan mengalahkan alasan akademis bagi saya.


2

Saya tidak berpikir itu praktik yang buruk jika digunakan dengan benar. Biasanya memiliki bidang ID penambahan-otomatis yang disebut "ID" yang tidak perlu Anda sentuh, dan gunakan pengenal yang lebih ramah untuk aplikasi tersebut. Mungkin sedikit merepotkan untuk menulis kode from tableA a inner join tableB b on a.id = b.a_idtetapi kode itu dapat disimpan.

Sebagai preferensi pribadi saya cenderung awalan Id dengan nama entitas, tapi saya tidak melihat masalah nyata dengan hanya menggunakan Idjika itu ditangani sepenuhnya oleh database.


Anda tidak akan pernah bergabung dengan dua tabel dengan kunci utama masing-masing terutama id kenaikan otomatis. Sampel di atas akan dari tableA a join tableBB bagian dalam a.id = b.table_a_id.
Bill Leeper

Ya, itulah yang saya maksud. Hampir makan siang dan butuh energi.
Wayne Molina

2

ID cukup umum, yang menurut saya tidak akan membingungkan siapa pun. Anda akan selalu ingin tahu meja. Menempatkan nama bidang dalam kode produksi tanpa menyertakan tabel / alias adalah praktik yang buruk. Jika Anda terlalu khawatir untuk bisa mengetik pertanyaan ad hoc dengan cepat, Anda harus melakukannya sendiri.

Hanya berharap tidak ada yang mengembangkan database sql di mana ID adalah kata yang dilindungi undang-undang.

CREATE TABLE CAR (ID);

Mengurus kenaikan bidang nama, kunci utama, dan otomatis dengan 1 dimulai dengan 1 semua dalam satu paket 2 karakter kecil yang bagus. Oh, dan saya akan menyebutnya CARS tetapi jika kita akan menghemat stroke-key dan siapa yang benar-benar berpikir meja yang disebut CAR hanya akan memiliki satu?


1
ini menunjukkan mengapa pengetahuan tentang teori hubungan formal itu penting, nama tabel mewakili apa satu baris itu. Tabel Carmewakili Tabletempat masing-masing Rowmewakili satu Car. Memanggil Carsperubahan semantik dan menunjukkan kurangnya pemahaman tentang prinsip dasar teori hubungan formal. Rails adalah contoh utama seseorang yang tahu cukup berbahaya .

2

Pertanyaan ini telah berulang kali dikalahkan, tetapi saya pikir saya juga akan menambahkan pendapat saya.

  1. Saya menggunakan id yang berarti bahwa itu adalah pengidentifikasi untuk setiap tabel, jadi ketika saya bergabung ke sebuah tabel dan saya membutuhkan kunci primer saya secara otomatis bergabung ke kunci utama.

  2. Bidang id adalah peningkatan otomatis, tidak ditandatangani (artinya saya tidak harus menetapkan nilainya dan tidak boleh negatif)

  3. Untuk kunci asing, saya menggunakan tablenameid (sekali lagi masalah gaya), tetapi kunci utama yang saya ikuti adalah bidang id dari tabel, jadi konsistensi berarti saya selalu dapat memeriksa kueri dengan mudah

  4. id juga pendek dan manis

  5. Konvensi tambahan - gunakan huruf kecil untuk semua nama tabel dan kolom, jadi tidak ada masalah yang ditemukan karena kasus tersebut


1

Hal lain yang perlu dipertimbangkan adalah bahwa jika nama kunci utama berbeda dari nama kunci asing, maka tidak mungkin untuk menggunakan alat pihak ketiga tertentu.

Misalnya, Anda tidak akan dapat memuat skema Anda ke alat seperti Visio dan membuatnya menghasilkan ERD yang akurat.


Itu akan menjadi kesalahan alat pihak ketiga. Konvensi penamaan kolom bukan pengganti kunci asing yang sebenarnya, yang harus diintrospeksi oleh alat ini.
Gerrat

1

Saya menemukan orang-orang di sini mencakup hampir setiap aspek tetapi saya ingin menambahkan bahwa "id" tidak dan tidak boleh dibaca sebagai "pengidentifikasi" itu lebih dari "indeks" dan tentu saja itu tidak menyatakan atau menggambarkan identitas baris. (Saya mungkin menggunakan kata-kata yang salah di sini, tolong perbaiki jika saya melakukannya)

Kurang lebih bagaimana orang membaca data tabel dan bagaimana mereka menulis kode mereka. Saya pribadi dan kemungkinan besar ini adalah cara paling populer yang saya lihat lebih sering adalah bahwa coders menulis referensi lengkap sebagai table.id, bahkan jika mereka tidak perlu melakukan persatuan atau / dan bergabung. Sebagai contoh:

SELECT cars.color, cars.model FROM cars WHERE cars.id = <some_var>

Dengan begitu Anda dapat menerjemahkannya ke bahasa Inggris sebagai "Beri saya warna dan model mobil yang diberi nomor." dan bukan sebagai "Beri aku warna dan model mobil yang diidentifikasi sebagai angka." ID tidak mewakili mobil dengan cara apa pun, itu hanya indeks mobil, nomor seri jika Anda mau. Sama seperti ketika Anda ingin mengambil elemen ketiga dari array.

Jadi untuk meringkas apa yang ingin saya tambahkan adalah bahwa itu hanya masalah preferensi dan cara membaca SQL yang dijelaskan adalah yang paling populer.

Padahal, ada beberapa kasus di mana ini tidak digunakan, seperti (contoh yang jauh lebih langka) ketika ID adalah string yang benar-benar menggambarkan. Misalnya id = "RedFordMustang1970"atau yang serupa. Saya sangat berharap saya bisa menjelaskan ini setidaknya untuk mendapatkan ide.

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.