Consulenza architettonica SQL relativa allo schema (overcomplex?)

Question

Attualmente sono nella fase di progettazione del database per lo sviluppo di una nuova sezione del nostro prodotto. Per il quale ho bisogno di avere un "controllo di integrità" o qualche consiglio perché non mi sento eccessivamente fiducioso su alcune parti del setup.

Un po 'di sfondo informazioni

Il prodotto che stiamo sviluppando è un cosiddetto "sistema ROI massimizzazione del marketing". Gestisce i big data e elabora/migliora/arricchisce una grande quantità di informazioni prima di inviarle a diversi canali di marketing. Questo è fondamentalmente quello che fa in poche parole.

Il problema del dominio

Il sistema attualmente non dispone pienamente buona validazione dei dati e viene "abusata" su base giornaliera dal "marketing" le persone e ciò che noi chiamiamo clienti "self-service". Con la nuova rete di annunci con scheda di prodotto di google in mente del nostro CEO, mi è stato dato il compito di trovare una buona soluzione su come gestire {informazioni/dati} da utilizzare nel canale di acquisti di google (chiamalo PLA; elenco prodotti Annunci).

Questo è il problema:
nostro prodotto non offre alcuna forma di convalida (leggi: aderire alla rete specifiche esigenze) e PLA sostanzialmente completamente ruota attorno integrità dei dati dai mezzi di classificazione delle voci (ciascuna la categoria ha definito i campi obbligatori/facoltativi) e ogni campo può o dovrebbe essere in un formato specifico (potrebbe anche dipendere dalla categoria collegata, non lo so ancora: P).

Immagina, siamo un po 'fregati con l'attuale configurazione. Non è possibile applicare questi tipi di feed di prodotto "rigorosi". Lasciare che i nostri addetti al marketing e i clienti self-service creino e inviino dati a PLA significherà risolvere problemi e risolvere i problemi il 99% delle volte. E poiché è solo una piccola azienda, preferirei guardare al vero problema. Questo significa; cercando di creare un vero sistema di validazione che possa essere utilizzato per le campagne di marketing del PLA.

Che cosa deve essere fatto

Ho parlato al nostro popolo di marketing e clienti per sapere quali sono i casi d'uso sono e quali sarebbero i requisiti. Questi possono essere riassunti nei seguenti voci di elenco:

• Ogni elemento del feed di ingresso deve essere mappato "categorisized" per una categoria di google PLA (vedere "collegamenti" sezione per vedere quali categorie possono essere mappati.
• convalida deve essere configurato per campo per "categoria"
• Ogni campo per ciascun elemento deve allocato/mappato a un campo definito nella categoria selezionata.

informazioni aggiuntive lato

Ora, non voglio preoccuparmi di cose come "Come collegheremo" elementi "a" categoria "o" campi "a" definizioni di campi categoria "o qualcosa del genere. Queste "cose ​​dinamiche" saranno gestite da un sistema di regole ECA, che sarà sviluppato in un altro momento. (perché chiedi? Il sistema sta gestendo/elaborando i dati su una base pianificata in modo che ogni operazione debba essere definita e archiviata per un uso successivo), per ora non preoccuparti dei dettagli di implementazione.

Inoltre, l'implementazione concreta specifica viene spesso realizzata mediante l'uso di attributi dinamici (ad esempio, gli attributi su un campo definito dal tipo di dati, ecc.). Anche un sistema EAV non è il mio obiettivo principale in questo momento.(il caso d'uso sopra riportato avrà più senso se dai un'occhiata al design del database).

Il mio progetto attuale

In primo luogo, mi permetta di spiegare la mia struttura SQL utilizzando le principali entità:

• schemas; un modo astratto di definire "categorie", pensare ad una categoria PLA
• fields; definizioni dei campi (in un schema)
• datatypes; un sacco di tipi. (utilizzato principalmente per dare all'integrità dei dati campi sopra)
• valueConstraints; un sacco di definizioni di vincoli (non l'implementazione!).

Ora. È tutto buono e dandy finora. Ecco la cosa Sono un po 'preoccupato:

valueConstraints sono tenuti a un tipo di dati per mezzo di un N: tavolo M (datatype_valueConstraints) ma quasi ogni tipo di dati generati dagli utenti è costituita da solo un sottoinsieme delle valueconstraints disponibili, non ha senso avere un tipo di dati "Price" che può avere un vincolo "Email". Tuttavia, ha senso avere un vincolo "Min" e "Max", visto che un prezzo è sempre un numero. Per chiarezza: datatype_valueConstraints è in possesso del "possibile" valueConstraints per tipo di dati.

Lo stesso problema si verifica con primitiveType -> constraintValue relations. Fondamentalmente un tipo di dati deve includere un "primitiveType" (nel mio caso una chiave esterna per la tabella dei tipi primitivi). Un tipo primitivo gestisce lo valueConstraints da cui selezionare. primitiveTypes e valueConstraints non sono considerati generati dall'utente, quindi per ora sono dati di installazione.

Non capisco? Ecco un esempio del flusso di lavoro (() un'installazione parziale per lo schema "PLA/abbigliamento"):

• Aggiungi tipo di dati "immagine", impostare {tipo primitivo di TESTO}
  • selezionare i seguenti ValueConstraints da utilizzare (TESTO specifico)
    • "URL" (assicurarsi che sia http | https o qualcosa di simile, non lo so)
    • "minLength" (assicurarsi che sia lì)
    • "Regex" (consentire certo Extensio immagine ns .. o qualcosa di simile)
• Aggiungi definizione di campo "imageURL", impostare {tipo di dati per "immagine"}
  • configurazione specifica tipo di dati, vale a dire la compilazione di dati affermazione di vincolo (modello EAV relazionato). "MinLength" = 14, "Regex" = "* (gif | jpg | png)" eccetera.

Perché il tipo di dati è stata di "TEXT" primitiva l'utente può selezionare da solo "TESTO" -concerning (ed ereditato a causa di albero come sistema datatyping) valueConstraints.

Una volta che il tipo di dati è stato configurato correttamente, possiamo usare il tipo di dati "immagine" per più campi nello schema (se vorremmo). Per esempio; uno schema "PLA/CLOTHING" potrebbe richiedere un campo "immagine aggiuntiva". Questo è ora perfettamente possibile riutilizzando il tipo di dati "immagine" con forse una diversa configurazione di vincoli.

Uno SQL layout visivo tabella che mostra le relazioni (onde cerebrali per quanto riguarda sopra muro di testo):

mio schema DB: (clicca per ingrandire)

TLDR;

Vedere "Il mio attuale design" e darmi la vostra opinione. Penso che potrebbe essere eccessivamente complesso/non ben pensato e in cerca di miglioramenti. Nota: non sono un DBA, solo uno sviluppatore. (Inoltre, non sono sicuro se il disegno dello schema avrà senso se non avete letto "Il dominio problema": P)

link

• Product Listing Ads
• Summary of attribute requirements

Non vedo davvero l'ora di vedere cosa ne pensate voi ragazzi. Grazie in anticipo!

Answer 1

Solo una questione di preferenze personali: non sono troppo appassionato di relazioni con i genitori all'interno di un tavolo se non sono realmente necessarie. Li vedo per la tabella degli schemi, ma in questo caso ritengo che i tipi primitivi potrebbero trarre vantaggio da uno schema più rigoroso, eliminando il tipo BASIC e aggiungendo i vincoli di base della lunghezza a tutti i primitivi (nessuna impresa del genere, in termini di spazio e velocità). Se hai davvero bisogno di creare un livello extra di tipi primitivi : fallo, ma aggiungi solo una tabella genitore per un solo livello genitore e conforma tutto a questo.

Certo: si manca di flessibilità, ma nella mia esperienza è più facile per aggiungere i dati conformi a questo schema e non ha bisogno di modificare il codice per recuperare le condizioni (e il codice sarà una query semplice) che consentono di livelli illimitati di nidificazione primitivi che non userete o peggio: vi abuserete :)