Joins mit gleichen Spaltennamen

[Daniel]

Hallo Leute!

Folgendes Problem: Ich hab zwei Tabellen:

+------+---------+     +------+---------+
|    Tabelle1    |     |    Tabelle2    |
+------+---------+     +------+---------+
|  id  | status  |     |  id  | status  |
+------+---------+     +------+---------+
|  1   | test1   |     |  1   | test2   |
+------+---------+     +------+---------+
|  2   | test4   |     |  2   | test3   |
+------+---------+     +------+---------+

Tabelle eins möchte ich mit Tabelle 2 über die ID verknüpfen, also in SQL etwa so: SELECT * FROM Tabelle1 INNER JOIN Tabelle2 ON Tabelle1.id = Tabelle2.id

---schnipp---
$dataquery = odbc_exec($conn, "SELECT * FROM Tabelle1 INNER JOIN Tabelle2 ON Tabelle1.id = Tabelle2.id");
while ($result = odbc_fetch_row($dataquery)) {
 $erg[] = odbc_fetch_array($dataquery);
}

var_dump($erg);
---schnapp---

Mein Problem ist, dass als Status hier nur "test2" und "test3" als Ergebnis zurückgeliefert werden. Die Inhalte "test1" und "test4" überschreibt er, sobald der gleiche Spaltenname auftritt. Tja und das ist natürlich nicht so schön.

Ich hoffe ihr könnt mein Problem nachvollziehen.

Bis dann

Daniel

[Andreas Korthaus]

Hi!

---schnipp---
$dataquery = odbc_exec($conn, "SELECT * FROM Tabelle1 INNER JOIN Tabelle2 ON Tabelle1.id = Tabelle2.id");
while ($result = odbc_fetch_row($dataquery)) {
$erg[] = odbc_fetch_array($dataquery);
}

var_dump($erg);
---schnapp---

Mein Problem ist, dass als Status hier nur "test2" und "test3" als Ergebnis zurückgeliefert werden. Die Inhalte "test1" und "test4" überschreibt er, sobald der gleiche Spaltenname auftritt. Tja und das ist natürlich nicht so schön.

Du könntest einen Alias definieren, also sowas:

SELECT
  Tabelle1.status AS status_tab1,
  Tabelle2.status AS status_tab2;
  ...

Dann kommst Du an das Ergebnis mit

$row = odbc_fetch_array($dataquery);
echo $row['status_tab1'];
...

Grüße
Andreas

[Daniel]

Hi Andreas,

Du könntest einen Alias definieren ...

Ein Alias find ich gut und hätte ich schon längst verwendet, aber den kann ich leider nicht definieren, da ich nicht weiß, was in der Tabelle alles drin steckt.
Ich habe nur die Info, dass die Tabelle existiert, der Rest muss in meinem Fall leider absolut dynamisch laufen.

Kann man eingentlich solch einen Alias definieren... SELECT * as tablename.* from... etc???

Bis dann
Daniel

[Cheatah]

Hi,

Ein Alias find ich gut und hätte ich schon längst verwendet, aber den kann ich leider nicht definieren, da ich nicht weiß, was in der Tabelle alles drin steckt.

das weißt Du. Das _musst_ Du wissen. Ohne dieses Wissen kannst Du nicht auf die Tabelle zugreifen. Zumindest musst Du das kennen, was Du verwenden willst - und der Rest ist Dir völlig egal, deswegen selektierst Du ihn auch nicht.

Kann man eingentlich solch einen Alias definieren... SELECT * as tablename.* from... etc???

Nein, und auf "*" möchtest Du außer zu Testzwecken *grundsätzlich* verzichten.

Cheatah

[Daniel]

Moin!

das weißt Du. Das _musst_ Du wissen. Ohne dieses Wissen kannst Du nicht auf die Tabelle zugreifen. Zumindest musst Du das kennen, was Du verwenden willst - und der Rest ist Dir völlig egal, deswegen selektierst Du ihn auch nicht.

Falsch das ist in dem Fall eine völlig falsche Aussage von dir. Ich _muss_ es nämlich nicht wissen... ich brauch höchstens ein Tabellennamen, mehr aber auch nicht. Wenn man etwas dynamisch erzeugen will (auch SQL Queries gehören dazu und Tabellen), muss ich teile dynamischer machen als andere. In diesem Fall muss es halt sehr sehr dynamisch sein. Eine bestimmte Tabelle ist vorgegeben, die einer bestimmten Schnittstellen entsprechen muss, beispielsweise einer id um die einzelnen Tabellen miteinander zu verknüpfen, mehr aber auch nicht. Der Rest kann durchaus variable sein und deshalb _muss_ ich ihn mit * selektieren.

Sonst stimm ich aber deiner Aussage völlig zu: Auf "*" sollte man, soweit es geht, verzichten.

Daniel

[Cheatah]

Hi,

Falsch das ist in dem Fall eine völlig falsche Aussage von dir. Ich _muss_ es nämlich nicht wissen...

doch, muss man. Alles andere ist entweder ein DB-Verwaltungs-Tool, welches dynamisch das Schema ermittelt (was in Deinem Fall aber nicht gegeben ist, weil Du sonst garantiert keinen JOIN hättest), oder aber ein grob fahrlässiges DB-Layout.

