Apakah desain tabel satu kolom bagus? [Tutup]


111

Bolehkah memiliki tabel hanya dengan satu kolom? Saya tahu ini tidak ilegal secara teknis, tetapi apakah itu dianggap desain yang buruk?

EDIT:

Berikut beberapa contohnya:

  • Anda memiliki tabel dengan 50 kode negara bagian AS yang valid, tetapi Anda tidak perlu menyimpan nama negara bagian yang bertele-tele.
  • Daftar hitam email.

Seseorang menyebutkan menambahkan bidang kunci. Menurut saya, kolom tunggal ini AKAN menjadi kunci utama.


Saya mengalami sedikit kesulitan membayangkan kasus penggunaan untuk tabel dengan hanya satu kolom. Bisakah Anda memberi contoh?
Paul Morie

tapi setidaknya jangan membuat Indeks untuk itu!
Sathya

3
Kode negara bagian AS adalah contoh klasik untuk menentukan domain
Quassnoi

3
Saya pernah melihat tabel database yang digunakan untuk menyimpan nilai kunci untuk aplikasi sebelumnya
Russ Cam

Saya menggunakan pola ini untuk membuat kumpulan data. Setiap record di tabel utama memiliki field SET. Rekaman dengan SET yang sama dihubungkan. Bagaimana Anda memasukkan banyak record dengan SET yang sama? 'INSERT INTO sets VALUES ()' dan kemudian gunakan insert ID terakhir sebagai SET ID Anda untuk dilampirkan ke record. Kemudian lagi, mungkin saya bisa menggunakan UUID, tetapi ada yang salah dengan itu.
William Entriken

Jawaban:


87

Ya, memang desain yang bagus untuk mendesain meja sedemikian rupa agar paling efisien. "Desain RDBMS yang Buruk" biasanya berpusat di sekitar inefisiensi.

Namun, saya telah menemukan bahwa sebagian besar kasus desain kolom tunggal dapat memperoleh manfaat dari kolom tambahan. Misalnya, Kode Status biasanya dapat mencantumkan nama Status Lengkap di kolom kedua. Atau daftar hitam dapat memiliki catatan yang terkait. Namun, jika desain Anda benar-benar tidak membutuhkan informasi tersebut, maka tidak masalah untuk memiliki kolom tunggal.


168

Dalam istilah relational algebraini akan menjadi hubungan unary, yang berarti " benda ini ada "

Ya, tidak masalah memiliki tabel yang mendefinisikan relasi seperti itu: misalnya, untuk mendefinisikan domain.

Nilai dari tabel seperti itu tentu saja harus natural primary key.

Tabel pencarian prime numbersadalah yang pertama terlintas di benak saya.


3
+1: Tabel adalah sekumpulan nilai yang kebetulan merupakan tipe primitif dari RDBMS Anda.
S. Lotot

4
1 untuk memberikan jawaban berdasarkan teori relasional.
lubos hasko

Berikut adalah contoh skema yang bagus yang memiliki tabel 1 kolom yang bukan merupakan kunci alami, tabel Thread di sistem pesan ... stackoverflow.com/a/6542556/45767
JeremyWeir

29

Saya telah menggunakannya di masa lalu. Salah satu klien saya ingin memblokir otomatis siapa pun yang mencoba mendaftar dengan nomor telepon di daftar besar yang dia miliki, jadi itu hanya satu daftar hitam besar.


19

Jika ada kebutuhan yang valid untuk itu, maka saya tidak melihat ada masalah. Mungkin Anda hanya ingin daftar kemungkinan untuk ditampilkan karena alasan tertentu dan Anda ingin dapat mengubahnya secara dinamis, tetapi tidak perlu menautkannya ke tabel lain.


+1 - Intinya, ini adalah jawaban yang benar dalam buku saya
Mark Brittingham

1 untuk jawaban yang ringkas dan jelas.
Matthew Jones

3
Mengapa tabel satu kolom tidak dapat ditautkan ke tabel lain?
Aheho

2
Kenapa tidak? Ambil tabel kode negara sebagai contoh. Mengapa Anda tidak menggunakannya sebagai batasan kunci asing terhadap tabel lain dengan bidang alamat?
Aheho

1
Itu adalah contoh yang bagus saat itu akan menjadi ide yang bagus.
Kevin

11

Satu kasus yang terkadang saya temukan adalah seperti ini:

Tabel country_id , hanya berisi satu kolom dengan ID numerik untuk setiap negara.

Tabel country_description , berisi kolom dengan ID negara, kolom dengan ID bahasa, dan kolom dengan nama negara yang dilokalkan.

Tabel company_factories , berisi informasi untuk setiap pabrik dari perusahaan tersebut, termasuk negara di mana lokasinya.

Jadi untuk menjaga koherensi data dan data independen bahasa dalam tabel, database menggunakan skema ini dengan tabel dengan hanya satu kolom untuk memungkinkan kunci asing tanpa ketergantungan bahasa.

