Ottieni informazioni dal database o crea informazioni dedotte?

5

Ha più senso archiviare e recuperare proprietà o informazioni direttamente correlate a un elemento in un database o, in tal caso, dire che l'ID di un prodotto può descrivere informazioni su di esso, nel caso in cui le informazioni vengano raccolte da tale? / p>

Esempio: articolo SKU - 4HBU12

4 - è il numero di motori
H - la tensione
B - il colore, il blu U - il modello
12 - la lunghezza

Devo memorizzare i singoli attributi e la SKU, o dovrei memorizzare solo la SKU e creare gli attributi da essa?

    
posta Nathan Lutterman 21.10.2013 - 19:50
fonte

4 risposte

17

Sarebbe meglio memorizzare i singoli attributi del prodotto e memorizzare anche l'SKU.

Ciò al fine di consentire una maggiore flessibilità nel modo in cui si progettano i propri attributi e di consentire all'utente di interrogare prodotti specifici in modo più efficiente tramite SQL. Se si basa sullo SKU per ricavare gli attributi dei prodotti, sarà davvero difficile scrivere select * from item where voltage = 'H' .

Mentre si potrebbe obiettare che si può semplicemente fare una query con caratteri jolly per effettuare la ricerca, questo rende difficile estendere il database in futuro. Ad esempio, dopo un anno o due, ora devi utilizzare due caratteri per il tuo attributo di voltaggio anziché uno, in effetti tutte le query create con una query con caratteri jolly come questa select * from product where SKU like '_H__%' non ti daranno sempre il risultato giusto.

    
risposta data 21.10.2013 - 20:08
fonte
4

Mettendo da parte i rapporti.

Memorizza i singoli attributi ... Ecco perché, Cosa succede se viene commesso un errore?

Supponiamo di fabbricare 5000 unità nere e di accorgersi che sono state fatte accidentalmente rosse? Che cosa fai?

Potresti avere pre-ordini e ricevere la cronologia e questa SKU può esistere su 100 tabelle nel sistema prima che te ne accorga. Anche se è possibile cambiare la SKU in tutto il sistema, che dire di tutte le pratiche burocratiche, come l'ordine di acquisto da parte dei clienti / venditori (potrebbe persino essere stampato sul prodotto stesso!). Come regola generale, una chiave non dovrebbe mai definire attributi. Le convenzioni sui nomi sono grandiose, ma dovrebbe essere solo una convenzione, non una regola applicata al sistema rigido.

    
risposta data 21.10.2013 - 20:17
fonte
2

Due problemi con lo schema di codifica dei dati che riesco a vedere subito sono:

  • Come rappresenti uno nero o uno marrone ora che Blu è usato?
  • Che cosa succede se ora hai bisogno di un 4HBU12 progettato per adattarsi a una Honda e uno per ogni altra marca di veicolo?

In genere cerco di non utilizzare significati speciali negli identificatori per questi e altri motivi.

Tuttavia dipende in qualche modo da cosa intendi fare con il numero. Nella mia esperienza può essere utile per gli utenti essere in grado di 'prevedere' quale sarebbe il numero di un prodotto senza aver bisogno di accedere a un computer. Inoltre, se questi prodotti sono contrassegnati da etichette con il numero di modello, se il numero di modello è l'unico indicatore visibile reale di ciò che è contenuto nella confezione, questo potrebbe supportare nuovamente l'eccezione.

Quindi, mentre evito che gli identificatori abbiano significati nascosti speciali, capisco che, come con la maggior parte delle cose, ci sono delle eccezioni.

    
risposta data 21.10.2013 - 22:52
fonte
2

Suggerirei di prendere in considerazione di archiviare solo lo SKU.

Ho scoperto che qualsiasi configurazione che memorizza entrambe è matura per loro che non sono sincronizzati a lungo termine e i problemi che ne derivano possono essere ambigui.

    
risposta data 23.10.2013 - 05:56
fonte

Leggi altre domande sui tag