INT o CHAR per un campo Tipo

Qual è il miglior design per un tavolo, un Typecampo di into char(1)? In altre parole, dato questo schema:

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

È più efficiente (in termini di prestazioni) VehTypeessere into o char(1)? Supponi di avere cinque tipi di auto, dovresti usare i valori incrementali 0 -> 4 o i caratteri per i tipi (diciamo; 'v', 's', 'c', 't', 'm')?

Se è qualcosa di più, userei una tabella Tipo separata e avrei una relazione di chiave esterna, ma non ne vedo la necessità.

Ho notato che la sys.objectsvista del catalogo utilizza un carattere per il typecampo. C'è una ragione per questo? Sto solo afferrando l'aria sottile qui, ed è tutto ciò con cui mi sento più a mio agio?

sql-server database-design datatypes

— Thomas Stringer
fonte

Risposte:

In genere useresti tinyint che è anche 1 byte

char (1) sarà leggermente più lento perché il confronto utilizza le regole di confronto
confusione: che cos'è S: SUV o Berlina o Berlina o Sport?
l'utilizzo di una lettera ti limita quando aggiungi altri tipi. Vedi l'ultimo punto.
ogni sistema che ho visto ha più di un client, ad es. reportistica. La logica di cambiare V, S in "Van", "SUV" ecc. Dovrà essere ripetuta. L'uso di una tabella di ricerca significa che è un semplice JOIN
estensibilità: aggiungi un altro tipo ("F" per " Macchina volante "), puoi passare una riga a una tabella di ricerca o modificare un sacco di codice e vincoli. E anche il tuo codice cliente perché questo deve sapere quali sono V, S, F ecc
manutenzione: la logica è in 3 punti: vincolo del database, codice del database e codice client. Con una ricerca e una chiave esterna, può trovarsi in un unico posto

Tra i lati positivi dell'uso di una sola lettera ... er, non ne vedo nessuna

Nota: esiste una domanda MySQL relativa a Enums . La raccomandazione è di usare anche una tabella di ricerca.

— GBN
fonte

grandi punti. Mi chiedo perché gli altri usano char (1) (come sys.objects).

— Thomas Stringer,

sys.objects ha un retaggio di tornare a Sybase e le prime versioni di SQL Server en.wikipedia.org/wiki/Microsoft_SQL_Server#Genesis Se si guarda gli oggetti del sistema è possibile vedere codici non gli ID in tutto: ma meno nelle nuove DMV. Per quanto riguarda le altre persone tranne la SM? Pensa a RDBMS e non a OO / Enum e ha senso usare le ricerche.

— gbn

Ok, sono d'accordo. Grazie per averlo chiarito. Quindi è un'affermazione abbastanza accurata che non esiste una vera ingegneria eccessiva con integrità relazionale e tabelle di ricerca? Voglio dire, in questo caso con l'archiviazione di una manciata di record in una tabella di ricerca e il riferimento a essi in una tabella di consumo, la precedente dichiarazione sarebbe accurata?

— Thomas Stringer,

@onedaywhen: fa la differenza se guardi i diversi tipi come dati o come set di valori statici che non cambieranno mai. Se si utilizza una tabella dei tipi, è possibile semplicemente aggiungere un altro tipo alla tabella senza la necessità di modificare le regole aziendali nel database e nell'applicazione.

— Guffa,

@ MichaelKjörling: esatto, se fosse solo una chiave. Ma OP intende che significhi qualcosa come "v" o "s". Nota, non ci occupiamo di auto-descrivendo e completiamo le chiavi naturali come i codici valuta (EUR, USD, GBP, CHF ecc.).

— gbn,

Proprio come complemento alla risposta di grande gbn .

Forse potresti creare qualcosa del genere:

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

Quindi puoi fare come ti pare con il tuo enum mantenendo l'integrità relazionale (usando una chiave esterna). Con la codecolonna puoi usare i tuoi codici char a piacimento, così diventerà documentato sul database (e puoi estrarre le informazioni del codice direttamente dal DB, senza una trasformazione contorta sul codice dell'applicazione per un'integrazione di sistemi).

— Fabricio Araujo
fonte

Intendi consentire un nullcodice?

— Jack Douglas,

Sì, il codice è facoltativo per consentire di rappresentare un tipo di veicolo non ancora codificato.

— Fabricio Araujo,

Perché alla gente piace rimanere eliminando i commenti? È piuttosto fastidioso.

— Fabricio Araujo,

@FabricioAraujo - Se un commento è obsoleto (ad es. "Lo modificherò nella mia risposta" e poi lo farai davvero), allora è bene ripulire i commenti che non si applicano più.

— Nick Chammas,

Suggerirei di aggiungere un tipo "Non classificato" alla tabella dei tipi e di rendere il valore predefinito del campo VehTypeId quel valore non classificato, piuttosto che consentire un valore nullo nel campo chiave esterna. In genere è una cattiva pratica rendere "null" un significato commerciale valido.

— Michael Blackburn,