Eine bestimmte Tabelle ist vorgegeben, die einer bestimmten Schnittstellen entsprechen muss, beispielsweise einer id um die einzelnen Tabellen miteinander zu verknüpfen, mehr aber auch nicht. Der Rest kann durchaus variable sein und deshalb _muss_ ich ihn mit * selektieren.

Ihr möchtet euch mit Kreuztabellen und Normalformen auseinandersetzen.

Sonst stimm ich aber deiner Aussage völlig zu: Auf "*" sollte man, soweit es geht, verzichten.

Nicht "sonst", sondern immer. "*" ist allenfalls für rein manuelle Vorgänge mal nutzbar, darüber hinaus aber kompletter Unsinn.

Cheatah

[Andreas Korthaus]

Hallo!

Ihr möchtet euch mit Kreuztabellen und Normalformen auseinandersetzen.

Was hat das mit Spaltennamen zu tun? Wenn ich viele Tabellen habe kommt es schonmal vor dass Spalten gleich heißen, das muss nicht heißten dass sie redundante Inhalte enthalten. Außerdem ist eine Normalform schön, aber nicht immer der Weisheit letzter Schluss.

Sonst stimm ich aber deiner Aussage völlig zu: Auf "*" sollte man, soweit es geht, verzichten.

Nicht "sonst", sondern immer. "*" ist allenfalls für rein manuelle Vorgänge mal nutzbar, darüber hinaus aber kompletter Unsinn.

Eigentlich schon, ich habe es früher manchmal verwendet wenn ich eh die ganze Tabelle abfragen will, aber das vermeide ich heute auch. Nur wie man hier sieht hat es bei JOINs überhaupt nichts verloren, eben wegen solcher Seiteneffekte.

Grüße
Andreas

[Daniel]

Hallo!

Sonst stimm ich aber deiner Aussage völlig zu: Auf "*" sollte man, soweit es geht, verzichten.

Nicht "sonst", sondern immer. "*" ist allenfalls für rein manuelle Vorgänge mal nutzbar, darüber hinaus aber kompletter Unsinn.

Eigentlich schon, ich habe es früher manchmal verwendet wenn ich eh die ganze Tabelle abfragen will, aber das vermeide ich heute auch. Nur wie man hier sieht hat es bei JOINs überhaupt nichts verloren, eben wegen solcher Seiteneffekte.

Naja manchmal muss man halt die ganze Tabelle abfragen... und das JOIN ist nicht das Problem, sondern leider die SQL-Funktion in PHP, dass darf man natürlich nicht vergessen. Wenn man solch einen Query in einer Datenbank ausführt, funktioniert dieser ja, auch mit den richtigen Daten;)
Das Problem ist ja schließlich das assoziative Array.

Bis dann

Daniel

[Cheatah]

Hi,

Naja manchmal muss man halt die ganze Tabelle abfragen...

nein. Manchmal brauchst Du eine Spaltenmenge, die zufällig allen Spalten der Tabelle(n) entspricht - in dem Moment. Du musst *nie* im Programmcode alle Spalten selektieren.

und das JOIN ist nicht das Problem, sondern leider die SQL-Funktion in PHP, dass darf man natürlich nicht vergessen.

Nein, dieser Mangel in PHP ist nur der Effekt, der Dir den Fehler in Deinem SQL-Statement aufzeigt. "SELECT *" ist falsch.

Cheatah

[Cheatah]

Hi,

Ihr möchtet euch mit Kreuztabellen und Normalformen auseinandersetzen.
Was hat das mit Spaltennamen zu tun?

ganz einfach: Wenn man das Schema nicht in Form von Beziehungen aufbaut, sind die Spalten bekannt. Wenn die Spalten nicht bekannt sind, sind Beziehungen das Mittel der Wahl.

Wenn ich viele Tabellen habe kommt es schonmal vor dass Spalten gleich heißen,

Es geht nicht um Namenskollisionen, sondern um "SELECT *". Gleiche Spaltennamen sind völlig natürlich und können wunderbar per SQL gehandhabt werden. "SELECT *" im Programmcode ist jedoch ein Bug.

Cheatah

[Lude]

Hi,

"SELECT *" im Programmcode ist jedoch ein Bug.

Ideologie pur! - Es stellt sich nun also die Frage, ob es richtig ist (dann ist es immer etwas hilfreich) oder falsch (dann kann Ideologie uebelste Auswirkungen haben).

Betrachten wir einmal die Wirkung von "SELECT *": den horizontal ungefilterten Zugriff auf eine Datensatzmenge

Da man die Datensatzmenge durch eine geeignete Spiegelung immer auch so aendern kann, dass Spalten und Zeilen vertauscht sind, so muss, wenn die Gleichung "'SELECT *' == <BUG>" stimmt auch ein "select df_1" ein Bug sein, denn es erfolgt keine Filterung, wie bsp. mit "select top 10 *".

Ich vermute, dass der Einwand lautet, dass es nicht um Filterung geht, sondern darum, dass Datenzugriff ohne Semantik nie sinnvoll ist, nicht sinnvoll sein kann.

Ich wuerde da gerne dagegenhalten, dass Spalten auch einen "Datenfeldnamen" haben, naemlich eine Eindeutigkeit. - Ein Datensatz ohne Eindeutigkeit ist ein Bug!   ;-)

Gruss,
Lude

[Daniel]

Hi,

