Likes Likes:  0
Risultati da 1 a 9 di 9

Discussione: help phpmyadmin-sql relazioni uno a uno

  1. #1
    Scandinavian LAG L'avatar di Seven986
    Registrato il
    Oct 2008
    Località
    Roma
    Posts
    957
    Likes (Given)
    671
    Likes (Received)
    480

    Predefinito help phpmyadmin-sql relazioni uno a uno

    C'è qualcuno che sa usare discretamente phpmyadmin-sql e mi spiegherebbe come implementare una relazione uno a uno tra due entità?

  2. #2
    Fish
    Registrato il
    Feb 2010
    Posts
    7
    Likes (Given)
    0
    Likes (Received)
    0

    Predefinito

    Crea la FK dell'entità 1 che punta alla PK dell'entità 2
    Tramite phpmyadmin devi farlo creando l'indice

  3. #3
    Scandinavian LAG L'avatar di Seven986
    Registrato il
    Oct 2008
    Località
    Roma
    Posts
    957
    Likes (Given)
    671
    Likes (Received)
    480

    Predefinito

    è uno a molti così

  4. #4
    Antonius L'avatar di loziobiz
    Registrato il
    Dec 2007
    Località
    in a grindhouse
    Posts
    2,329
    Likes (Given)
    0
    Likes (Received)
    2

    Predefinito

    Citazione Originariamente Scritto da Seven986 Visualizza Messaggio
    è uno a molti così
    no, il fatto è che in mysql le 1-a-1 in realtà non esistono nativamente e quindi devi usare questo espediente.

    qui trovi in esempio
    "per te deve contare solo l'EV. non te ne deve fregare un cazzo di rannare bene o male l'importnte deve essere fare mosse +EV" (cit. sgamble)

    "Magliagialla nn so chi sei e nn mi interessa." (cit. rammstein3)

  5. #5
    Antonius L'avatar di 5om3on3
    Registrato il
    Oct 2009
    Località
    Alba
    Posts
    2,882
    Likes (Given)
    2163
    Likes (Received)
    2584

    Predefinito

    Ma non è meglio creare un'entità unica piuttosto che una rel 1:1?

  6. #6
    Calling Station
    Registrato il
    Nov 2009
    Posts
    129
    Likes (Given)
    0
    Likes (Received)
    0

    Predefinito

    Citazione Originariamente Scritto da 5om3on3 Visualizza Messaggio
    Ma non è meglio creare un'entità unica piuttosto che una rel 1:1?
    Non sempre.
    Posso voler splittare le info su due tabelle A e B in relazione 1:1 per più di qualche motivo, ad esempio:

    1) la relazione è di tipo supertype/subtype, dove oltre a B ci sono anche tabelle C, D etc. ognuna in relazione 1:1 con A, dove però una riga di A ha un "tipo" e quindi ha bisogno di estendersi di volta in volta su una sola della altre in funzione del valore del campo "tipo". (Classico esempio: Persona -> Cliente, Venditore, Fornitore)

    2) la relazione è in realtà una 0..1:1, quindi non tutte le righe di A necessitano di una corrispondente "estensione" su B, anzi magari solo un piccolo sottoinsieme di esse. In questo caso aggiungere tutti i campi di B direttamente ad A è uno spreco di spazio su disco, memoria, cpu e banda, dato che su moltissime righe di A questi campi rimarrebbero sempre null. E' in pratica un caso particolare della precedente, con la differenza che per molte righe di A la tabella B non serve proprio a nulla e non c'è nemmeno in generale bisogno di un campo "tipo".

    3) le info su B posso volerle caricare separatamente solo quando occorrono perché es. sono molto estese (blob etc.)

    4) A e B stanno su schema/database diversi per avere permessi/policies di backup diverse tra le 2 tabelle es. in considerazione della size e della frequenza di aggiornamento dei rispettivi campi di A e B

    5) e probabilmente molti altri motivi che alle 2 del mattino non mi vengono in mente

  7. #7
    Scandinavian LAG L'avatar di Seven986
    Registrato il
    Oct 2008
    Località
    Roma
    Posts
    957
    Likes (Given)
    671
    Likes (Received)
    480

    Predefinito

    allora devo fare un e-commerce.
    il problema in breve sarebbe il carrello che dovrebbe funzionare come tutti i siti web, cioè metti gli oggetti nel carrello, poi quando effettui l'acquisto viene svuotato e diventa una vendita. Non posso usare la stessa entità in quanto ad ogni vendita corrisponde una fattura e una bolla per la spedizione, e ho racchiuso queste ultime 2 nell'entità vendita. Il problema è che finche non confermi l'acquisto degli oggetti non posso avere la fattura, quindi mi serve appunto il carrello.
    che ne dite se implemento il carrello con la view?
    dovrebbe funzionare bene?
    non so se sono stato molto chiaro.

  8. #8
    Antonius L'avatar di 5om3on3
    Registrato il
    Oct 2009
    Località
    Alba
    Posts
    2,882
    Likes (Given)
    2163
    Likes (Received)
    2584

    Predefinito

    Citazione Originariamente Scritto da algernon Visualizza Messaggio
    cut
    ty

  9. #9
    Calling Station
    Registrato il
    Nov 2009
    Posts
    129
    Likes (Given)
    0
    Likes (Received)
    0

    Predefinito

    Citazione Originariamente Scritto da Seven986 Visualizza Messaggio
    allora devo fare un e-commerce.
    il problema in breve sarebbe il carrello che dovrebbe funzionare come tutti i siti web, cioè metti gli oggetti nel carrello, poi quando effettui l'acquisto viene svuotato e diventa una vendita. Non posso usare la stessa entità in quanto ad ogni vendita corrisponde una fattura e una bolla per la spedizione, e ho racchiuso queste ultime 2 nell'entità vendita. Il problema è che finche non confermi l'acquisto degli oggetti non posso avere la fattura, quindi mi serve appunto il carrello.
    che ne dite se implemento il carrello con la view?
    dovrebbe funzionare bene?
    non so se sono stato molto chiaro.

    manca qualche info, perché la gestione del carrello in un e-shop è molto dipendente dalle specifiche dell'applicativo e dalle funzionalità del middle-tier su cui lavori. Ci sono molti modi di approcciare la cosa.

    In generale, tu per gli ordini effettuati hai una struttura User <--- Order <--- OrderItem che sono tutte relazioni 1:N.

    Se tu prevedi che anche un utente non loggato possa riempire un carrello, e poi loggarsi/registrarsi solo al momento del checkout (= acquisto, credo sia il caso + comune), devi impostare la relazione User-Order in modo da consentire la creazione di un ordine senza utente associato, e l'utente anonimo in qualche modo lo devi cmq identificare se vuoi recuperare il suo carrello.

    Inoltre puoi gestire il carrello in più modi, es. come un ordine con un flag che indichi se è stato effettivamente inviato o meno lavorando quindi sempre sulle stesse tabelle; e qui puoi andare di view, se ti conviene, così fai anche sparire i campi che non si applicano all'item quando sta ancora nel carrello. Occhio che le view siano updatabili, però

    Oppure si può anche usare come carrello una tabella temporanea (per sessione) che contenga solo (Id_Prodotto, Quantita, Prezzo) e copiandone le righe su quelle "ufficiali" - con generazione di un ordine vero e proprio - solo in caso di acquisto. In questo caso sorge il problema di sincronizzare la sessione utente con quella del database - e lì dipende dal framework e dal DB, col vantaggio però che a fine sessione il carrello sparisce da solo e non va ripulito.

    Viceversa, se implementi il tutto con una tabella "normale" devi ripulirla manualmente quando una sessione utente finisce, perché a nessuno interessa avere nel database vecchi carrelli creati da omino 2 anni fa e mai ordinati
    Questo nella pratica può essere un po' complesso da fare.

    A me piace di più l'idea della tabella separata per il carrello perché più pulita, tutte le FK in User <--- Order <--- OrderItem possono essere rese obbligatorie così come altri campi senza doverli dichiarare nullable giusto per supportare casi particolari e poi magari dover aggiungere i controlli da trigger o da codice. Però non so, boh, è oppo dependent


    (oh cazzo ho scritto un papiro sry. ma magari tra di voi c'è qualche studente di informatica a cui interessa sta roba )

Informazioni Discussione

Utenti che Stanno Visualizzando Questa Discussione

Ci sono attualmente 1 utenti che stanno visualizzando questa discussione. (0 utenti e 1 ospiti)

Segnalibri

Permessi di Scrittura

  • Tu non puoi inviare nuove discussioni
  • Tu non puoi inviare risposte
  • Tu non puoi inviare allegati
  • Tu non puoi modificare i tuoi messaggi
  •