Dalam hal ini saya pikir keberadaan tabel satu kolom dapat dibenarkan.

Diedit sebagai tanggapan atas komentar oleh: Quassnoi


(sumber: ggpht.com )

Dalam skema ini saya dapat mendefinisikan kunci asing di tabel company_factories yang tidak mengharuskan saya untuk memasukkan kolom Bahasa di tabel, tetapi jika saya tidak memiliki tabel countries_id, saya harus menyertakan kolom Bahasa di tabel untuk menentukan kunci asing .


2
Mengapa memiliki countries_id? Untuk memasukkan negara, Anda harus mengetahui namanya setidaknya dalam satu bahasa, dan ini akan menghasilkan country_id yang muncul di countries_description. Entri country_id tanpa country_description tidak ada artinya. "Tuan Barack Obama, Presiden COALESCE (14243, nama_negara) MENGEMBALIKAN NILAI NILAI, hari ini bertemu dengan Dmitry Medvedev, Presiden Россия"
Quassnoi

4
@Doliveras: Oke, saya mengerti sekarang, +1. Saya lebih suka menggunakan ISO 3166-1 untuk coutry_code. Tidak seperti id numerik, kode negara 3 huruf memberikan gambaran tentang negara apa yang disebutkan oleh hampir semua orang di dunia yang bisa membaca alfabet Latin.
Quassnoi

Berikut cara lain yang saya terapkan untuk mengakomodasi terjemahan bahasa alami dalam tabel yang sama. Memang, banyak kolom yang dapat dinihilkan, tetapi Anda dapat memindahkan integritas data ke pemicu kustom. CREATE TABLE "DBA" "myLocalisedTable" ( "entry_id" INTEGER NOT NULL DEFAULT AUTOINCREMENT, "master_entry_id" INTEGER NULL, "master_entry_label" VARCHAR (200) NULL, "LANGUAGE_ID" INTEGER NULL, "localised_entry_label" VARCHAR (300) NULL,.
Vincent Buck

7

Akan ada kasus yang jarang terjadi ketika tabel satu kolom masuk akal. Saya membuat satu database di mana daftar kode bahasa yang valid adalah tabel kolom tunggal yang digunakan sebagai kunci asing. Tidak ada gunanya memiliki kunci yang berbeda, karena kode itu sendiri adalah kuncinya. Dan tidak ada deskripsi tetap karena deskripsi kode bahasa akan bervariasi menurut bahasa untuk beberapa konteks.

Secara umum, setiap kasus di mana Anda memerlukan daftar nilai otoritatif yang tidak memiliki atribut tambahan adalah kandidat yang baik untuk tabel satu kolom.


5

Saya menggunakan tabel satu kolom sepanjang waktu - tergantung, tentu saja, apakah desain aplikasi sudah menggunakan database. Setelah saya menanggung beban desain untuk membuat koneksi database, saya memasukkan semua data yang bisa berubah ke dalam tabel jika memungkinkan.

Saya dapat memikirkan dua kegunaan tabel kolom tunggal OTMH:

1) Item data ada. Sering digunakan dalam daftar dropdown. Juga digunakan untuk tes legitimasi sederhana.

Misalnya. singkatan negara bagian AS dua huruf; Kode pos yang kami kirim; kata-kata legal di Scrabble; dll.

2) Atribut biner renggang, yaitu, dalam tabel besar, atribut biner yang benar hanya untuk beberapa record. Alih-alih menambahkan kolom boolean baru, saya mungkin membuat tabel terpisah yang berisi kunci record yang atributnya benar.

Misalnya. karyawan yang memiliki penyakit terminal; bank dengan 360 hari setahun (sebagian besar menggunakan 365); dll.

-Al.



4

Sebagian besar saya telah melihat ini di tabel tipe pencarian seperti tabel status yang Anda jelaskan. Namun, jika Anda melakukan ini, pastikan untuk mengatur kolom sebagai kunci utama untuk memaksa keunikan. Jika Anda tidak dapat menetapkan nilai ini sebagai unik, Anda tidak boleh menggunakan satu kolom.


Meskipun menggunakan satu kolom di sini mungkin baik-baik saja, perlu diingat bahwa Anda juga dapat mengatur batasan keunikan di kolom lain.
Stealth Rabbi

2

Saya akan mengatakan secara umum, ya. Tidak yakin mengapa Anda hanya membutuhkan satu kolom. Ada beberapa pengecualian untuk ini yang saya lihat digunakan secara efektif. Itu tergantung pada apa yang ingin Anda capai.

Mereka tidak benar-benar desain yang bagus ketika Anda memikirkan skema database, tetapi seharusnya hanya digunakan sebagai tabel utilitas.

Saya telah melihat tabel angka digunakan secara efektif di masa lalu.


1

Tujuan database adalah menghubungkan potongan informasi satu sama lain. Bagaimana Anda bisa melakukan itu ketika tidak ada data untuk dihubungkan?