Ich wuerde da gerne dagegenhalten, dass Spalten auch einen "Datenfeldnamen" haben, naemlich eine Eindeutigkeit. - Ein Datensatz ohne Eindeutigkeit ist ein Bug!   ;-)

Auch eine interessante These... naja eigentlich ist die Spalte ja auch eindeutig, wenn man sie im Zusammenhang mit der Tabelle sieht... naja dafür ist php aber leider nicht richtig ausgelegt.

Bis dann

Daniel

[Andreas Korthaus]

Hallo!

Du könntest einen Alias definieren ...

Ein Alias find ich gut und hätte ich schon längst verwendet, aber den kann ich leider nicht definieren, da ich nicht weiß, was in der Tabelle alles drin steckt.

Hm, und was macht das dann für einen Sinn? Du willst die Daten doch eh weiterverarbeiten, und dazu musst Du wissen wie die Spalten heißen, oder?

Ich habe nur die Info, dass die Tabelle existiert, der Rest muss in meinem Fall leider absolut dynamisch laufen.

Auch wenn ich den Sinn nicht verstehe, das geht AFAIK nur indem Du dafür sorgst dass zumindest innerhalb der Joins keine doppelten Spaltennamen vorkommen. Aber da das vermutlich auch nicht geht fällt mir  nur noch ein auf Joins zu verzichten und diese Logik in PHP zu implementieren, da hast Du entsprechende Möglichkeiten.

Solche Dynamik bringt halt Nachteile mit sich. Ich würde mich aber fragen ob das tatsächlich sein muss. Wie Cheatah schon sagte, SELECT * ist sowieso böse ;-)

Kann man eingentlich solch einen Alias definieren... SELECT * as tablename.* from... etc???

Wäre mir nicht bekannt.

Grüße
Andreas

[Daniel]

Hallo!

Ein Alias find ich gut und hätte ich schon längst verwendet, aber den kann ich leider nicht definieren, da ich nicht weiß, was in der Tabelle alles drin steckt.

Hm, und was macht das dann für einen Sinn? Du willst die Daten doch eh weiterverarbeiten, und dazu musst Du wissen wie die Spalten heißen, oder?

Man kann auch Daten nur darstellen;) Auch komplexe Datenstrukturen sollte man darstellen können müssen sollen ;)).. deutsch war nie meine Stärke;)

Auch wenn ich den Sinn nicht verstehe, das geht AFAIK nur indem Du dafür sorgst dass zumindest innerhalb der Joins keine doppelten Spaltennamen vorkommen. Aber da das vermutlich auch nicht geht fällt mir  nur noch ein auf Joins zu verzichten und diese Logik in PHP zu implementieren, da hast Du entsprechende Möglichkeiten.

Die Logik habe ich in PHP schon eingebracht und funktioniert mit den von mir programmierten Klassen wunderbar. Mein Ergebnis ist auch wunderbar und richtig.

Um jetzt mal konkreter zu werden... bei einem Datensatz, den ich selektieren will, ist dies kein Problem. Dafür müssen allerdings zur Zeit schon 7 Queries ausgeführt werden.
Bei 200 Datensätzen mal 7 Queries, gibt das schon ein Problem. Dort soll ein Export in eine Excel-Tabelle gemacht werden. Funktioniert gut und auch richtig, aber die Geschwindigkeit ist bei vielen Datensätzen einfach super mega schlecht.

Solche Dynamik bringt halt Nachteile mit sich. Ich würde mich aber fragen ob das tatsächlich sein muss. Wie Cheatah schon sagte, SELECT * ist sowieso böse ;-)

Böse aufjedenfall, gib ich zu, aber halt ggf. auch sehr sehr dynamisch.

Danke

Daniel

[Cheatah]

Hi,

$dataquery = odbc_exec($conn, "SELECT * FROM Tabelle1 INNER JOIN Tabelle2 ON Tabelle1.id = Tabelle2.id");

never, ever, ever select * from anything. Wähle *immer* die Spalten aus, die Du haben willst. Ganz nebenbei kannst Du ihnen dann auch Aliase vergeben.

Cheatah

[Ludwig Ruderstaller]

never, ever, ever select * from anything. Wähle *immer* die Spalten aus, die Du haben willst. Ganz nebenbei kannst Du ihnen dann auch Aliase vergeben.

ich will mich mit dir echt nicth streiten cheatah, aber "never, ever" stimmt auch nicht. Es kann durchaus fälle geben an denen es sinn macht. zb. wenn man gar nicht weis welche felder es in der tabelle gibt.

Ludwig

[Cheatah]

Hi,

ich will mich mit dir echt nicth streiten cheatah, aber "never, ever" stimmt auch nicht. Es kann durchaus fälle geben an denen es sinn macht. zb. wenn man gar nicht weis welche felder es in der tabelle gibt.

auf diese Tabelle greift man nicht zu, zumindest nicht per Programmcode.

Cheatah

[Daniel]

Hi!

auf diese Tabelle greift man nicht zu, zumindest nicht per Programmcode.

Kann es sein, dass du ein ziemlicher besserwissericher Klugscheißer bist, der irgendwelche Meinungen vertritt, die er sich irgendwann mal auf der Toilette ausgedacht hat und dann der ganzen Welt aufdringen will?

