select über mehrer Spalten, Spalten aber variabel

Hallo,

wie kann ich ein select über mehrere Spalten durchführen ohne die
einzelnen Spaltennamen zu kennen?

Erklärung:
Ich habe eine Tabelle mit mehreren Sprachen für eine Website. Jede
Sprache steht in einer eigenen Spalte.

id | var | de | eng | cz |

In einem speziellen Fall muss ich aber nach einem Wort suchen welches
ich in deutsch kenne, aber nicht den Namen der Spalte kenne wo das
gesuchte Wort in der anderen Sprache abgelegt ist.

Das könnte ich ich jetzt so lösen:
select de, eng, cz from tabelle where de like '%$txt%' and (eng like
'%$su_txt%' or cz like '%$su_txt%')

Wenn jetzt aber eine weitere Sprache hinzu käme, dann müsste ich diese
Funktion ebenfalls anpassen.
Dies möchte ich aber vermeiden und das ganze variabel machen.

Gibt es dafür eine Möglichkeit.?

Vielen Dank und Gruß

Marcel

Re: select übermehrer Spalten, Spalten aber variabel

Marcel Polty wrote:

> Hallo,
>
> wie kann ich ein select über mehrere Spalten durchführen ohne die
> einzelnen Spaltennamen zu kennen?
>
> Erklärung:
> Ich habe eine Tabelle mit mehreren Sprachen für eine Website. Jede
> Sprache steht in einer eigenen Spalte.
>
> id | var | de | eng | cz |

Normalisieren.

Tabelle 1:
id | var

Tabelle 2:
id | lang | text

evtl. noch Tabelle 3: (in diesem Fall ist lang in Tabelle 2 lang_id)
lang_id | lang_name


Wenn das nicht geht, kannst Du applikationsseitig die Spalten der Tabelle
abfragen (SHOW COLUMNS FROM Tabelle oder so ähnlich) und das Query dann von
Hand zusammenbasteln. Aber normalisieren wäre sinnvoller...

> Das könnte ich ich jetzt so lösen:
> select de, eng, cz from tabelle where de like '%$txt%' and (eng like
> '%$su_txt%' or cz like '%$su_txt%')

select such.lang, such.text from Tabelle2 AS such JOIN Tabelle2 AS de ON
such.id=de.id AND de.lang='de' AND such.lang != 'de' WHERE de.text LIKE
'%$txt%' and such like '%$su_txt%'

im Falle einer Tabelle 3: entsprechend erweitern oder lang_id vorher
ermitteln...



Thomas
--
> Bitte nicht gleich losschimpfen,
Das ist hier auch nicht Sitte. Denn hier ist hamster.all und nicht de.all.
(Maik Bauch und Joern Weber in hamster.de.config; 2000-09-24)

Re: select über mehrer Spalten, Spalten aber variabel

Hallo,

vielen Dank Thomas für die Tipps!!!

Thomas Rachel schrieb:
>Normalisieren.
>
>Tabelle 1:
>id | var
>
>Tabelle 2:
>id | lang | text
>
>evtl. noch Tabelle 3: (in diesem Fall ist lang in Tabelle 2 lang_id)
>lang_id | lang_name

An Normalisieren hatte ich am Anfang auch gedacht, dann kam aber die
Frage der Aktualisierung auf. Und die muss ja von verschiedenen Leuten
in verschiedenen Sprachen gemacht werden. Die sollen auf keinen Fall
alle Zugriff auf die Datenbank haben. Also hat man entschieden das
über eine Excel-Tabelle zu realisieren.

Und deshalb bin ich von der Normalisierung wieder abgekommen und ziehe
es vor, alles in einer Tabelle zu machen. Zumal die Anzahl der
Spalten, sprich Sprachen auch absehbar ist.

>Wenn das nicht geht, kannst Du applikationsseitig die Spalten der Tabelle
>abfragen (SHOW COLUMNS FROM Tabelle oder so ähnlich) und das Query dann von
>Hand zusammenbasteln. Aber normalisieren wäre sinnvoller...