Mungkin ini semacam tabel kompilasi (yaitu Nama Depan + Nama Belakang + Tanggal Lahir), meskipun saya masih tidak yakin mengapa Anda ingin melakukan itu.

EDIT: Saya bisa melihat menggunakan tabel semacam ini untuk daftar sederhana dari beberapa jenis. Apakah itu tujuan Anda menggunakannya?


9
Tidak, tujuan utama database adalah untuk menyimpan informasi.
Spencer Ruport

Tetapi spreadsheet dapat menyimpan informasi. Dan bagaimana informasi itu berguna jika hanya sekelompok angka dan huruf yang terputus-putus tanpa korelasi di antara mereka?
Matthew Jones

Informasi tersebut dapat berguna karena aplikasi yang menggunakan database membutuhkannya dan ini bukan kumpulan yang tetap. Artinya, DB hanyalah tempat yang paling nyaman untuk meletakkan informasi yang akan digunakan oleh aplikasi database - relasional atau sebaliknya. Saya cukup yakin Anda setuju bahwa kami tidak membangun aplikasi untuk membuktikan kemurnian kami sehubungan dengan ideal relasional. Sebagai gantinya, kami membangun aplikasi agar berguna.
Mark Brittingham

@ Mark - Itulah yang saya maksud dengan daftar sederhana. Sepertinya saya tidak menjelaskan diri saya dengan baik.
Matthew Jones

1
@SR - Tidak, tujuan utama database adalah untuk mengambil informasi. Karena deretan minat lebih sering bergantung pada bagian data lain, saya pikir komentar asli MJ berlaku.
CurtainDog

1

Ya, selama field adalah kunci utama seperti yang Anda katakan. Alasannya karena jika Anda memasukkan data duplikat, baris tersebut hanya akan dapat dibaca. Jika Anda mencoba untuk menghapus salah satu baris yang digandakan. itu tidak akan berfungsi karena server tidak akan tahu baris mana yang akan dihapus.


2
Konyol sekali. Operasi penghapusan tanpa kunci utama atau batasan akan menghapus semua baris yang cocok, tidak mengabaikannya.
Erik Funkenbusch

1
Dengan 'tidak berfungsi', yang dia maksud adalah "tidak berfungsi seperti yang diharapkan", yang mencakup kondisi "hai saya menghapus satu baris tetapi keduanya hilang".
GWLlosa

Atau, jika Anda mencoba menghapus rekaman di SSMS dari tampilan "Tabel Terbuka", ini akan memunculkan dialog bahwa rekaman tidak dapat diidentifikasi secara unik dan kemudian tidak melakukan apa-apa ...
Michael Fredrickson

-1

Satu-satunya kasus penggunaan yang dapat saya bayangkan adalah tabel kata-kata yang mungkin untuk permainan kata. Anda mengakses tabel hanya untuk memverifikasi bahwa sebuah string adalah sebuah kata: pilih kata dari kata-kata di mana kata =?. Tetapi ada struktur data yang jauh lebih baik untuk menyimpan daftar kata daripada relasional database yang.

Jika tidak, data dalam database biasanya ditempatkan di database untuk memanfaatkan hubungan antara berbagai atribut data. Jika data Anda tidak memiliki atribut di luar nilainya, bagaimana hubungan ini akan dikembangkan?

Jadi, meski tidak ilegal, secara umum Anda mungkin tidak boleh memiliki tabel dengan hanya satu kolom.


Mirip dengan ini adalah tabel angka yang sangat berguna untuk menghentikan perulangan.
u07ch

-1

Semua tabel saya memiliki setidaknya empat bidang teknologi, kunci utama serial, stempel waktu pembuatan dan modifikasi, dan penghapusan lunak boolean. Dalam daftar hitam mana pun, Anda juga pasti ingin tahu siapa yang menambahkan entri. Jadi bagi saya, jawabannya adalah tidak, tabel dengan hanya satu kolom tidak akan masuk akal kecuali saat membuat prototipe sesuatu.


1
Sepertinya Anda mencampur tabel data dengan tabel transaksi. Menurut saya, ini harus menjadi dua hal yang terpisah.
Josh Noe

-2

Ya itu baik-baik saja. tetapi bidang ID tidak bisa melukainya kan?


7
Sebenarnya bisa. Saat Anda memiliki daftar definitif dari nilai yang valid, hal terakhir yang Anda inginkan adalah bidang ID karena menyiratkan bahwa nilainya tidak unik. Jika 'LightBlue' adalah kuncinya, maka Anda tidak ingin seseorang berpikir bahwa 'LightBlue' dengan id 1 mungkin berbeda dari 'LightBlue' dengan id 4.
Jeremy Bourque

Siapa bilang Id harus identitas? Atau bagian dari kuncinya?
Eric

3
Ini bisa menjadi kunci sintetis dan bidang asli bisa memiliki batasan unik.
Mark Canlas
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.