Sorry, dass musste jetzt mal raus. Wenn du meinst, dass man es nicht darf, bitte... aber dann las doch andere, die sicherlich sich auch gut, vielleicht sogar besser als du auskennen (ich meine jetzt nicht mich damit), über mein Problem diskutieren. Das ist ein Diskussions-Forum und kein Ich-Habe-Eine-Meinung-Und-Dazu-Noch-Die-Beste-Also-Lass-Uns-Deshalb-Nicht-Diskutieren-Forum.

Ich sag ja gar nicht, dass es immer richtig und sinnvoll ist, wenn man mit * auf eine Tabelle zugreift, aber irgendwer, der sich vielleicht nicht so gut auskennt wie du, weil er hat ja sich so ein blödsinn wie * ausgedacht, wird sich ja wohl etwas dabei gedacht haben, dass er in seiner Datenbank-Engine auch ein * in SQL vorgesehen hat.
Naja aber das war sicherlich eh nur irgendein dahergelaufener Spinner...

In diesem Sinne

Daniel

[Cheatah]

Hi,

Kann es sein, dass du ein ziemlicher besserwissericher Klugscheißer bist, der irgendwelche Meinungen vertritt, die er sich irgendwann mal auf der Toilette ausgedacht hat und dann der ganzen Welt aufdringen will?

nein; aber es kann sein, dass Du diesbezüglich im Archiv recherchieren möchtest, bevor Du eine Debatte (nicht mal Diskussion) vom Zaun brichst, die dem bereits im Archiv stehenden nichts hinzuzufügen hat.

Ich sag ja gar nicht, dass es immer richtig und sinnvoll ist, wenn man mit * auf eine Tabelle zugreift, aber irgendwer, der sich vielleicht nicht so gut auskennt wie du, weil er hat ja sich so ein blödsinn wie * ausgedacht, wird sich ja wohl etwas dabei gedacht haben, dass er in seiner Datenbank-Engine auch ein * in SQL vorgesehen hat.

Das "*" ist dafür gedacht, mal eben schnell auf einer Shell per Hand eingetippt zu werden. Wer es im Programmcode verwendet, hat diverse Grundlagen nicht verstanden - und zwar nicht nur SQL-spezifische.

Cheatah

[Daniel]

Hi!

nein; aber es kann sein, dass Du diesbezüglich im Archiv recherchieren möchtest, bevor Du eine Debatte (nicht mal Diskussion) vom Zaun brichst, die dem bereits im Archiv stehenden nichts hinzuzufügen hat.

Ich wollte keine Diskussion über * herausfordern.

Ich sag ja gar nicht, dass es immer richtig und sinnvoll ist, wenn man mit * auf eine Tabelle zugreift, aber irgendwer, der sich vielleicht nicht so gut auskennt wie du, weil er hat ja sich so ein blödsinn wie * ausgedacht, wird sich ja wohl etwas dabei gedacht haben, dass er in seiner Datenbank-Engine auch ein * in SQL vorgesehen hat.

Das "*" ist dafür gedacht, mal eben schnell auf einer Shell per Hand eingetippt zu werden. Wer es im Programmcode verwendet, hat diverse Grundlagen nicht verstanden - und zwar nicht nur SQL-spezifische.

Ist jetzt in meinem Fall nicht gegeben, aber wenn ich einen Datenbank-Explorer programmieren würde, bleibt mir doch garkeine andere Möglichkeit als *. Ich weiß doch nicht welche Felder in meiner Tabelle sind.

Bis dann
Daniel

[Cheatah]

Hi,

Ich wollte keine Diskussion über * herausfordern.

nein, aber über "besserwisserische Klugscheißer".

Ist jetzt in meinem Fall nicht gegeben, aber wenn ich einen Datenbank-Explorer programmieren würde, bleibt mir doch garkeine andere Möglichkeit als *.

Doch, das DBMS bietet Zugriffsmöglichkeiten auf die Tabellen-Struktur.

Cheatah

[Daniel]

Hi!

nein, aber über "besserwisserische Klugscheißer".

Nein das stimmt auch nicht.

Ist jetzt in meinem Fall nicht gegeben, aber wenn ich einen Datenbank-Explorer programmieren würde, bleibt mir doch garkeine andere Möglichkeit als *.

Doch, das DBMS bietet Zugriffsmöglichkeiten auf die Tabellen-Struktur.

Klar, aber das kann es doch auch nicht sein, dass ich ersteinmal bei jeder Abfrage mir die Tabellen-Struktur analysieren lasse und dann, damit ich kein * benutze, eine Abfrage mir dynamisch generiern lasse, dessen Spalten immer aller Spalten der Tabelle entspricht... da seh ich persönlich keinen Sinn drin.

Bis dann

Daniel

[Cheatah]

Hi,

nein, aber über "besserwisserische Klugscheißer".
Nein das stimmt auch nicht.

ganz ehrlich: Das freut mich. Mehr noch hätte mich allerdings gefreut, wenn Du trotzdem vor der entsprechenden Bemerkung im Archiv danach recherchiert hättest.

Doch, das DBMS bietet Zugriffsmöglichkeiten auf die Tabellen-Struktur.
Klar, aber das kann es doch auch nicht sein, dass ich ersteinmal bei jeder Abfrage mir die Tabellen-Struktur analysieren lasse und dann, damit ich kein * benutze, eine Abfrage mir dynamisch generiern lasse, dessen Spalten immer aller Spalten der Tabelle entspricht...

