Struttura gerarchica che deve rafforzare la disponibilità

Dopo aver affrontato grandi risposte qui. Ho implementato (la risposta di Joel Brown sul link)

link

senza numeri di visita . Ho esaminato casi d'uso e questo approccio sta risolvendo ciascuno di essi, inoltre è abbastanza generico da permettermi di ignorare qualsiasi campo mi piacerebbe. Purtroppo non posso contrassegnare il commento di Vlad come risposta.

Il modello gerarchico non sembra una buona idea. Idealmente al livello più alto c'è una voce.

Ad esempio, per Asia, ci sarebbe una voce: Nokia

Ora, se si smette di vendere telefoni Nokia in Asia, si rimuoverà solo quel record al livello più alto e il cambiamento si ridurrà a cascata verso gli altri livelli. Questo è ciò che rende un modello gerarchico potente.

Se hai molte eccezioni, come possiamo vendere Nokia in Asia, ma per questa regione per questi 2 negozi non possono vendere Nokia, e per questa regione per questi 5 negozi non possiamo vendere Nokia, quindi il modello gerarchico cade a pezzi.

La disponibilità del telefono non ha senso perché, solo perché il telefono è disponibile in Asia, potrebbe non esserlo per una regione o un negozio perché potrebbe essere esaurito, ecc. Questo perché i modelli gerarchici funzionano dall'alto verso il basso. Quindi, la disponibilità di modelli su questo non sarà una buona idea.

Si può ancora modellare le posizioni dei negozi come gerarchiche. Ciò ti consentirà di eseguire query gerarchiche, come quanti telefoni sono disponibili per questa regione, ecc.

Ma collegherei la disponibilità agli ID dei negozi invece che a un ID o a un paese o regione in modo relazionale rispetto a quello gerarchico.

Identifica correttamente il problema delle regole in conflitto a diversi livelli della gerarchia e della soluzione. O: usa solo liste bianche o nere. O mappare solo il livello più basso

Secondo la mia vista, solo il livello più basso è un errore. L'impostazione sarà un prodotto di un insieme di regole aziendali. Hai affermato che le regole sono cose come "solo X telefoni disponibili in asia", quindi dovrai avere quella regola gerarchica memorizzata da qualche parte e usarla per calcolare l'impostazione di livello più basso. Potresti anche calcolarlo al volo a meno che non sia molto intenso.

Sì, significa che devi seguire l'albero per controllare tutti i livelli, ma sul lato positivo hai meno regole da mantenere.

Sul lato negativo però le regole sono più complicate da spiegare agli addetti alle vendite.

Si desidera inserire le informazioni ridondanti e ogni livello sostituisce i valori del relativo genitore. Creerei quattro tavoli, chiamiamoli Regione, Paese, Magazzino e Negozio. E tre viste con un join esterno su ogni due tabelle Region-Country, Country-Warehouse e Warehouse-Store. Ad ogni vista i valori del livello figlio, se presenti, sostituiscono i valori del livello genitore.

In questo modo puoi leggere le informazioni a livello di Regione, Paese, Magazzino o Negozio.

Scrivi nelle tabelle inserendo solo le informazioni richieste con ridondanza minima e leggi dalle viste.

Lo stesso potrebbe essere ottenuto con un singolo tavolo unito a se stesso, ma penso che sarebbe molto più difficile capire i lavori interiori.

CREATE TABLE Region (
    Region VARCHAR(50) NOT NULL,
    Model VARCHAR(100) NOT NULL,
    OnSale SMALLINT NOT NULL,
    Name VARCHAR(100) NOT NULL,
    Price DECIMAL(18, 2) NULL,
    Attribute VARCHAR(100) NULL,
    CONSTRAINT PK_Region PRIMARY KEY (Region,Model)
)

CREATE TABLE Country (
    Region VARCHAR(50) NOT NULL,
    Country VARCHAR(50) NOT NULL,
    OnSale SMALLINT NOT NULL,
    Model VARCHAR(100) NOT NULL,
    Name VARCHAR(100) NULL,
    Price DECIMAL(18, 2) NULL,
    Attribute VARCHAR(100) NULL,
    CONSTRAINT PK_Country PRIMARY KEY (Region,Country,Model),
    CONSTRAINT F1_Country FOREIGN KEY (Region,Model) REFERENCES Region(Region,Model)
)

CREATE TABLE Warehouse (
    Region VARCHAR(50) NOT NULL,
    Country VARCHAR(50) NOT NULL,
    Warehouse VARCHAR(50) NOT NULL,
    OnSale SMALLINT NOT NULL,
    Model VARCHAR(100) NOT NULL,
    Name VARCHAR(100) NULL,
    Price DECIMAL(18, 2) NULL,
    Attribute VARCHAR(100) NULL,
    CONSTRAINT PK_Warehouse PRIMARY KEY (Region,Country,Warehouse,Model),
    CONSTRAINT F1_Warehouse FOREIGN KEY (Region,Country,Model) REFERENCES Country(Region,Country,Model)
)

CREATE TABLE Store (
    Region VARCHAR(50) NOT NULL,
    Country VARCHAR(50) NOT NULL,
    Warehouse VARCHAR(50) NOT NULL,
    OnSale SMALLINT NOT NULL,
    Store VARCHAR(50) NOT NULL,
    Model VARCHAR(100) NOT NULL,
    Name VARCHAR(100) NOT NULL,
    Price DECIMAL(18, 2) NULL,
    Attribute VARCHAR(100) NULL,
    CONSTRAINT PK_Store PRIMARY KEY (Region,Country,Warehouse,Store,Model),
    CONSTRAINT F1_Store FOREIGN KEY (Region,Country,Warehouse,Model) REFERENCES Country(Region,Country,Warehouse,Model)
)

CREATE VIEW CountryModels AS
SELECT R.Region,C.Country,R.Model,ISNULL(C.OnSale,R.OnSale) AS OnSale,ISNULL(C.Name,R.Name) AS Name,ISNULL(C.Price,R.Price) AS Price ,ISNULL(C.Attribute,R.Attribute) AS Attribute FROM Region R LEFT OUTER JOIN Country C ON R.Region=C.Region AND R.Model=C.Model

CREATE VIEW WarehouseModels AS
SELECT C.Region,C.Country,W.Warehouse,ISNULL(W.OnSale,C.OnSale) AS OnSale,C.Model,ISNULL(W.Name,C.Name) AS Name,ISNULL(W.Price,C.Price) AS Price ,ISNULL(W.Attribute,C.Attribute) AS Attribute FROM CountryModels C LEFT OUTER JOIN Warehouse W ON W.Region=C.Region AND W.Country=C.Country AND W.Model=C.Model

CREATE VIEW StoreModels AS
SELECT W.Region,W.Country,W.Warehouse,S.Store,ISNULL(S.OnSale,W.OnSale) AS OnSale,W.Model,ISNULL(S.Name,W.Name) AS Name,ISNULL(S.Price,W.Price) AS Price ,ISNULL(S.Attribute,W.Attribute) AS Attribute FROM WarehouseModels S LEFT OUTER JOIN Store W ON S.Region=W.Region AND S.Country=W.Country AND S.Warehouse=W.Warehouse AND S.Model=W.Model