Come posso modellare la relazione IS-A su un registro, quando si hanno classi di prodotti diverse?

1

Questa è una domanda su come modellare le entità e le relazioni del database quando si tratta di archiviare dati persistenti e trattare con tipi di prodotti gestiti in modo diverso.

Usa caso

L'azienda vende varie percentuali di% di co_de che vengono prodotte all'interno dell'azienda e varie percentuali di Products , che non sono prodotte in azienda e sono trattate in modo diverso.

Ogni prodotto ha un numero di parte individuale specifico, ma i motori non sono l'attività principale dell'azienda e in quanto tali stanno prendendo un sedile posteriore nel senso che, indipendentemente dal tipo di motore venduto, è sempre elencato sotto generico numero di parte di Motors sul libro mastro delle vendite. Questo è anche perché il più delle volte, il motore è una parte "una tantum", solo di passaggio, e spesso deve essere acquistato su misura, e non è tenuto in magazzino permanente.

Allo stesso tempo, quando possibile, è necessario sapere esattamente quale motore viene venduto a fini di inventario e ci sono diversi modi per affrontarlo concettualmente.

  • mantieni la tabella di dati MOTOR separata con i motori dei fornitori tipici
  • sul libro mastro accanto al numero di parte MOTOR, descrivere il motore esatto nella descrizione
  • sposta i Motori nella tabella dei prodotti principali, ma poi deve creare molti numeri di pezzi del motore a perdere a causa di pezzi unici (non desiderabili e non della rotta che voglio percorrere)

Pensieri correnti

Ho un diagramma ER in cui ho definito alcune tabelle, in questo modo:

Tuttiiprodottiprodottidall'aziendaconilpropriospecificonumerodipartesitrovanonellatabellamotor.Ilnumerodipartegenericodi"MOTOR" si trova anche nella tabella product .

Tipici motori di vari fornitori che sono probabilmente ordinati si trovano nella tabella products .

Il problema con il mio approccio è più o meno evidente nella tabella motor . Ho ledger_item e motor_id , rispettivamente discernente prodotto e motore. Se è un product_id , quindi estraggo i dati di product e utilizzo il numero di parte specifico di quel prodotto, che può essere discernuto da product .

Se product_id significa che cercare il motore nella tabella dei motori per scoprire il motore specifico, ho bisogno di leggere product_id == MOTOR e andare nella tabella motor_id per trovare le specifiche.

Per i casi in cui viene aggiunto un motore che non è nella tabella motori (una parte singola), posso solo contare sulle chiavi motor e category_id per dirmi che è un motore, non fare affidamento sulla tabella product_id , quindi leggere la descrizione nel libro mastro.

Questo può essere ... reso migliore? Oppure ho ragione a usare motor come metodo per indicare la relazione di tipo category_id nel libro mastro e poi a scavare nelle chiavi esterne appropriate per le specifiche?

    
posta Dennis 20.09.2016 - 18:29
fonte

3 risposte

1

Relazione IS-A

Non capisco che "sia una" relazione di cui stiamo parlando. Un motore è un prodotto?

Il database non è il posto dove definire queste relazioni, il tuo modello di classe di dominio è. Le tabelle del database possono mappare molto bene questa relazione, ma il database è l'archivio dati, non la definizione della relazione.

Pensare in questo modo è un gateway per mettere le regole aziendali nel database. E lo stai già facendo ...

numero di parte generico di MOTOR sul libro mastro delle vendite

Ovviamente "MOTOR" è antitetico alle tabelle delle relazioni PK / FK necessarie. La tabella "linking", ledger-item, contiene le chiavi del prodotto e del motore, ma poi vai in giro schiacciando "MOTOR" e poi specula sfrenatamente sulla riprogettazione della tabella solo così puoi mettere "MOTOR" su un libro mastro invece di il vero motore. Fallo e combatterai con il design del DB ovunque nella tua applicazione; e avrai query aggiuntive ogni volta che ottieni questi dati particolari (prodotto - libro mastro - motore)

