Newsgroup: it.comp.software.database
Titolo: Select di tutte le colonne, tranne una, con MySQL

Avrei già risolto eliminando la colonna via php.. ma per curiosità.. come si
scrive una query MySQL del tipo...
SELECT * tranne quella_che si chiama_così FROM mia_tabella
Grazie

 SELECT * tranne quella_che si chiama_così FROM mia_tabella
SELECT non_asterisco, ma_solo, le_colonne, che_ti, servono FROM tabella;
tra l'altro, per motivi spiegati e rispiegati, è meglio non usare select * 
in un'applicazione. è comodo solo per interrogare velocemente la tabella da 
prompt sql.
ciao
-- 
Punkarruso
mail:punkarruso(at)geniotradottoininglese(dot)it
pubblicità progresso:
http://ethology.intercult.su.se/freescience/

 SELECT * tranne quella_che si chiama_cosě FROM mia_tabella
SELECT colonna1, colonna2, colonna3....
senza pero' indicare la COLONNA_CHE_NON_VUOI
Davide

 SELECT non_asterisco, ma_solo, le_colonne, che_ti, servono FROM tabella;
Scusami.. in effetti mi sono spiegato male...
Le tue considerazioni sono pertinenti ma non è possibile specificare nel mio
caso le colonne che mi servono poichè il loro numero può variare (a volte ne
vengono aggiunte o eliminate) quindi non è detto che si sappia qual è il
loro numero o il nome.
In realtà non è un problema vero e proprio perchè o tolgo la colonna che non
voglio dopo via php o vado a prendere i nomi delle colonne che mi servono da
un'altra table; è solo una curiosità che mi è venuta. Mi sono chiesto.. se
ho solo una tabella in cui aggiungo o elimino delle colonne.. come posso
selezionarle tutte tranne quelle che hanno un determinato nome?
Scusa di nuovo per la poca chiarezza del post iniziale.

 come posso selezionarle tutte tranne quelle che hanno un determinato nome?
in che modo vengono messe e tolte le colonne?
non c'è modo, a fronte di questa modifica strutturale, di variare anche la 
struttura della query?
potresti tenere traccia dei campi in un'altra tabella, oppure tenerne conto 
in un backend in cui puoi 'checkare' i campi da selezionare in quella query.
comunque, a questo punto anche select * può essere una soluzione!
ciao!
-- 
Punkarruso
mail:punkarruso(at)geniotradottoininglese(dot)it
pubblicità progresso:
http://www.gnu.org/philosophy/no-word-attachments.it.html

 loro numero o il nome.
   Ti consiglio caldamente di sottoporre ad un'accurata revisione il 
processo di normalizzazione che hai seguito nel progetto della tua base 
di dati.
-- 
Alla prossima,
Marco

 potresti tenere traccia dei campi in un'altra tabella
In effetti nella mia applicazione "reale" questo avviene già: in una table a
parte c'è l'elenco delle colonne che mi interessa interrogare. Quindi prima
ricavo quelle e poi le uso per la seconda query.
Ma la mia curiosità è questa, senza implicazioni relative all'efficienza o
alla distribuibilità dell'applicazione:
se ho una sola tabella, di cui non conosco il numero ed il nome dei campi,
posso ricavare tutti i campi presenti tranne quello che per ipotesi si
chiama 'id'?
Pensavo che ci fosse qualche operatore adatto allo scopo, tenendo presente
che devo fare per forza riferimento a * dal momento che non so a priori il
nome dei campi.
Credevo che fosse dovuto alla mia ignoranza nell'uso della sintassi di
interrogazione.
Vabbè.. non importa.. è solo una curiosità..

 di dati.
Si beh.. non è questo il punto. Come ho spiegato in un altro post si tratta
solo di una considerazione teorica. Nella mia applicazione questo problema
non esiste dal momento che le colonne che mi interessano le ricavo da
un'altra tabella: ripeto che si tratta solo di una curiosità.

 chiama 'id'?
non in SQL.
è impossibile a meno che non usi delle viste di sistema e non ti crei una 
sp che ti crei LEI dinamicamente la query. a questo punto potresti 
prevedere come input un campo da non selezionare.
chiaramente non parlo di mysql!!
...soluzioni così sporche che mi vengono i brividi...
ciao
-- 
Punkarruso
mail:punkarruso(at)geniotradottoininglese(dot)it
pubblicità progresso:
http://php.dopoil.com

 è impossibile
