DB Parrucchiere

di
Anonimizzato20368
il
4 risposte
/
Anonimizzato20368
Utente anonimizzato

DB Parrucchiere

Salve a tutti
purtroppo non ho dato retta a tutti voi all'inizio della mia iscrizione, e mi sono buttato a pesce nel creare un db
senza studiare le relazioni tra tabelle...
Il mio problema è questo:

Ho un cliente , che in una certa data, deve fare dei servizi e comprare dei prodotti.

Ho provato a creare la tabella CLIENTI,DATA,SERVIZI,PRODOTTI:

RELAZIONE CLIENTI 1-MOLTI VERSO DATA
RELAZIONE DATA 1-MOLTI VERSO SERVIZI
RELAZIONE DATA 1-MOLTI VERSO PRODOTTI

Creo la maschera in base ai clienti, ma non funziona, la vedo in struttura ma non in maschera.

che sto combinando??
Grazie
Ale
Allegati:
20368_d1284244042c1d2be3c6148f2e50dc5b.jpg
20368_d1284244042c1d2be3c6148f2e50dc5b.jpg

20368_60a11bf264e129caa448e6ae8304328b.jpg
20368_60a11bf264e129caa448e6ae8304328b.jpg

20368_028b1293f3e8bb701f29a9ad862bf90c.jpg
20368_028b1293f3e8bb701f29a9ad862bf90c.jpg

4 Risposte

  • O
    OsvaldoLaviosa
    Super Famoso
    Iscritto da
    apr, 2012
    Messaggi:
    7539

    Re: DB Parrucchiere

    1. Servizi e Prodotti possono diventare una tabella unica...non so la chiamerei Oggetti. Per distinguere se si tratta di un Prodotto o Servizio aggiungi un campo di discriminazione, magari una casella combinata, dove specifichi ciò.
    2. Risolto il punto 1. la tabella di congiunzione dovrebbe avere un solo campo IDOggetto e la relazione dovrebbe essere Oggetti.IDOggetto uno-a-molti Cassa.IDOggetto.
  • /
    Anonimizzato11767
    Utente anonimizzato

    Re: DB Parrucchiere

    Sono d'accordo con Osvaldo, ma più che Oggetti, direi che è più corretto Articoli.
  • /
    Anonimizzato20368
    Utente anonimizzato

    Re: DB Parrucchiere

    Grazie !!
    ho seguito il vostro consiglio, ho accorpato servizi e prodotti, e pare che va bene !

    Alex
  • +
    +m2+
    Utente Famoso
    Iscritto da
    mag, 2017
    Messaggi:
    3548

    Re: DB Parrucchiere

    Elemento di teoria: se parliamo di design banale (come in questo caso) sei incappato nel problema del collasso verso l'alto, o verso il basso.
    La soluzione proposta è detta collasso verso l'alto, con introduzione di selettore (i figli nei padri).
    Quello che invece avevi abbozzato è il c.d. collasso verso il basso, con il mantenimento delle gerarchie, dove la selezione è fatta esternamente proprio dall'associazione.

    La scelta tra le due forme dipende da tanti fattori: nel tuo caso, essendo sostanzialmente identiche, il collasso verso l'alto non dà effetti collaterali, se non una possibile riduzione delle prestazioni per le ricerche con match singolo.

    Se invece avessi avuto (come capita normalmente) attributi molto diversi, avresti avuto tanti campi possibilmente NULL (a seguito del collasso).
    Supponi, ad esempio, che i PRODOTTI abbiano un certo sconto, mentre i SERVIZI non ce l'abbiano mai.
    Avresti aggiunto un campo popolato (per i PRODOTTI), ma NULL (per i servizi)

    Poi partirebbe lo spiegone sulle diversità dovute allo sharding orizzontale (e parzialmente anche verticale, vedi osservazione precedente) nelle prestazioni, e magari anche la verifica della copertura (del collasso verso l'alto, verso il basso è automatico).

    ... insomma... cribbio... ma non si insegna più niente?
Devi accedere o registrarti per scrivere nel forum
4 risposte