Best Practice für konstante SQL-Werte

Question

In C# oder anderen ähnlichen Sprachen ist es eine schlechte Methode, wenn wir eine magische Zahl verwenden. Wie wäre es mit SQL?

CREATE PROCEDURE ProcessOrder 
    @productTypeId INT 
    , @productName NVARCHAR(50) 
AS 
BEGIN 

    IF (@productType = 3) -- Electronic product type 
     -- Handle electronic 
    ELSE IF (@productType = 4) -- Other product type  

END  

diese mit einer ENUM

Der Benutzeraufruf die INT konvertiert: Ich habe diese Art von SQL viel gesehen. Angenommen ProductType-Tabelle (3, 'Electronic') existiert. Was sollte hier die beste Praxis sein?

Answer 1

Sie können immer Funktionen verwenden.

CREATE FUNCTION 
    [dbo].PRODUCT_ELECTRO() 
RETURNS INT 
AS 
BEGIN 
     RETURN 3 
END 


-- This returns the value 3 
SELECT 
    dbo.PRODUCT_ELECTRO() 

IF @MyValue = dbo.PRODUCT_ELECTRO() 
BEGIN 
    PRINT 'The value is tres' 
END 

Answer 2

Wenn Sie eine Nachschlagetabelle haben, würde ich gerne eine Spalte namens "Code" für jeden Datensatz haben und es einzigartig halten. also werde ich immer auch der Lookup-Tabelle beitreten und diesen String-Wert verwenden, anstatt ihn mit einem ID-Feld zu prüfen. und der String-Wert kann etwas sein sinnvoll (Bsp .: ELE_PROD_TYPE) und Menschen lesbar.

IF (@productTypeCode = 'ELE_PROD_TYPE') 

Answer 3

Magische Zahlen sind sicherlich eine schlechte Antipattern. Konstanten, die sich auf magische Zahlen beziehen, sind jedoch ein Muster. Wie

if (productType == 3) //Bad 
if (productType == PRODUCT_ELECTRO) //Good even while PRODUCT_ELECTRO=3 

Eine gute Praxis in SQL verwendet lookup tables!

PRODUCT TABLE 
TYPE  DESCRIPTION 
1   FOOD 
2   ELECTRONIC 
3   HOUSE 

Und dann definieren Sie Ihre Entitäten mit einem FOREIGN KEY zu dieser Tabelle.

Beispiel

CREATE TABLE PRODUCT_TYPES (PRODUCT_TYPE_ID NUMBER PRIMARY KEY, PRODUCT_TYPE_DESCRIPTION VARCHAR2); 

CREATE TABLE PRODUCTS (PRODUCT_ID NUMBER PRIMARY KEY, PRODUCT_TYPE NUMBER NOT NULL REFERENCES PRODUCT_TYPES(PRODUCT_TYPE_ID), BLA BLA BLA..........); 

In Ihrem Code Sie Konstanten wie

public class ProductTypes { 
    public const int FOOD_PRODUCT = 1; 
    ...... 
} 

Beispiel query (mir bitte erinnern Sie nicht, dass dieses Muster :) unsicher ist)

definieren

öffentlich Produkt [] getElectronicProducts() { ... // init Verbindung bla bla bla Command.CommandText = Strin g.Format ("SELECT * VON PRODUKTEN, WO PRODUCT_TYPE = {0}", ProductTypes.ELECTRONIC_PRODUCT);

//Produces "SELECT * FROM PRODUCTS WHERE PRODUCT_TYPE = 3" 

... //do the query and return 

}

Answer 4

Mit Aufzählungen mit Werten es ein gutes Design ist.

eine Lookup-Tabelle Hinzufügen bietet zwei Vorteile:

1: Sie referentielle Integrität hinzufügen

2: jemand diese magischen Zahlen, die Lookup-Tabelle finden und klar seine Zweifel versuchen zu erraten, was

Der wichtigste Teil des Anwendungscodes ist die Verwendung von Enums. Sie können sogar use attributes to assign string keys to enum values.

So lassen Sie mich empfehlen, eine Tabelle zu verwenden, die anstelle von "magischen Zahlen" etwas vernünftige Saiten haben.(4 Zeichen = 4 Bytes, wie ein int key - 1 char ist 1 Byte, wie ein tinyint)

Sie eine Lookup-Tabelle wie diese haben könnten:

Key  Value 
'Elec' 'Electronic' 
'Othr' 'Other' 

mit dem gleichen Raum wie wenn Du hattest einen Int-Schlüssel.

Dies erleichtert das Lesen Ihrer SQL-Abfragen.