Query condizionale.

Buonasera a tutti,

ho la necessità di recuperare dati aggregati partendo dalla selezione di una DataGridView.

Nello specifico la query deve recuperare alcuni dati che possono essere indicati nella tabella come 'default' quando presenti.

Per chiarire meglio pongo un esempio: trattandosi della selezione di un cliente, posso disporre di alcuni controlli di visualizzazione (textbox) dove mostrare la tipologia del contatto (mail, cellulare, fisso, etc.) e il relativo valore (indirizzo, numero); successivamente alla selezione i dati prelevati vanno splittati verso i relativi controlli popolando la scheda cliente.

Se il cliente dispone di un solo contatto questo viene automaticamente impostato come predefinito e mostrato di default.
Se il cliente dispone di più contatti, l'utente ha la possibilità di modificare l'impostazione di visualizzazione selezionandone uno a piacere dalla lista delle disponibilità.

Il problema è che con la query che ho scritto, ovviamente, se non esiste un contatto legato al cliente (o se esiste ma non è stato flaggato come default), anche il resto dei dati non viene prelevato.

La query è la seguente:

select customers.name, surname, 
         addresses.id, addresses.address, addresses.streetn, addresses.notes,
         municipalities.name, municipalities.province, municipalities.zipcode, 
         contacts.id, contacts.typeid, contacts.description, contacts.notes, contactstypes.description from customers 
                         left join addresses on customers.id = addresses.customerid
                         left join municipalities on addresses.municipalityid = municipalities.id
                         left join contacts on customers.id = contacts.customerid
                         left join contactstypes on contacts.typeid = contactstypes.id
                         where customers.id = <id_cliente> and  addresses.isdefault = 1 and contacts.isdefault = 1;

Chiedo aiuto nel tentativo di far fronte a questa necessità.

Secondo me lasciare che non vi sia un contatto predefinito è un errore.
L'utente può scegliere qual è quello predefinito, ma deve essercene almeno uno.

Probabilmente abbiamo una visione diversa, data dal fatto che nei contatti io includo anche gli indirizzi, mentre vedo che tu tieni separati gli indirizzi dai contatti.
In sostanza io raggruppo tutti i contatti: indirizzi, email, tel, cell, ecc... in una sola tabella (che io chiamo Recapiti) ed in cui ho per ogni tipo di recapito, il relativo default.
Posso avere l'indirizzo della Sede legale, l'indirizzo di spedizione, quello di fatturazione, l'email per le fatture, quella per i DDT, il tel del magazzino, e così via, ognuno con una Descrizione che mi dice a cosa si riferisce quel specifico recapito.

Probabilmente abbiamo una visione diversa, data dal fatto che nei contatti io includo anche gli indirizzi, mentre vedo che tu tieni separati gli indirizzi dai contatti.
In sostanza io raggruppo tutti i contatti: indirizzi, email, tel, cell, ecc... in una sola tabella (che io chiamo Recapiti) ed in cui ho per ogni tipo di recapito, il relativo default.

Scusa gibra ma così facendo non violi le regole di normalizzazione?

Quanti campi inutilizzati ti restano con questo approccio?
E quanto overhead prestazionale pesa sulle operazioni?

Questo modo di operare è ampiamente sconsigliato in tutta la letteratura.

Comunque questioni implementative a parte e col massimo rispetto nei tuoi confronti nonché, per quanto possa valere, la mia ammirazione, effettivamente il tuo intervento mi ha fatto comunque riflettere sul fatto che almeno un contatto o ce l'hai o lo richiedi di persona per cui sarebbe cosa buona separare le due logiche di creazione e visualizzazione dei dati cliente.

Il fatto è che se anche volessi eliminare la possibilità di editare i contatti e gli indirizzi dalla scheda di visualizzazione, avrei comunque un problema: se nella scheda di creazione e gestione cliente accidentalmente si dovesse eliminare proprio il contatto indicato come default io, con quella query, non riuscirei a recuperare più neanche le restanti informazioni.

Dovrò gestire la cosa dalla scheda di creazione/gestione cliente in modo che almeno un contatto per cliente sia sempre presente e che sia impossibile procedere all'eliminazione dello stesso qualora ve ne sia soltanto uno.

Ti ringrazio per aver contribuito.

P.S.: E se per l'utente non fosse necessario avere l'indirizzo? Credi debba prevedere un valore di default tipo <N/A>?

Scusa, ma non capisco cosa intendi.
Per me non esiste che un soggetto (sia esso cliente, fornitore, vettore, agente, altro...) NON ABBIA almeno un recapito.
Non avrebbe alcun senso.
Ma probabilmente ciò dimostra che abbiamo una diversa visione nella gestione dei dati, quindi non posso aiutarti.

P.S.
Non mi interessa aprire una diatriba sulla normalizzazione, che non c'entra nulla, e secondo me hai capito l'8 per il 18.

No, no... per carità. Nessuna diatriba.

E' ovvio che il recapito debba esistere in un modo o nell'altro.

Mi spiego meglio: per come avevo impostato la gestione del cliente, potevo selezionarne uno ed eventualmente operare sulle informazioni a lui correlate.

E' successo che, avendo selezionato un nominativo per il quale non avevo ancora inserito i valori relativi ai contatti, mi sono accorto che la query veniva eseguita correttamente ma non restituiva niente per via delle clausole associate alla where.

Da qui è nato il problema che io ho esposto in merito alla questione del contatto ma, poiché anche l'indirizzo risponde agli stessi criteri di selezione, mi sono posto il problema del recupero di un insieme di informazioni con siffatta query legate ad un eventuale dato (ancora) non presente o cancellato per errore.

La domanda è nata perché ho pensato a situazioni tipo call center dove magari (e in via ipotetica) ad un nominativo potrebbe essere associato un numero di telefono ma non ancora l'indirizzo.

Grazie al tuo intervento ho potuto rivalutare la mia idea e trovare la soluzione, l'8 e pure il 18!