Newsgroup: it.comp.software.database
Titolo: [MySQL] mixare due colonne

Ola!,
	ho un problema che mi si ripresenta per l'ennesima volta. Negli altri casi
ho risolto per "vie traverse" stavolta non cavo un ragno da un buco.
Allora ho una tabella community con _ID_, nick, email, e altri dati di
iscritti.
Un'altra tabella in cui chiamata vocabolario in cui c'è una serie di record
fatti così
IDautore, autore, linkImmagine.
In pratica in questa tabella, se l'autore dell'immagine è un iscritto metto
il suo ID, mentre se l'autore non è iscritto (quindi non c'è una sua tupla
nella tabella community), metto IDautore=0 e scrivo in autore il suo nick
(autore è una stringa). Questo mi permette di salvare disegni di iscritti
alla community e di non iscritti. Quando poi vado a visualizzare, se
IDautore=0 stampo autore, altrimenti stampo nick della tabella community
(ovviamente la SQL è + o - SELECT community.ID, community.nick,
vocabolario.IDautore, vocabolario.autore, vocabolario.linkImmagine FROM
vocabolario LEFT JOIN community ON (vocabolario.IDautore=community.ID)
WHERE...
A questo punto ottengo (ovviamente) una tabella con le colonne
ID, nick, IDautore, autore, linkimmagine.
Il problema è che il "nome" degli autori sta un po' nella colonna nick (per
gli utenti registrati) e un po' nella colonna autore (per gli utenti non
registrati). Quindi se ordino in base alla colonna autore, ottengo prima
tutte le tuple degli iscritti (perchè il loro valore della colonna autore
risulta NULL) e poi tutti quelli dei non iscritti, mentre io vorrei
un'ordinamento alfabetico globale.
Ho provato con CONCAT concatenando la colonna nick e autore in una nuova
colonna nome, ma non risulta niente di bello, perchè la CONCAT restituisce
NULL se uno dei suoi "valori" è null.
Mi chiedevo se c'è un modo per ottenere (fermo restando che le colonne che
già risultano dalla query di cui sopra mi servono) una colonna in più in cui
vi è una copia del contenuto di nick nel caso di utente registrato, o una
copia del contenuto di autore nel caso di utente non registrato, in modo da
poter ordinare in base a quella colonna.
Si può fare sta cosa?
Grazie in anticipo ;D
-- 
doGmaI


Il tuo problema e' che i dati non sono normalizzati.
dovresti unificare gli autori anche se hai solo il nick.
Comunque, una soluzione brutale esiste. Non e' ottimizzata,
perche' la non normalizzazione dei dati impedisce l'usi di un
indice, ma funziona.
select
     case when autore is not null then autore
          when nick is not null then nick
     else 'nessun autore!!'
     end AS autore_sicuro, ID, nick, IDautore, autore, linkimmagine
from
    nometabella
order by
    autore_sicuro;
ciao
gmax
-- 
  _  _ _  _
(_|| | |(_|><
  _|
http://gmax.oltrelinux.com

 indice, ma funziona.
Provo questa soluzione intanto.
Grazie tante
-- 
doGmaI

 (autore è una stringa).
Hai un chiaro errore di modellazione, come ti hanno già fatto notare.
Per la teoria relazionale, non esistono attributi opzionali, attributi
che cambiano significato "a seconda di", numeri "magici" (IDautore=0 è
un valore perfettamente valido), attributi che stanno in due tabelle a
seconda di un valore o di una procedura di inserimento...
Modella correttamente lo schema e vedrai che non avrai mai più bisogno
di tricks nel codice.

 di tricks nel codice.
Allora cambio leggermente la domanda.
E' necessario però a sto punto spiegare brevemente come funziona la "cosa"
che sfrutta il database
C'è una raccolta di disegni e ogni disegno viene associato ad un autore. Ora
alcuni autori sono iscritti al sito e quindi dotati di un loro ID nella
tabella iscritti. Altri disegni sono associati a gente che non è iscritta e
pertanto non è identificata da un ID. Quando devo inserire nella tabella
disegni un disegno fatto da un autore che non è registrato "prima" usavo
ID=0 e mettevo direttamente il nome in una colonna autore (stringa)
Ovviamente questa non è una soluzione perfetta, allora vi chiedo a sto
punto, come sarebbe corretto modellizzare sta cosa?
Dovrei mettere un record per ogni autore anche se questo non è iscritto
nella tabella iscritti? Non mi sembra molto "intelligente".
Ora come ora ho pensato di mettere un ID>0 per gli iscritti al sito e un
ID<0 per gli autori non iscritti. Anche questa non è corretta come
modellizzazione.
Ma come dovrei fare per tenere traccia di questi autori che non sono
iscritti (almeno una volta per tutte imparo sta cosa e non sbaglio +)
grazie delle eventuali dritte
-- 
doGmaI

 grazie delle eventuali dritte
Stai chiedendo la soluzione pronta? Se te la dico non impari :-)
Se invece stai chiedendo un corso di teoria relazionale, in meno di
alcuni mesi di studio è difficile tirare fuori qualcosa....

 alcuni mesi di studio è difficile tirare fuori qualcosa....
Qualcosa ho fatto in un corso di basi di dati, ma questa faccenda dei "dati"
non presenti nel db non era contemplata e devo essere sincero non mi va di
comprarmi un libro di basi di dati per un sito amatoriale spendendo magari
80-90€ quando non ci ricavo niente.
-- 
doGmaI

 l'organizzazione del DB, quella me la faccio io
Dunque, cominciamo a ragionare sul seguente scheletro di schema:
Gente {Persona}
Iscritti {Iscritto FK gente.persona}
Opere {Autore FK gente.persona}
Ogni persona viene censita innanzitutto nella tab. Gente; solo alcuni di
questi anche si iscrivono, e viene inserita una riga in Iscritti.
Ogni opera ha sempre una e una sola persona come autore,
indipendentemente se è iscritto oppure no.
A questo punto, anche le interrogazioni diventano più logiche:
Per sapere se una Persona è anche autore: avrà almeno una riga in Opere
Per sapere le opere con gli autori: join opere con Gente
Per sapere le opere di tutti gli autori iscritti: join Opere con Iscritti
Per sapere le opere anonime: join Opere con Gente not in Iscritti
Questo è uno schema che io definisco "sano", perché ha l'enorme vantaggio
di rendere IMPOSSIBILE l'inserimento di dati (logicamente) errati. Adesso
l'integrità dei dati è responsabilità del motore di database, e non del
programma.
Restano ancora aperte varie questioni, ma iniziamo a ragionare su questo.

 Restano ancora aperte varie questioni, ma iniziamo a ragionare su questo.
Da qualche parte devo pur iniziare... :D
Intanto grazie
-- 
doGmaI

 dati che magari verranno usati solo una volta?
No, è un po' un controsenso: se li usi una volta, non devi comunque
registrarli da qualche parte?
Anche se fosse, non è importante. Non ti devi fare di questi problemi.
Oggigiorno i GB abbondano. Quello che costa sono i bug e il tempo che
il programmatore ci spende sopra.
Quello che devi inoltre notare, è che Iscritti è una subtable di Gente,
e sono legate da un senso logico. Un progetto di schema inizia sempre
col chiedersi che sono _esattamente_ le entità che andrò a modellare, e
in che modo sono correlate.
ciao

 ciao
Beh, per ora ti ringrazio. Appena avrò altri problemi con SQL e DB saprò
dove trovare il "mio tecnico di fiducia".
Grazie
-- 
doGmaI