Auch SHOW COLUMNS habe ich mir schon angeschaut. Ich komme aber nicht
wirklich zurecht damit. Ich finde z.B. nicht die Variable wo nach
einer Abfrage die Spalten drin stehen. Das MySQL Handbuch lässt mich
ganz schön im Stich.
Wenn ich hier einen Tipp bekommen würde, wäre ich sofort ein ganzes
Stück weiter.
Die Scipt-Sprache ist übrigens php.

Nochmals vielen Dank

Gruß Marcel

Re: select über mehrer Spalten, Spalten aber variabel

Marcel Polty schrieb:

> Thomas Rachel schrieb:
>> Normalisieren.
>>
>> Tabelle 1:
>> id | var
>>
>> Tabelle 2:
>> id | lang | text
>>
>> evtl. noch Tabelle 3: (in diesem Fall ist lang in Tabelle 2 lang_id)
>> lang_id | lang_name
>
> An Normalisieren hatte ich am Anfang auch gedacht, dann kam aber die
> Frage der Aktualisierung auf. Und die muss ja von verschiedenen Leuten
> in verschiedenen Sprachen gemacht werden. Die sollen auf keinen Fall
> alle Zugriff auf die Datenbank haben. Also hat man entschieden das
> über eine Excel-Tabelle zu realisieren.
>

Ah, eine "enterprisey"-Lösung. Excel, weil man nicht weiß, wie man
Zugriffsrechte in MySQL regelt? Keine Normalisierung, weil man
GRANT INSERT on db.tabelle.spalte TO erwin identified by ...
nicht kennt?

> Und deshalb bin ich von der Normalisierung wieder abgekommen und ziehe
> es vor, alles in einer Tabelle zu machen. Zumal die Anzahl der
> Spalten, sprich Sprachen auch absehbar ist.
>

Ah, es wird enterpriseyer. Natürlich ist die Anzahl der Sprachen
"absehbar". Sie ist sogar endlich, egal, was ihr noch vorhabt. Aber
was hat all das (Excel, endliche Zahl von Sprachen) mit der von *Dir*
entworfenen Tabellenstruktur in *Deiner* Datenbank zu tun? Wenn Du
Excel-Daten in eine Tabelle reinpopeln kannst (weil niemand GRANT
richtig bedienen kann?), dann kannst Du sie doch auch in mehrere
Tabellen reinpopeln. Wo ist Deiner Meinung nach das Problem?

>> Wenn das nicht geht, kannst Du applikationsseitig die Spalten der Tabelle
>> abfragen (SHOW COLUMNS FROM Tabelle oder so ähnlich) und das Query dann von
>> Hand zusammenbasteln. Aber normalisieren wäre sinnvoller...
>
> Auch SHOW COLUMNS habe ich mir schon angeschaut. Ich komme aber nicht
> wirklich zurecht damit. Ich finde z.B. nicht die Variable wo nach
> einer Abfrage die Spalten drin stehen. Das MySQL Handbuch lässt mich
> ganz schön im Stich.

Nicht wirklich - Wenn Du eine hinreichend aktuelle MySQL-Version hast,
ist SHOW COLUMNS ohnehin überflüssig, weil es dort INFORMATION_SCHEMA
gibt.

> Wenn ich hier einen Tipp bekommen würde, wäre ich sofort ein ganzes
> Stück weiter.

Normalisierung. Alles andere ist Krampf.

Re: select übermehrer Spalten, Spalten aber variabel

Marcel Polty wrote:

> [...] Also hat man entschieden das über eine Excel-Tabelle zu realisieren.
>
> Und deshalb bin ich von der Normalisierung wieder abgekommen und ziehe
> es vor, alles in einer Tabelle zu machen.

Das eine hat mit dem anderen aber nichts zu tun. Du kannst beim Auslesen der
Excel-Tabelle ja dennoch in verschiedene Tabellen einfügen, aber das hat
Christian ja schon erwähnt.

Eingabeformat ist eine Sache, Speicherformat (also Tabellenstruktur) eine
ganz andere, die mit ersterem nicht unbedingt viel zu tun haben muß.


> Auch SHOW COLUMNS habe ich mir schon angeschaut. Ich komme aber nicht
> wirklich zurecht damit. Ich finde z.B. nicht die Variable wo nach
> einer Abfrage die Spalten drin stehen.