Il modello di classe di dominio è il posto in cui effettuare la sostituzione. È universale e facile. E non abbiamo "MOTOR" per ogni riga sulle tabelle, che è la definizione del bambino poster di archiviazione di dati non normalizzata e inefficiente.

Disaccoppiamento dei requisiti per le palle dispari

Se le considerazioni sulla progettazione ti spingono a mettere "MOTORE" nel database, allora crea una tabella separata. Quindi farei un recupero una tantum per metterlo in un oggetto dominio e fare riferimento a tutto il resto dell'applicazione.

Se questa pazzia del "MOTORE" provoca attrito nel codice allora forse può essere la sua classe. Ma è solo un singolo valore! Bene, questo ti dà un posto dove gettare qualsiasi maneggevolezza eccezionale e regole una tantum per quella cosa. Ed è più facile, più pulito da iniettare o sostituire. Può anche far parte di un'infrastruttura di "business rule" più grande: è solo una delle raccolte di regole applicate nel tuo modello.

    
risposta data 28.09.2016 - 15:02
fonte
1

Per essere onesti, penso che tu stia pensando troppo.

Non otterrai nulla utilizzando il modello proposto sul tuo database - ti ritroverai con più o meno la stessa quantità di dati nel database e aumenterai i costi delle tue query.

In realtà, se il motore è una parte, affrontala come una parte e dimentica quante volte verranno utilizzate. Semplificherai la progettazione del tuo database e il tuo software client, ti renderà più facile espandersi in futuro e sarai anche in grado di addestrare le nuove reclute al Dev Team più velocemente.

Quindi, ecco il mio plagio su questo:

  • Utilizza la tabella Prodotti (usa nomi plurali per tabelle, nomi singoli per classi) per archiviare tutte le "cose vendute", prodotti o motori regolari.
  • Utilizzare il nome generico della parte "MOTORE" per i motori.

La tua soluzione proposta crea altrettanti oggetti "una tantum" che li mettono nella tabella Prodotti. Non capisco perché dici che non è desiderabile, ma guardando a ciò che hai presentato sulla tua domanda sembra il modo migliore per affrontare questo problema.

Non preoccuparti di avere a malapena dati usati nel tuo database - "una tantum". Pensa ai log tables: sono di design pieni di elementi "unici" che saranno presenti se ne hai bisogno, ma altrimenti resterai seduto lì senza fare nulla. Per quanto ne so, non sono davvero un problema per la maggior parte dei sistemi che li usano in modo ragionevole. Le tabelle dei prodotti finiranno sempre per riempire di cose che non userete mai più: le cose vanno fuori linea, non vengono mai più vendute, ecc. Ecc. Davvero, non preoccuparti.

Se sei preoccupato di avere troppi "prodotti" per qualcuno da scegliere, usa la colonna Category per filtrare i motori dalla "combobox del prodotto" iniziale che probabilmente hai da qualche parte nel tuo sistema. Se l'utente vuole vedere i motori, può benissimo filtrarli.

Se non riesci a utilizzare la Colonna categorie per questo, assegna una colonna "Tipo" in più alla tabella del prodotto con alcuni tipi di macro, come "Motori", "Parti in plastica", "Parti metalliche" o qualsiasi altra cosa che abbia senso nel tuo sistema.

    
risposta data 27.12.2016 - 17:10
fonte
0

Ho svalutato le risposte di radar e di TSar. Sono d'accordo con loro.

Ecco un modello proposto:

  • Una categoria 'MOTOR' esiste nella tabella PRODUCT_CATEGORY
  • I motori specifici esistono in PRODUCT insieme ad altri prodotti non motori
  • Il nome LEDGER_ITEM implica che ci dovrebbe essere un'entità LEDGER
  • MOTOR contiene colonne che si adattano solo ai motori, tale relazione è 1: 1, non obbligatoria ed è un FK sul lato MOTOR in attesa di PRODUCT
risposta data 27.03.2017 - 20:08
fonte