Selbstverständlich, warum sollte das nicht sein können?

da seh ich persönlich keinen Sinn drin.

Wenn Du ein Tool zur Auswertung eines Datenbank-Schemas schreibst, sollte dieses Tool in der Lage sein, das Datenbank-Schema auszuwerten. IMHO macht das eine ziemliche Menge Sinn.

Cheatah

[Daniel]

Hi,

ganz ehrlich: Das freut mich. Mehr noch hätte mich allerdings gefreut, wenn Du trotzdem vor der entsprechenden Bemerkung im Archiv danach recherchiert hättest.

Nun ich habe versucht im Forum danach zu suchen, allerdings nicht nach einem * (da hätte ich wahrscheinlich zwar auch was gefunden, aber ich denke, dass wäre zu viel gewesen), sondern nach meinem eigentlichen Problem: 2 Spalten mit dem gleichen Spaltennamen joinen.

Klar, aber das kann es doch auch nicht sein, dass ich ersteinmal bei jeder Abfrage mir die Tabellen-Struktur analysieren lasse und dann, damit ich kein * benutze, eine Abfrage mir dynamisch generiern lasse, dessen Spalten immer aller Spalten der Tabelle entspricht...

Selbstverständlich, warum sollte das nicht sein können?

Weil der Aufwand enorm groß ist und für die Lesbarkeit des Codes nicht steigert.

da seh ich persönlich keinen Sinn drin.

Wenn Du ein Tool zur Auswertung eines Datenbank-Schemas schreibst, sollte dieses Tool in der Lage sein, das Datenbank-Schema auszuwerten. IMHO macht das eine ziemliche Menge Sinn.

Nein das ist es defenitiv nicht. Sondern nur ein Tool zum Verwalten eines mehr oder weniger variablen Datenbestandes.

Bis dann

Daniel

[Andreas Korthaus]

Hi!

Klar, aber das kann es doch auch nicht sein, dass ich ersteinmal bei jeder Abfrage mir die Tabellen-Struktur analysieren lasse und dann, damit ich kein * benutze, eine Abfrage mir dynamisch generiern lasse, dessen Spalten immer aller Spalten der Tabelle entspricht... da seh ich persönlich keinen Sinn drin.

Mag sein, aber Du solltest ja gemerkt haben dass es mit * eben nicht geht. IMHO hast Du 3 Möglichkeiten:

1. Du stellst tabellenweit eindeutige Spaltennamen sicher
2. Du benutzt keine Joins sondern fragst nur Tabellen ab und setzt die Arrays dann in PHP zusammen
3. Du fragst die Strukturen der Tabellen ab über die Du joinen willst, und erzeugst daraus ein entsprechendes SELECT-Statement mit passenden mit "Aliasen" für _alle_ Spalten, am besten setzt Du dann für jede Tabelle einen spezielle Prefix davor.

Ob das mit *_fetch_row() mit SELECT * geht weiß ich nicht, aber die Struktur musst Du in jedem Fall abfragen.

Der Einwurf bzgl. phpMyAdmin ist IMHO gerechtfertigt, wenn Du was Vergelichbares machen willst, denn im Prinzip ist das ja dasselbe wie "manuell SELECT *", da es nur zu Verwaltungszwecken dient.

Jede der genannten Möglichkeiten hat eigene Vor- und Nachteile. Musst halt sehen was Deinen Anforderungen am besten gerecht wird.

Du hast leider ein seltenes Problem, für sowas sind Datenbanken nicht gedacht. Es geht schlichtweg nicht so einfach wie Du es gerne hättest, das liegt wie gesagt an Deinem Vorhaben.

Wobei ich es nicht so ganz verstehe, denn wenn Du Joins verwendest, brauchst Du zwangsläufig Wissen über die Datrenstruktur, das geht nicht 100%ig dynamisch, da Du ja wissen musst worüber Du die(welche) Tabellen verknüpfen kannst.

Grüße
Andreas

PS: Wenn Du MS SQL verwendest, hierfür gibt es auch eine spezialisiertes Modul.

[Andreas Korthaus]

Hi!

kleiner Nachtrag:

Wobei ich es nicht so ganz verstehe, denn wenn Du Joins verwendest, brauchst Du zwangsläufig Wissen über die Datrenstruktur, das geht nicht 100%ig dynamisch, da Du ja wissen musst worüber Du die(welche) Tabellen verknüpfen kannst.

Ich denke genau hier liegt der Knackpunkt. Entweder Du schreibst ein Tool um eine DB zu verwalten, dann darfst Du aber nicht solche Joins machen und dem Anwender zusammenhängende Tabellen vorgaukeln, sondern Zugriff auf einzelnde Tabellen gewähren, dann hast Du auch keine Probleme.
Nur hast Du das vermutlich nicht vor, sondern willst eine Art Verwaltungsfunktion für eine spezielle Anwendung schreiben. Und eben das ist der Unterschied, das ist dann kein reines DB-Verwaltungs-Tool mehr, sondern Teil einer speziellen Anwendung. Und hier ziehen dann auch wieder alle Argumente von Cheatah, Daniela etc.
Das was Du vorhast würde sicher sehr unsauber, da es IMHO nicht konsequent ist sondern mit "schmutzigen Workarounds" probiert Dir Deinen Programmier-Aufwand zu verkleinern.
Ich würde mich evtl. sogar noch weiter aus dem Fenster lehnen und behaupten das DB-Design ist schlecht wenn Du mit solchen Tricks wie dynamischen Tabellen arbeiten musst. Das ist schon bei einzelnen Tabellen schlecht, bei Tabellen-Verknüpfungen IMHO fast eine Garantie für spätere Probleme. Aber dazu kenne ich Deine Anwendung nicht gut genug.