Perfetto.. almeno vuol dire che se non ci sono riuscito non è dovuto alla
mia ignoranza in materia di sintassi :)

 un'altra tabella: ripeto che si tratta solo di una curiosità.
   Si`, ho letto. Vorrei pero` sottolineare il punto che una relazione 
ben disegnata dovrebbe esporre alle interrogazioni un insieme di 
attributi ben definito e coerente. Alle volte, invece, capita che un 
errore di progettazione porti a relazioni interpretate dalle 
interrogazioni in modo--diciamo--"dinamico", lasciando alla business 
logic il compito di decidere volta per volta le proiezioni in base a 
condizioni non predeterminabili.
   Questo accade perche` spesso non e` sufficientemente chiaro in fase 
di progetto quali debbano essere gli attributi di una relazione, 
venendosi in tal modo a creare situazioni in cui una stessa tabella 
fisica si trova, di fatto, a gestire il carico di piu` relazioni 
logiche, a seconda dei campi richiesti dalle varie interrogazioni. E` 
per questo che ti consigliavo di curare meglio la normalizzazione: sono 
piu` utili, ed hanno prestazioni applicativamente migliori, piu` 
relazioni con pochi attributi ma consistenti su ogni singola istanza, 
piuttosto che una sola con molti attributi che si applicano a gruppi 
distinti di istanze.
   Una misura di quanto affermo la da` la distribuzione dei valori NULL 
all'interno dei campi delle istanze: in una base dati ben progettata, in 
una relazione gli attributi per i quali valga l'ipotesi di NULL 
accettato sono pochi rispetto al totale della relazione stessa, 
altrimenti viene da chiedersi perche` esistano tali attributi per 
istanze per le quali mai verra` chiesta la loro valorizzazione.
   Un altro caso molto frequente, anche a giudicare dalla lettura degli 
articoli in questo NG, e` la sovradefinizione di attributi. Ho notato, 
infatti, che la "pratica" tende spesso a risolvere il problema delle 
chiavi univoche mediante l'utilizzo di attributi "contatore" o 
"sequenza" che non sempre sono utili e qualche volta addirittura dannosi.
   Credo che in questo caso ricada anche il tuo problema: ove cosi` 
fosse rifletti sulla reale necessita` del campo 'ID' che non vuoi 
visualizzare nella tua interrogazione. Se non vuoi vederlo, forse non e` 
nemmeno del tutto necessario. Potresti, dunque, partizionare la tua 
relazione in piu` relazioni con attributi sempre utilizzati, e poi 
legarle mediante una politica efficiente di definizione delle chiavi 
interne ed esterne.
   Come suole dirsi in queste occasioni: just my two cents... ;)
-- 
Alla prossima,
Marco

 ...soluzioni cosě sporche che mi vengono i brividi...
brrrr.... rabbrrrrividiamo... ! :)
oddio, non so quanto del codice dao qui sotto possa essere portato in sql,
cmq l'idea dovrebbe esserci. questo e' un semplice access: se in un db serio
non si puo' fare una cosa del genere, be', quel db non e' serio :)
il db e' quello di cui ho postato la struttura poco fa nel thread 'database
access':
Option Explicit
Private Sub Command1_Click()
    Dim db As Database, s As String, f As Field
    Set db = OpenDatabase("db1.mdb")
    s = "select "
    For Each f In db.TableDefs("files").Fields
        s = s & f.Name & ", "
    Next
    s = Left(s, Len(s) - 2)
    Text1 = s
    db.Close: Set db = Nothing
End Sub
Private Sub Command2_Click()
    Dim db As Database, s As String, f As Field
    Set db = OpenDatabase("db1.mdb")
    s = "select "
    For Each f In db.TableDefs("files").Fields
        If f.Name <> "fpath" Then s = s & f.Name & ", "
    Next
    s = Left(s, Len(s) - 2)
    Text2 = s
    db.Close: Set db = Nothing
End Sub
risultato:
cmd1: select id, fpath, fname, fdate, fsize
cmd2: select id, fname, fdate, fsize
ciao, j.
--
www.sundaysw.com