ähm, hast Du es denn schon ernsthaft ausprobiert? Hab jetzt grad keine Lust,
nachzuschauen, aber irgendwo steht garantiert, daß dieser Befehl ein
Resultset (oder wie das heißt) zurückgibt, genau wie ein Select-Befehl.
(beim Probieren im MySQL-CLI-Client: es kommt genau so eine Tabelle zurück,
wie sie auch ein SELECT-Befehl liefern könnte).

Somit liegt es nahe, daß das Ergebnis genauso abgefragt werden könnte.

Ein Test in einem mysql_query / while mysql_fetchrow()-Konstrukt zeigt Dir,
daß diese Vermutung stimmt. D.h. Du durchläufst diese Schleife und
speicherst die dabei zutage geförderten Spaltennamen irgendwo, wo Du sie
später in ein Query einbauen könntest. Aber wie gesagt - Normalisierung ist
sauberer.


Thomas
--
Trolle sind vergleichbar mit präpubertären Jungs, die in Unterwäsche in die
Betstunde eines Nonnenklosters platzen und lautstark fragen, ob der Slip
einer der anwesenden Damen gehöre.
(Cheatah in dnq: <9dgb35.90.1@hadie403.hadiko.de>)

Re: select übermehrer Spalten, Spalten aber variabel

Christian Kirsch wrote:

> Nicht wirklich - Wenn Du eine hinreichend aktuelle MySQL-Version hast,
> ist SHOW COLUMNS ohnehin überflüssig, weil es dort INFORMATION_SCHEMA
> gibt.

Ich nehme an, dafür braucht man 5.x.

Gibt es einen nennenswerten "Qualitäts-"Unterschied zwischen der Verwendung
dieser Tabellen und dem SHOW COLUMNS...? Abgesehen davon, daß man diese
INFORMATION_SCHEMA evtl. mit einer unnormalisierten Tabelle joinen kann,
wenn man sowas krankes denn wollte...


Thomas
--
Kampf den Teletubbies!

Re: select über mehrer Spalten, Spalten aber variabel

OK!

Christian Kirsch schrieb:

>Ah, eine "enterprisey"-Lösung. Excel, weil man nicht weiß, wie man
>Zugriffsrechte in MySQL regelt? Keine Normalisierung, weil man
> GRANT INSERT on db.tabelle.spalte TO erwin identified by ...
>nicht kennt?

Keine Ahnung wo Du da oben rumschwebst, pass nur gut auf das Du nicht
abstürzt ;-)
Ich habe schon vor 5 oder 6 Jahren normalisierte Datenbanken entworfen
und die entsprechenden Abfragen programmiert.

>> Und deshalb bin ich von der Normalisierung wieder abgekommen und ziehe
>> es vor, alles in einer Tabelle zu machen. Zumal die Anzahl der
>> Spalten, sprich Sprachen auch absehbar ist.
>>
>
>Ah, es wird enterpriseyer. Natürlich ist die Anzahl der Sprachen
>"absehbar". Sie ist sogar endlich, egal, was ihr noch vorhabt. Aber
>was hat all das (Excel, endliche Zahl von Sprachen) mit der von *Dir*
>entworfenen Tabellenstruktur in *Deiner* Datenbank zu tun? Wenn Du
>Excel-Daten in eine Tabelle reinpopeln kannst (weil niemand GRANT
>richtig bedienen kann?), dann kannst Du sie doch auch in mehrere
>Tabellen reinpopeln. Wo ist Deiner Meinung nach das Problem?

Das hat mit Zufriffsrechten usw. überhaut gar nichts zu tun.
Die Leute welche die Übersetzungen machen, sind bunt zusammengesucht
und haben u.U gar nichts mit Computer am Hut. Warum sollte ich denen
ein Interface XY erklären um die paar Worte einzugeben? Eine
Tabellen-Kalkulations-Tabelle kann jeder ohne großartige Einweisung
ausfüllen.

Und wenn man die Daten auf mehere Tabellen verteilt, dann muss man
auch mehrere Tabellen aktuell halten. Das ist Fehleranfällig. Zumal
man die Fehler selbst gar nicht merken kann. Oder kannst Du die
polnische, tschechische, russische Sprache....?