Grüße
Andreas

[Daniel]

Hi!

kleiner Nachtrag:

Wobei ich es nicht so ganz verstehe, denn wenn Du Joins verwendest, brauchst Du zwangsläufig Wissen über die Datrenstruktur, das geht nicht 100%ig dynamisch, da Du ja wissen musst worüber Du die(welche) Tabellen verknüpfen kannst.

Ich denke genau hier liegt der Knackpunkt. Entweder Du schreibst ein Tool um eine DB zu verwalten, dann darfst Du aber nicht solche Joins machen und dem Anwender zusammenhängende Tabellen vorgaukeln, sondern Zugriff auf einzelnde Tabellen gewähren, dann hast Du auch keine Probleme.

Mach ich ja nicht.

Nur hast Du das vermutlich nicht vor, sondern willst eine Art Verwaltungsfunktion für eine spezielle Anwendung schreiben. Und eben das ist der Unterschied, das ist dann kein reines DB-Verwaltungs-Tool mehr, sondern Teil einer speziellen Anwendung. Und hier ziehen dann auch wieder alle Argumente von Cheatah, Daniela etc.
Das was Du vorhast würde sicher sehr unsauber, da es IMHO nicht konsequent ist sondern mit "schmutzigen Workarounds" probiert Dir Deinen Programmier-Aufwand zu verkleinern.

Hmm, sicher der Programmieraufwand ist geringer, der Ergebnis ist das gleiche, die Geschwindigkeit bei kleinen Abfrage allerdings schlechter, bei großen Abfragen höher.

Ich würde mich evtl. sogar noch weiter aus dem Fenster lehnen und behaupten das DB-Design ist schlecht wenn Du mit solchen Tricks wie dynamischen Tabellen arbeiten musst. Das ist schon bei einzelnen Tabellen schlecht, bei Tabellen-Verknüpfungen IMHO fast eine Garantie für spätere Probleme. Aber dazu kenne ich Deine Anwendung nicht gut genug.

Nun ja ich denke nicht, dass das DB-Design schlecht ist (ich kann es euch leider nicht zeigen, weil es was Firmeninternes ist), aber was gefordert ist, ist etwas dynamisches Tabelle hinzufügen, Config ändern und das wars... der Rest wird wie gesagt dynamisch erzeugt, wie bearbeiten und hinzufügen etc. Die Verknüpfung geht nur über eine ID. Diese ID muss in den anderen Tabellen auch vorhanden sein, deshalb kann ich joinen. Sonst sind allerdings alle Spalten interessant (und das immer), deshalb werden sie selektiert.

Bis dann

Daniel

[Daniel]

Hi!

Mag sein, aber Du solltest ja gemerkt haben dass es mit * eben nicht geht. IMHO hast Du 3 Möglichkeiten:

1. Du stellst tabellenweit eindeutige Spaltennamen sicher
2. Du benutzt keine Joins sondern fragst nur Tabellen ab und setzt die Arrays dann in PHP zusammen
3. Du fragst die Strukturen der Tabellen ab über die Du joinen willst, und erzeugst daraus ein entsprechendes SELECT-Statement mit passenden mit "Aliasen" für _alle_ Spalten, am besten setzt Du dann für jede Tabelle einen spezielle Prefix davor.

1. Ist leider nicht möglich, das hab ich dummerweise nicht zu entscheiden.

2. Hab ich gemacht, aber das ist wie ich ja schon gesagt habe, bei einem Datensatz angenehm, aber bei 200 Datensätze mal min. 7 Queries nicht mehr so performant.

3. Das werde ich wohl, leider, machen müssen, wenn die Selektion schnell geschehen soll.

Der Einwurf bzgl. phpMyAdmin ist IMHO gerechtfertigt, wenn Du was Vergelichbares machen willst, denn im Prinzip ist das ja dasselbe wie "manuell SELECT *", da es nur zu Verwaltungszwecken dient.

Jede der genannten Möglichkeiten hat eigene Vor- und Nachteile. Musst halt sehen was Deinen Anforderungen am besten gerecht wird.

Du hast leider ein seltenes Problem, für sowas sind Datenbanken nicht gedacht. Es geht schlichtweg nicht so einfach wie Du es gerne hättest, das liegt wie gesagt an Deinem Vorhaben.

Tja das es ein seltenes Problem ist, weiß ich. Wobei ich sagen muss, das ich beispielsweise mit ADO nicht das Problem hätte, aber da sind wir ja nun mal nicht und es geht um PHP.

Wobei ich es nicht so ganz verstehe, denn wenn Du Joins verwendest, brauchst Du zwangsläufig Wissen über die Datrenstruktur, das geht nicht 100%ig dynamisch, da Du ja wissen musst worüber Du die(welche) Tabellen verknüpfen kannst.

