Deshacerse de los números "mágicos" en SQL Server

En el código uno puede especificar constantes/enums/etc accesibles en el mundo una vez que luego se pueden reutilizar a través de la aplicación. Esto le da la capacidad de usar nombres significativos como 'Mazda' en lugar de números como '2'.Deshacerse de los números "mágicos" en SQL Server

Nos gustaría hacer lo mismo con nuestros procedimientos almacenados de SQL Server, pero no estamos seguros de la mejor manera de implementar esto.

Por ejemplo, para las siguientes tablas (El esquema coche proverbiales):

Car  ManufacturerId 
350Z  1 
Hilux  2 
Yaris  2 

ManufacturerId Name 
1    Nissan 
2    Toyota

Así que en lugar de escribir

SELECT * FROM Car WHERE ManufacturerId = 1 -- Nissan

Nos gustaría escribir algo como

SELECT * FROM Car WHERE ManufacturerId = @Nissan

Una restricción lo que tenemos es que no podemos confiar en que Manufacturer.Name permanezca igual durante la vida de la aplicación. Nos hacían pensar en tener una columna "Código" que nunca cambia y las combinaciones que se buscan de esta manera:

SELECT * 
FROM Car c 
    INNER JOIN Manufacturer m ON c.ManufacturerId = m.ManufacturerId 
WHERE m.Code = 'Nissan'

Estoy un poco indeciso sobre este, ya que utiliza un extra y se unen a las comparaciones de cadenas que pueden estar mal escritas .

¿Cuál es la mejor manera de lograr esto sin tener que declarar las variables en cada procedimiento almacenado?

Fuente

2009-06-26 Robert Wagner

Hemos hecho esto un par de maneras:

función definida por el usuario que devuelve el "número mágico" por su nombre.
Utilice una columna nchar (4) en lugar de la columna int y obtenga códigos menos inescrutables. Entonces Nissan sería "NISN" en lugar de 1. Un poco más agradable.

Fuente

2009-06-26 00:32:13

Jugó con la primera sugerencia, pero es demasiado tarde para la segunda. Quizás la próxima vez. –

Lo que se pone difícil con este problema es que el número mágico generalmente corresponde a una enumeración en su código de cliente. En algún momento se arruinará la sincronización de su búsqueda SQL con la enumeración del cliente. MS SQL Server ofrece aquí un punto de integración muy ordenado: puede codificar una UDF de CLR para devolver el valor enum, lo que básicamente impone cierto tipo de seguridad de tipo de tiempo de ejecución. Sin embargo, todavía necesita asegurarse de que sus consultas obtengan los nombres de los valores enum, nunca he encontrado una forma de solucionar esta parte del problema. –

No necesita almacenar números en la base de datos. Hay administradores de DB que todavía adoran la idea de "claves naturales". En lugar de usar una ID, simplemente usan una clave natural que define de manera única al fabricante. A menudo, esto puede conducir a múltiples claves primarias. Es posible que tenga que tener un 'Mazda' 'Canadá' como identificador único para el fabricante.

Personalmente, no me gusta este método, y prefiero tener una identificación única para cada objeto identificable almacenado en mis tablas. Esto significa crear una nueva tabla que es una búsqueda. 2, 'Mazada'. Luego puede crear una vista que arrastre 'Mazda' en donde hay 2 en la base de datos, luego ejecute la consulta en contra de la vista. SELECCIONE * de v_cars donde maker = 'Mazda'

Fuente

2009-06-26 00:52:57 Kieveli

Además de llegar tarde a cambiar el arreglo, estoy de acuerdo con usted en no utilizar claves naturales en estos casos, ya que facilita el uso de enums en el código. Me gusta la idea de vista. –

Deshacerse de los números "mágicos" en SQL Server

Respuesta

Cuestiones relacionadas