Progettazione del database MySQL - Opinioni

• I nomi delle entità devono essere singolari ( client , purchase , ecc. non clients , purchases , ecc.)

• La relazione da purchase_article a purchase dovrebbe essere da uno a molti (essendo purchase da un lato)

• La relazione da purchase_article a article dovrebbe essere da uno a molti (essendo article da un lato)
• La relazione da provider_article a article dovrebbe essere da uno a molti (essendo article da un lato)
• La relazione da provider_article a provider dovrebbe essere da uno a molti (essendo il fornitore da un lato)
• provider_article Pk dovrebbe essere (idProvider, idArticle) , se insisti sull'utilizzo di un surrogato assicurati di creare un vincolo univoco su (idProvider, idArticle)
• Qual è la differenza tra Phone e Telephone ? Mi sembra violare 1FN per me
• Qual è la differenza tra unitPrice e Price ?
• Sei sicuro che la relazione tra Purchase e Account non sia invertita?
• Se insisti per avere un PK surrogato su client , provider , ecc., assicurati di creare un vincolo univoco sulla chiave aziendale per evitare duplicati.

Non vorrei commentare dettagli minori che puoi correggere in seguito. Ci sono diversi problemi strutturali qui:

1. Perché hai un PurchaseUnitPrice in Purchase ? Questo dovrebbe essere su purchaseArticle
2. Allo stesso modo, perché hai un PurchaseQuantity in Purchase ? Questo dovrebbe essere anche su purchaseArticle
3. Qualche cosa mi dice che UnitPrice è il prezzo che hai ottenuto dal fornitore e price è il prezzo che vendi. Se ciò è vero, NON inserire article profit , se vuoi un argomento, possiamo parlare ulteriormente per spiegare
4. Lo stato di acquisto non dovrebbe essere un valore booleano. Potresti voler avere più opzioni in seguito, come "non pagato", "pagamento parziale", "reso", ecc.
5. Presumo che tu abbia una tabella providerArticle perché un article potrebbe provenire da diversi fornitori. In questo modo, assicurati che PurchaseArticle abbia una relazione con ProviderArticle non Article perché desideri conoscere il provider esatto che fornisce l'articolo che hai appena venduto. Se la mia ipotesi non è vera, è sufficiente creare una relazione molti-a-molti tra article e provider
6. Account dovrebbe avere una relazione uno-a-uno con Client' not with Acquista '
7. Se vuoi davvero tenere traccia dei pagamenti di ciascun acquisto, inserisci una relazione uno-a-molti da Purchase a Payment (una nuova entità tabella)

Penso che tu debba fare un po 'più di analisi su come il tempo influisce sul tuo modello.

• Un'offerta di vendita è al prezzo corrente
• Un articolo (o gruppo di articoli) viene venduto ad un prezzo particolare che non cambierà mai.
• Sembra che tu stia procedendo nella giusta direzione con il prezzo totale nella tabella degli acquisti, ma poi i link di acquisti_articoli a una tabella che ha campi di prezzo e profitto che potrebbero non essere più pertinenti.

Quello che sto evidenziando è che è necessario copiare i campi in tabelle "logging", anche se questo sembra denormalizzazione. La teoria classica della modellazione dei dati tende a ignorare questa realtà sconveniente.

Potresti usare le due chiavi esterne come primario combinato negli articoli dei fornitori. Questo per assicurarti di avere solo uno di ciascun articolo del fornitore. Altrimenti potresti ottenere duplicati con un ID diverso. E prova a usare gli ID leggibili (come gli indirizzi email). Oltre a questo non vedo nulla oltre alla cosa decimale-float.