Ja, tu ich auch. Wie ich schon sagte, sind gewisse Schnittstellen festgelegt, so beispielsweise eine eindeutige ID und ein anders Status-Feld. Andere Spalten können hier vollkommen unterschiedlich sein.

Der Rest wird allerdings nur in einer Konfigurationsdatei festgelegt. Beispielsweise, dass es eine Tabelle xy gibt, die der Definition entspricht und bei der Verarbeitung etc. berücksichtig werden muss. Für einen Datensatz kann ich wunderbar meine geschrieben Klassen benutzen, dafür nehme ich nämlich deinen Punkt 2.
Aber für mehr Geschwindigkeit, muss ich eine große Abfrage machen und nicht 2000 kleine.

PS: Wenn Du MS SQL verwendest, hierfür gibt es auch eine spezialisiertes Modul.

Ja das hatte ich probiert, aber hat irgendwie nicht ganz funktioniert, aber ich weiß nicht warum, aber der ODBC-Treiber tut seinen Dienst eigentlich auch gut.

Bis dann
Daniel

[Daniela Koller]

Hi Daniel

Ich sag ja gar nicht, dass es immer richtig und sinnvoll ist, wenn man mit * auf eine Tabelle zugreift, aber irgendwer, der sich vielleicht nicht so gut auskennt wie du, weil er hat ja sich so ein blödsinn wie * ausgedacht, wird sich ja wohl etwas dabei gedacht haben, dass er in seiner Datenbank-Engine auch ein * in SQL vorgesehen hat.
Naja aber das war sicherlich eh nur irgendein dahergelaufener Spinner...

* ist sehr nützlich für Adhoc Queries, aber in einem Programm haben sie nicht das geringste zu Suchen. Zum warum gibt es genug im Archiv. Bei uns in der Firma ist es sogar per Programmierrichtlinie verboten.

Jemand der nicht weis wie man mit Aliasen für Spaltennamen arbeitet, sollte sich vielleicht auch etwas zurückhalten was solche Kritik angeht.

Gruss Daniela

[Daniel]

Hi Daniela

* ist sehr nützlich für Adhoc Queries, aber in einem Programm haben sie nicht das geringste zu Suchen. Zum warum gibt es genug im Archiv. Bei uns in der Firma ist es sogar per Programmierrichtlinie verboten.

Nun ja ich bezweifle überhaupt nicht, dass * nicht wirklich effektiv sind, aber manchmal sind sie doch unumgehbar. Stell dir vor in phpMyAdmin würden Daten nicht mit * selektiert. Kann man sich dann die Daten dann anschauen?

Jemand der nicht weis wie man mit Aliasen für Spaltennamen arbeitet, sollte sich vielleicht auch etwas zurückhalten was solche Kritik angeht.

Ich weiß wohl, wie man mit Aliasen umgeht, aber ich kann in meinem Fall, wenn du dir den Thread mal komplett durchliest, arbeiten. Würde ich gerne machen, aber ist nicht möglich.

Bis dann

Daniel

[AlexBausW]

Hallo,

* ist sehr nützlich für Adhoc Queries, aber in einem Programm haben sie nicht das geringste zu Suchen. Zum warum gibt es genug im Archiv. Bei uns in der Firma ist es sogar per Programmierrichtlinie verboten.

Nun ja ich bezweifle überhaupt nicht, dass * nicht wirklich effektiv sind, aber manchmal sind sie doch unumgehbar. Stell dir vor in phpMyAdmin würden Daten nicht mit * selektiert. Kann man sich dann die Daten dann anschauen?

Es gibt mit PHP und MySQL Möglichkeiten die Tabellendefinitionen abzufragen, ohne * auch nur einmal verwenden zu müssen.

Jemand der nicht weis wie man mit Aliasen für Spaltennamen arbeitet, sollte sich vielleicht auch etwas zurückhalten was solche Kritik angeht.

Ich weiß wohl, wie man mit Aliasen umgeht, aber ich kann in meinem Fall, wenn du dir den Thread mal komplett durchliest, arbeiten. Würde ich gerne machen, aber ist nicht möglich.

Wenn Du auch weist, wie man mit der PHP-Doku umgeht, kannst Du Dir ja aus den entsprechenden Funktionen zusammensuchen, mit denen man statt eines assoziativen Arrays ein Numerisches als Ergebnis erhält, und wie man die Felddefinitionen zu den Spaltenindizes abfragen kann. :))

Gruß Alex

[Daniel]

Hallo!

Es gibt mit PHP und MySQL Möglichkeiten die Tabellendefinitionen abzufragen, ohne * auch nur einmal verwenden zu müssen.

Ich weiß, gibt es bei den ODBC-Funktionen auch, aber er gibt den Primary Key mit einem MS-SQL-Server nicht mit... seltsamerweise, aber ist im meinem Fall auch nicht wichtig.

Wenn Du auch weist, wie man mit der PHP-Doku umgeht, kannst Du Dir ja aus den entsprechenden Funktionen zusammensuchen, mit denen man statt eines assoziativen Arrays ein Numerisches als Ergebnis erhält, und wie man die Felddefinitionen zu den Spaltenindizes abfragen kann. :))

Gibt es bei MySQL, leider aber nicht bei ODBC... oder hab ich was übersehen???
Aber mir einen Query zu erzeugen, bei dem ich alle Spalten einen Alias gebe, halte ich auch nicht für sonderlich sinnvoll und leserlich.

