2012-01-11 13 views
5

Tengo la siguiente consulta:consulta SQL - deshacerse de los valores no modificables

Select Name, 
     case when charindex('I',a.S_Data) > 0 then 1 else 0 end as Illustrated, 
     case when charindex('FP',a.S_Data) > 0 then 1 else 0 end as FrontPage, 
     case when charindex('BP',a.S_Data) > 0 then 1 else 0 end as BackPage, 
     case when charindex('ELP',a.S_Data) > 0 then 1 else 0 end as EDLP, 
     case when charindex('PR',a.S_Data) > 0 then 1 else 0 end as SpecialPromo 
From Table1 

Lo que me gustaría hacer es almacenar los valores de filtro en una especie de tabla de consulta o una tabla de valores.

Estoy luchando con la forma de dibujar los valores de una tabla de búsqueda para usar con esta consulta.

+6

seguro de la cantidad que ganaría, ya que estoy suponiendo que todavía querría los nombres de columna codificados ('Illustrated', 'FrontPage', etc.) asociado con esos valores en su conjunto de resultados. –

+0

¿Qué tal crear una vista para esta selección? –

+0

Eso es lo que pensé, es decir, "¿vale la pena?" – Perplexed

Respuesta

3

puedo pensar en por lo menos dos opciones ...

CREATE TABLE constants (
    id    AS INT, 
    Illustrated  AS VARCHAR(3), 
    FrontPage  AS VARCHAR(3), 
    BackPage   AS VARCHAR(3), 
    EDLP    AS VARCHAR(3), 
    SpecialPromo  AS VARCHAR(3) 
) 

INSERT INTO constants SELECT 1, 'I', 'FP', 'BP', 'ELP', 'PR' 

SELECT 
    Name, 
    CASE WHEN CHARINDEX(constants.Illustrated, data.S_Data) > 0 THEN 1 ELSE 0 END AS Illustrated, 
    etc, etc 
FROM 
    data 
INNER JOIN 
    constants 
    ON constants.id = 1 

O ...

CREATE TABLE constants (
    constant_set_id AS INT, 
    constant_name AS VARCHAR(16), 
    value   AS AS VARCHAR(3) 
) 

INSERT INTO constants SELECT 1, 'Illustrated', 'I' 
INSERT INTO constants SELECT 1, 'FrontPage', 'FP' 
INSERT INTO constants SELECT 1, 'BackPage',  'BP' 
INSERT INTO constants SELECT 1, 'EDLP',   'ELP' 
INSERT INTO constants SELECT 1, 'SpecialPromo', 'PR' 

SELECT 
    Name, 
    MAX(CASE WHEN constants.constant_name = 'Illustrated' AND CHARINDEX(constants.value, data.S_Data) > 0 THEN 1 ELSE 0 END) AS Illustrated, 
    etc, etc 
FROM 
    data 
INNER JOIN 
    constants 
    ON constants.constant_set_id = 1 
GROUP BY 
    data.name 

Ambos le permiten tener varios conjuntos diferentes de las constantes. Uno es ampliable sin cambiar el esquema, aunque la consulta todavía tendría que cambiar.

La principal ventaja de cualquiera de los enfoques es que puede reutilizar las constantes else else, pero almacenarlas una vez en una ubicación centralizada. Lo cual solo es relevante si/cuando los valores en las constantes necesitan actualización. Reutilizar a través de indirección.

+0

Brillante, ¡gracias! – Perplexed

1

Por el momento, su tabla aparentemente infringe First Normal Form, ya que un solo campo puede contener muchos valores para un solo registro.

Hay al menos dos maneras en que esto podría ser resuelto:

(1) si los únicos valores que se pueden almacenar en este campo son los cinco especificado en la consulta, podría tener sentido para reemplazar el campo de caracteres con cinco campos de enteros, cada una bandera para la condición especificada - es decir:

... 
Illustrated int, 
FrontPage int, 
BackPage int, 
EDLP int, 
SpecialPromo int, 
... 

(2) Si una variedad de diferentes condiciones han de ser almacenado, entonces sugeriría la adición de una tabla de búsqueda para las condiciones, y un enlace tabla entre las condiciones y la tabla original - como lo siguiente:

Conditions 
---------- 
Condition_id 
Description 

Link_Table 
---------- 
Table1_id 
Condition_id 
+0

+1 por violación de 1NF. – onedaywhen

1

En primer lugar, parece que Table1 no es la primera forma normal (NFNF) porque no cumple con el requisito de que cada tupla de tiene exactamente un valor para cada atributo que es del tipo que es el tipo declarado de ese atributo es decir, el S_Data tiene múltiples tipos escalares. Usted sufrirá anomalías de actualización, p. borrar una configuración implica presumiblemente un UPDATE con concatenación de texto. Tenga en cuenta que SQL no tiene operadores que manejen este tipo de datos (es decir, no relacionales) muy bien.

En segundo lugar, su tabla de salida es inferior a la óptima porque devuelve el mismo tipo que varias columnas, es decir, se parece más a un informe.

consideran que la unidad de trabajo en SQL es la fila:

CREATE TABLE Settings 
(
Setting VARCHAR(15) NOT NULL UNIQUE 
); 

INSERT INTO Settings VALUES ('Illustrated'), ('FrontPage'), ('BackPage'), 
          ('EDLP'), ('SpecialPromo'); 

CREATE TABLE Table1 
(
Name VARCHAR(20) NOT NULL, 
Setting VARCHAR(15) NOT NULL 
    REFERENCES Settings (Setting) 
    ON DELETE CASCADE 
    ON UPDATE CASCADE, 
UNIQUE (Name, Setting) 
); 
No
Cuestiones relacionadas