Schema DB, pareri e consigli

di
WinstonSmith
il
4 risposte
W
WinstonSmith
Utente Attivo
Iscritto da
gen, 2019
Messaggi:
114

Schema DB, pareri e consigli

Salve,
-vista la mia scarsa conoscenza- mi sto esercitando con i database relazionali e vorrei una vostra opinione.

Traccia:
Una enoteca mette in vendita i propri prodotti (etichetta, prezzo, disponibilità) online.
ogni utente/acquirente dovrà avere un username (nella tabella non dovranno esserci due username uguali) ed una password.
Ad Ogni utente sarà associato un carrello.

Query:
- prezzo totale dei prodotti nel carrello di un utente

Ho pensato:
Tab prodotto (idProdottoPK, etichetta, prezzo, disponibilità)
Tab utente (username unique Pk, password)
Tab carrello (idcarrello, FK usernameUtente)
Tab di associazione prodottiNelCarrello (id, idProdottoFk, idcarrelloFk)

Quindi 1-1 tra utente e carrello, N-M tra prodotto e carrello (quindi ecco la tab di associazione)

Per le query... parto dalla tab prodottiNelCarrello faccio una join con prodotto andando a sommare (sum) i valori di prezzo dove idProdottoFk = idProdottoPK... più o meno corretta?

grazie mille.

4 Risposte

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

    Re: Schema DB, pareri e consigli

    Il Prezzo non è strettamente legato al Prodotto perché può variare nel tempo. Direi di metterlo nella tabella AssociazioneProdottiNeiCarrelli (abituati a nominare le tabelle sempre al plurale).
    In quest'ultima tabella ci vedo anche un campo Quantità. Di conseguenza elimini il campo Disponibilità da Prodotti.
    Per tutto il resto "a grandi linee" ci siamo...almeno a livello di esercizio. Considera che la relazione uno-a-uno nel 99% dei casi viene rigettata dai programmatori che preferiscono inglobare tutti i campi in unica tabella, nel tuo caso Utenti.
  • M
    migliorabile
    Super Famoso
    Iscritto da
    apr, 2013
    Messaggi:
    6072

    Re: Schema DB, pareri e consigli

    Naa! Quasi!

    Tab prodotti (idProdottoPK, etichetta, prezzo, disponibilità)
    Tab utenti (idUserPK, username, password)
    Tab carrelli (idCarrelloPK, idUserFK, idProdottoFK, quantita)

    SE lo stesso utente puo' avere piu' carrelli, altrimenti

    Tab carrelli (idUserFK, idProdottoFK, quantita)

    SE un utente puo' avere un solo carello alla volta.



    @Osvaldo, a questo livello (esercizio) prevedere prezzi diversi per lo stesso prodotto e' una complicazione non necessaria. Si puo' fare, ovviamente, MA si incasina non poco la modellazione, perche' bisogna prevedere anche un range di date di validita' del prezzo, che cosa succede se uno aggiunge un prodotto gia' esistente nel carrello ma con un prezzo diverso, ecc.
    Insomma, un 'casino'

    Pero' perche' vuoi togliere il campo disponibilita'? Puo' essere utile per modellare il fatto che l'enbesimo marinaio ubriacone non puo' ordinare 99 bottiglie di birra, quando un'intera ciurma di ubriaconi se ne sono gia' scolate quasi tutte

    Per la storia del 99% dei programmatori ci andrei cauto. Il 99% di quelli che si SPACCIANO per programnatori, ma che non sanno programmare! E non conoscono la teoria relazionale dei dati!
  • O
    OsvaldoLaviosa
    Super Famoso
    Iscritto da
    apr, 2012
    Messaggi:
    7499

    Re: Schema DB, pareri e consigli

    migliorabile ha scritto:

    @Osvaldo, a questo livello (esercizio) prevedere prezzi diversi per lo stesso prodotto e' una complicazione non necessaria. Si puo' fare, ovviamente, MA si incasina non poco la modellazione, perche' bisogna prevedere anche un range di date di validita' del prezzo, che cosa succede se uno aggiunge un prodotto gia' esistente nel carrello ma con un prezzo diverso, ecc.
    Insomma, un 'casino'
    D'accordo.

    migliorabile ha scritto:

    Pero' perche' vuoi togliere il campo disponibilita'? Puo' essere utile per modellare il fatto che l'enbesimo marinaio ubriacone non puo' ordinare 99 bottiglie di birra, quando un'intera ciurma di ubriaconi se ne sono gia' scolate quasi tutte
    Per me la Disponibilità sarà solo la Quantità risultante di Entrate e Uscite di Prodotti. Se lo vuoi gestire da campo di tabella...si rischia di manometterne il valore in continuazione...boh...non so se ho capito la tua osservazione.

    OsvaldoLaviosa ha scritto:

    Considera che la relazione uno-a-uno nel 99% dei casi viene rigettata dai programmatori che preferiscono inglobare tutti i campi in unica tabella

    migliorabile ha scritto:

    Per la storia del 99% dei programmatori ci andrei cauto. Il 99% di quelli che si SPACCIANO per programnatori, ma che non sanno programmare! E non conoscono la teoria relazionale dei dati!
    Ti dirò, per me si tratta di una "dottrina" ereditata dal mago @Alex...alla quale mi adeguo volentieri...poi non so...
  • W
    WinstonSmith
    Utente Attivo
    Iscritto da
    gen, 2019
    Messaggi:
    114

    Re: Schema DB, pareri e consigli

    Grazie ad entrambi, mi fa piacere non esserci andato troppo lontano
    comunque si, in effetti per il mio bassissimo livello meglio non complicarlo ulteriormente..
Devi accedere o registrarti per scrivere nel forum
4 risposte