Danke

Daniel

[AlexBausW]

Hallo,

Es gibt mit PHP und MySQL Möglichkeiten die Tabellendefinitionen abzufragen, ohne * auch nur einmal verwenden zu müssen.

Ich weiß, gibt es bei den ODBC-Funktionen auch, aber er gibt den Primary Key mit einem MS-SQL-Server nicht mit... seltsamerweise, aber ist im meinem Fall auch nicht wichtig.

Hmmm. Ich kenn die ODBC-Spezifikation nicht, aber dann sieht es so aus, daß sich irgendwer nicht daran hält.

Wenn Du auch weist, wie man mit der PHP-Doku umgeht, kannst Du Dir ja aus den entsprechenden Funktionen zusammensuchen, mit denen man statt eines assoziativen Arrays ein Numerisches als Ergebnis erhält, und wie man die Felddefinitionen zu den Spaltenindizes abfragen kann. :))

Gibt es bei MySQL, leider aber nicht bei ODBC... oder hab ich was übersehen???

Schau doch mal unter http://de.php.net/odbc, ob da nichts passendes zu finden ist. Wie wäre es mit odbc_fetch_row(), odbc_result(), odbc_field_*(), usw.. Allerdings habe ich die Funktionen noch nicht verwendet, aber die zugehörige Doku hört sich doch vielversprechend an. :)

Aber mir einen Query zu erzeugen, bei dem ich alle Spalten einen Alias gebe, halte ich auch nicht für sonderlich sinnvoll und leserlich.

Ist ja nicht nötig. Mit wenigen Zeilen Code kannst Du die Spaltennamen abfragen und zu einem kommaseparierten String zusammenfassen. Dieser lässt sich dann in die Abfrage einbauen. Und wenn man schon vorher weis, an welcher Stelle welcher Spaltenname in der Abfrage steht, weis man hinterher auch, wie die Spalte mit Index 1 heißt, und zu welcher Tabelle sie gehört.

Gruß Alex

[Ludwig Ruderstaller]

Hi,

auf diese Tabelle greift man nicht zu, zumindest nicht per Programmcode.

... da ich sagte ich will mich nicht streiten, und da das daniel doch schon begonnen hat. Las ich es gut sein auch wenn ich nicht deiner meinung bin.

:-)

Ludwig

[Daniel]

Hi!

... da ich sagte ich will mich nicht streiten, und da das daniel doch schon begonnen hat. Las ich es gut sein auch wenn ich nicht deiner meinung bin.

Naja ich wollte mich eigentlich auch nicht streiten und so einen unschönen Satz schreiben... muss eigentlich nicht sein, war auch eigentlich nichht sehr nett vor mir (eigentlich kann man in diesem Satz streichen). Aber manchmal muss man sich halt luft machen.

Bis dann

Daniel

[Ludwig Ruderstaller]

Hallo,

SELECT table1.*, table2.* FROM table1,table2... WHERE

SELECT a.*,b.* FROM table1 AS a, table2 AS b WHERE

such dir eine aus :)

Ludwig

[Andreas Korthaus]

Hi!

SELECT table1.*, table2.* FROM table1,table2... WHERE

SELECT a.*,b.* FROM table1 AS a, table2 AS b WHERE

such dir eine aus :)

Aber wenn ich mich nicht irre werden im Ergebnis trotzdem alle doppelten Spalten überschrieben, oder? Ich meine mich jedenfalls zu erinner dass wenn ich "taballe.spalte" angebe, dass im Ergebnis dann trotzdem nur "spalte" steht. Bin mir sogar ziemlich sicher.

Grüße
Andreas

[Daniel]

Hi!

Aber wenn ich mich nicht irre werden im Ergebnis trotzdem alle doppelten Spalten überschrieben, oder? Ich meine mich jedenfalls zu erinner dass wenn ich "taballe.spalte" angebe, dass im Ergebnis dann trotzdem nur "spalte" steht. Bin mir sogar ziemlich sicher.

Ja leider hast du Recht. Das ist ja mein Problem... man könnte natürlich sich zuerst alle Spaltenname auslesen und dort sich selber ein Konstrukt bauen wie: Tabelle.Spalte... aber das ist auch sehr aufwendig zu programmieren.

Danke

Daniel

[Lude]

Hi,

Mein Problem ist, dass als Status hier nur "test2" und "test3" als Ergebnis zurückgeliefert werden. Die Inhalte "test1" und "test4" überschreibt er, sobald der gleiche Spaltenname auftritt. Tja und das ist natürlich nicht so schön.

an dieser Stelle der Tipp, dass es sich bewaehrt hat DB-eindeutige Spaltennamen zu nutzen, die beispielsweise mit einer Praefix oder Suffix versehen sind, also z.B.:

'Sesssion_CreationDate' oder auch 'U_Right_GUID' ('U' kurz fuer 'User')

Gruss,
Lude

[Daniel]

Hi Lude!

an dieser Stelle der Tipp, dass es sich bewaehrt hat DB-eindeutige Spaltennamen zu nutzen, die beispielsweise mit einer Praefix oder Suffix versehen sind, also z.B.:

Jo das stimmt, aber in Verbindung mit der Tabelle macht es Sinn... dummerweise sind Schnittstellen für die Tabelle erstellt worden, deshalb sind da gleiche Spaltenbezeichnungen.