INT o CHAR para un campo de tipo

¿Cuál es el mejor diseño para una tabla, un Typecampo que es de into char(1)? En otras palabras, dado este esquema:

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

¿Es más eficiente (en cuanto al rendimiento) VehTypeser un into un char(1)? Digamos que tiene cinco tipos de automóviles, ¿debería usar los valores incrementales 0 -> 4, o caracteres para los tipos (por ejemplo, 'v', 's', 'c', 't', 'm')?

Si es más que eso, usaría una tabla Tipo separada y tendría una relación de clave externa, pero no veo la necesidad de eso.

Noto que la sys.objectsvista de catálogo usa un carácter para el typecampo. ¿Hay alguna razón para eso? ¿Estoy agarrando el aire aquí y es con lo que me siento más cómodo?

sql-server database-design datatypes

— Thomas Stringer
fuente

Respuestas:

Por lo general, usaría tinyint, que también es 1 byte

char (1) será un poco más lento porque la comparación utiliza la intercalación
confusión: ¿qué es S: SUV o Saloon o Sedan o Sports?
usar una letra lo limita a medida que agrega más tipos. Ver último punto.
Todos los sistemas que he visto tienen más de un cliente, por ejemplo, informes. Será necesario repetir la lógica de cambiar V, S en "Van", "SUV", etc. Usar una tabla de búsqueda significa que es una simple UNIÓN
Extensibilidad: agregue un tipo más ("F" para " Auto volador "), puede remar una fila a una tabla de búsqueda o cambiar mucho código y restricciones. Y su código de cliente también porque esto tiene que saber qué son V, S, F, etc.
mantenimiento: la lógica está en 3 lugares: restricción de la base de datos, código de la base de datos y código del cliente. Con una búsqueda y clave externa, puede estar en un solo lugar

En el lado positivo de usar una sola letra ... er, no veo ninguna

Nota: hay una pregunta relacionada de MySQL sobre Enums . La recomendación es usar una tabla de búsqueda allí también.

— gbn
fuente

Grandes puntos. Me hace preguntarme por qué otros usan char (1) (como sys.objects).

— Thomas Stringer el

sys.objects tiene un legado que se remonta a Sybase y a las primeras versiones de SQL Server en.wikipedia.org/wiki/Microsoft_SQL_Server#Genesis Si observa los objetos del sistema, puede ver códigos, no identificadores por todas partes, pero menos en los nuevos DMV. ¿En cuanto a otras personas excepto MS? Piense RDBMS y no OO / Enums y tiene sentido usar las búsquedas.

— gbn

OK estoy de acuerdo. Gracias por aclararlo. Entonces, ¿es una afirmación bastante precisa de que no hay una sobreingeniería real con integridad relacional y tablas de búsqueda? Quiero decir, en este caso con almacenar un puñado de registros en una tabla de búsqueda y hacer referencia a ellos en una tabla de consumo, ¿sería correcta la declaración anterior?

— Thomas Stringer

@onedaywhen: hace una diferencia si ves los diferentes tipos como datos o como un conjunto estático de valores que nunca cambiarán. Si usa una tabla de tipos, puede agregar otro tipo a la tabla sin necesidad de cambiar las reglas de negocio en la base de datos y en la aplicación.

— Guffa

@ MichaelKjörling: Correcto, si fuera solo una clave. Pero OP pretende que signifique algo así como "v" o "s". Tenga en cuenta que no hablamos de autodescripción y claves naturales completas como códigos de moneda (EUR, USD, GBP, CHF, etc.).

— gbn

Solo como un complemento a la gran respuesta de gbn .

Tal vez podrías crear algo así:

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

Entonces puede hacer lo que quiera con su enumeración mientras mantiene la integridad relacional (usando una clave foránea). Con la codecolumna puede usar sus códigos char a voluntad, por lo que quedará documentado en la base de datos (y puede extraer la información del código directamente de DB, sin una transformación complicada en el código de la aplicación para una integración de sistemas).

— Fabricio Araujo
fuente

¿Quieres decir permitir un nullcódigo?

— Jack Douglas el

Sí, el código es opcional para permitir representar un tipo de vehículo que aún no está codificado.

— Fabricio Araujo

¿Por qué a la gente le gusta quedarse eliminando comentarios? Es bastante molesto.

— Fabricio Araujo

@FabricioAraujo: si un comentario está obsoleto (por ejemplo, "lo editaré en mi respuesta" y luego lo haces), entonces es bueno limpiar los comentarios que ya no se aplican.

— Nick Chammas

Sugeriría agregar un tipo "Sin clasificar" a su tabla de tipos y hacer que el valor predeterminado de su campo VehTypeId sea ese valor sin clasificar, en lugar de permitir un valor nulo en el campo de clave externa. En general, es una mala práctica hacer que "nulo" tenga un significado comercial válido.

— Michael Blackburn