>Normalisierung. Alles andere ist Krampf.

Nicht nur ich denke das es Gründe gibt die dagegen sprechen.

Marcel

Re: select über mehrer Spalten, Spalten aber variabel

Marcel Polty schrieb:
> Christian Kirsch schrieb:

> Die Leute welche die Übersetzungen machen, sind bunt zusammengesucht
> und haben u.U gar nichts mit Computer am Hut. Warum sollte ich denen
> ein Interface XY erklären um die paar Worte einzugeben? Eine
> Tabellen-Kalkulations-Tabelle kann jeder ohne großartige Einweisung
> ausfüllen.

Das kann man akzeptieren.

> Und wenn man die Daten auf mehere Tabellen verteilt, dann muss man
> auch mehrere Tabellen aktuell halten. Das ist Fehleranfällig. Zumal
> man die Fehler selbst gar nicht merken kann.

Es ist aber trotzdem kein Argument dafür, aus einer Excel-Tabelle
auch eine DB-Tabelle zu machen. Schreibe ein Importscript in Deiner
bevorzugten Sprache, welches die Sprachspalten der Excel-Tabelle
halt in entprechend viele DB-Tabellen übertragt.


Gruß
JPM

Re: select über mehrer Spalten, Spalten aber variabel

Marcel Polty wrote:
> Christian Kirsch schrieb:
>
>>Ah, eine "enterprisey"-Lösung. Excel, weil man nicht weiß, wie man
>>Zugriffsrechte in MySQL regelt? Keine Normalisierung, weil man
>> GRANT INSERT on db.tabelle.spalte TO erwin identified by ...
>>nicht kennt?
>
> Keine Ahnung wo Du da oben rumschwebst, pass nur gut auf das Du nicht
> abstürzt ;-)
> Ich habe schon vor 5 oder 6 Jahren normalisierte Datenbanken entworfen
> und die entsprechenden Abfragen programmiert.

Mal angenommen, daß dem tatsächlich so ist, und du nicht nur
phantasierst - du kannst das prima verbergen. Glückwunsch!

Das war Ironie!

>>> Und deshalb bin ich von der Normalisierung wieder abgekommen und ziehe
>>> es vor, alles in einer Tabelle zu machen. Zumal die Anzahl der
>>> Spalten, sprich Sprachen auch absehbar ist.
>>
>>Ah, es wird enterpriseyer. Natürlich ist die Anzahl der Sprachen
>>"absehbar". Sie ist sogar endlich, egal, was ihr noch vorhabt. Aber
>>was hat all das (Excel, endliche Zahl von Sprachen) mit der von *Dir*
>>entworfenen Tabellenstruktur in *Deiner* Datenbank zu tun? Wenn Du
>>Excel-Daten in eine Tabelle reinpopeln kannst (weil niemand GRANT
>>richtig bedienen kann?), dann kannst Du sie doch auch in mehrere
>>Tabellen reinpopeln. Wo ist Deiner Meinung nach das Problem?
>
> Das hat mit Zufriffsrechten usw. überhaut gar nichts zu tun.
> Die Leute welche die Übersetzungen machen, sind bunt zusammengesucht
> und haben u.U gar nichts mit Computer am Hut. Warum sollte ich denen
> ein Interface XY erklären um die paar Worte einzugeben? Eine
> Tabellen-Kalkulations-Tabelle kann jeder ohne großartige Einweisung
> ausfüllen.

"Wir können das nicht richtig machen weil unsere Anwender zu doof
sind"? Na das nenne ich mal ein prima Argument.

FYI: etwas vergleichbare hat mein vor-7-Jahren Arbeitgeber auch gehabt
(allerdings mit einem sinnvollen Datenmodell). Der Aufwand war so in
der Gegend von 50 Zeilen PHP Code. Irgendwie 10.000% produktiver, als
die Daten erst durch Excel zu schieben. IMMV.

>>Normalisierung. Alles andere ist Krampf.
>
> Nicht nur ich denke das es Gründe gibt die dagegen sprechen.

Du glaubst, du hättest da Unterstützer? Namen her. Man will doch
schließlich wissen, für wen das Napalm ist...


XL