INT atau CHAR untuk Bidang Jenis

Apa desain terbaik untuk tabel, Typebidang yang dari intatau char(1)? Dengan kata lain, diberikan skema ini:

create table Car
(
    Name varchar(100) not null,
    Description varchar(100) not null,
    VehType .... not null
)

Apakah lebih efisien (dari segi kinerja) untuk VehTypemenjadi seorang intatau char(1)? Katakanlah Anda memiliki lima jenis mobil, haruskah Anda menggunakan nilai tambah 0 -> 4, atau karakter untuk jenis tersebut (misalnya; 'v', 's', 'c', 't', 'm')?

Jika lebih dari itu, saya akan menggunakan tabel Tipe terpisah dan memiliki hubungan kunci asing, tapi saya tidak melihat perlunya.

Saya perhatikan bahwa tampilan sys.objectskatalog menggunakan karakter untuk typebidang tersebut. Apakah ada alasan untuk itu? Apakah saya hanya meraih udara tipis di sini, dan apakah itu yang paling nyaman bagi saya?

sql-server database-design datatypes

— Thomas Stringer
sumber

Jawaban:

Anda biasanya menggunakan tinyint yang juga 1 byte

char (1) akan sedikit lebih lambat karena membandingkan penggunaan collation
kebingungan: apakah S: SUV atau Saloon atau Sedan atau Olahraga?
menggunakan huruf membatasi Anda saat Anda menambahkan lebih banyak jenis. Lihat poin terakhir.
setiap sistem yang saya lihat memiliki lebih dari satu klien misalnya pelaporan. Logika untuk mengubah V, S menjadi "Van", "SUV" dll perlu diulangi. Menggunakan tabel pencarian berarti itu GABUNG sederhana
diperpanjang: tambahkan satu jenis lagi ("F" untuk " Mobil terbang ") Anda dapat satu baris ke tabel pencarian atau mengubah banyak kode dan kendala. Dan kode klien Anda juga karena ini harus tahu apa V, S, F dll
pemeliharaan: logika ada di 3 tempat: batasan basis data, kode basis data dan kode klien. Dengan pencarian dan kunci asing, itu bisa berada di satu tempat

Di sisi positifnya menggunakan satu huruf ... eh, tidak ada

Catatan: ada pertanyaan terkait MySQL tentang Enums . Rekomendasi adalah untuk menggunakan tabel pencarian di sana juga.

— gbn
sumber

poin bagus. Itu membuat saya bertanya-tanya mengapa orang lain menggunakan char (1) (seperti sys.objects).

— Thomas Stringer

sys.objects memiliki peninggalan kembali ke Sybase dan versi awal SQL Server en.wikipedia.org/wiki/Microsoft_SQL_Server#Genesis Jika Anda melihat objek sistem, Anda dapat melihat kode bukan ID di seluruh: tetapi lebih sedikit pada DMV baru. Adapun orang lain kecuali MS? Pikirkan RDBMS dan bukan OO / Enums dan masuk akal untuk menggunakan Pencarian.

— gbn

Baiklah saya setuju. Terima kasih telah menjelaskannya. Jadi apakah ini pernyataan yang cukup akurat bahwa tidak ada rekayasa berlebihan nyata dengan integritas relasional dan tabel pencarian? Maksud saya, dalam hal ini dengan menyimpan beberapa catatan dalam tabel pencarian dan merujuknya ke tabel konsumsi, apakah pernyataan sebelumnya akurat?

— Thomas Stringer

@onedaywhen: Ini membuat perbedaan apakah Anda melihat tipe berbeda sebagai data atau sebagai kumpulan nilai statis yang tidak akan pernah berubah. Jika Anda menggunakan tabel tipe, Anda bisa menambahkan tipe lain ke tabel tanpa perlu mengubah aturan bisnis dalam database dan aplikasi.

— Guffa

@ MichaelKjörling: Benar, jika itu hanya kunci. Tapi OP bermaksud untuk berarti sesuatu seperti "v" atau "s". Catatan, kami tidak sedang mendeskripsikan diri sendiri dan menyelesaikan kunci alami seperti kode mata uang (EUR, USD, GBP, CHF dll).

— gbn

Sama seperti pelengkap jawaban gbn besar .

Mungkin Anda bisa membuat sesuatu seperti itu:

create table dbo.VehicleType
(
    VehicleTypeId int not null primary key,
    Name varchar(50) not null,
    Code char(3) null
) 
go 

create table Car
(
    Name varchar(100) not null,
    Description varchar(100) not null,
    VehTypeId int not null ,
    foreign key FKTypeOfCar(VehTypeId) referenctes dbo.VehicleType (VehicleTypeId) 
)
go

Jadi, Anda dapat melakukan sesuka Anda dengan enum sambil mempertahankan integritas relasional (menggunakan kunci asing). Dengan codekolom, Anda dapat menggunakan kode char sesuka Anda, sehingga akan didokumentasikan pada basis data (dan Anda dapat mengekstrak info kode langsung dari DB, tanpa transformasi yang berbelit-belit pada kode aplikasi untuk integrasi sistem).

— Fabricio Araujo
sumber

Apakah Anda bermaksud mengizinkan suatu nullkode?

— Jack Douglas

Ya, kode bersifat opsional untuk memungkinkan mewakili jenis kendaraan yang belum dikodifikasi.

— Fabricio Araujo

Mengapa orang suka tetap menghapus komentar? Cukup menyebalkan.

— Fabricio Araujo

@FabricioAraujo - Jika komentar sudah usang (mis. "Saya akan mengedit jawaban saya" dan kemudian Anda benar-benar melakukannya) maka ada baiknya untuk membersihkan komentar yang tidak lagi berlaku.

— Nick Chammas

Saya akan menyarankan menambahkan tipe "Tidak Diklasifikasikan" ke tabel jenis Anda dan membuat nilai default bidang VehTypeId Anda yang nilai tidak terklasifikasi, daripada membiarkan nilai nol di bidang kunci asing. Biasanya praktik buruk membuat "null" memiliki makna bisnis yang valid.

— Michael Blackburn