MySQL: Anzahl der Tabellen im Query

[Bär]

Hallo Forum,

ich habe mir ein kleines SQL-Tool programmiert. Nun möchte ich, abhängig von der Anzahl der abzufragenden Tabellen in meinem dynamischen SQL-Query, eine Aktion ausführen. Wie also kann ich herausfinden, wieviele Tabellen in meinem SQL stecken?
Ich benutze PHP 5 und MySQL 5.

Natürlich könnte ich mit PHP alles was nach "FROM" steht filtern - aber vielleicht gibt es da eine bessere Lösung.

MfG
Bär

[Ilja]

yo,

Natürlich könnte ich mit PHP alles was nach "FROM" steht filtern - aber vielleicht gibt es da eine bessere Lösung.

dazu müsstest du erst mal genauer spezifizieren, was du mit anzahl an tabellen meinst, schließlich können das auch self-joins sein, zählen die dann als eine tabelle oder zwei, was ist mit unterabfragen, UNIONS....fragen über fragen.

Ilja

[Bär]

Hi

dazu müsstest du erst mal genauer spezifizieren, was du mit anzahl an tabellen meinst, schließlich können das auch self-joins sein, zählen die dann als eine tabelle oder zwei, was ist mit unterabfragen, UNIONS....fragen über fragen.

Ich stelle mir das so vor: Ich bekomme (wie auch immer) eine Liste (Array o.ä.) mit allen Tabellen, die "angefasst" wurden. Dort filtere ich doppelte Einträge heraus, und zähle dann deren Anzahl.

Self Joins können demnach auch als 2 Tabellen gelten, das ist mir egal. Wenn meine Lösung das vorsieht, dann filtere ich eben die doppelten Eitnräge heraus.

Also meinentwegen so:

(als String)
Bestellungen, Bestellungen, Positionen, Kunden

=

[0] Bestellungen
[1] Bestellungen
[2] Positionen
[3] Kunden

=

[0] Bestellungen
[1] Positionen
[3] Kunden

=

count()

=

3

Wie genau die Lösung aussieht, ist mir relativ egal. Eine PHP/MySQL-Funktion dazu gibts wohl nicht, oder?

MfG
Bär

[dedlfix]

echo $begrüßung;

Wie genau die Lösung aussieht, ist mir relativ egal. Eine PHP/MySQL-Funktion dazu gibts wohl nicht, oder?

Es gibt EXPLAIN.

echo "$verabschiedung $name";

[Sven Rautenberg]

Moin!

Natürlich könnte ich mit PHP alles was nach "FROM" steht filtern - aber vielleicht gibt es da eine bessere Lösung.

Wenn du deine JOINs bislang nur durch Tabellenaufzählung hinter FROM realisiert hast, dann produzierst du dir sowieso einige Probleme.

Erstens: Deine SQL-Querys werden unübersichtlicher.
Zweitens: Du kannst nicht alle JOINs realisieren, die es gibt.
Drittens: Du kannst ggf. auch nicht an der Performance optimieren, weil diese Art der SQL-Formulierung nicht flexibel genug ist.

Überhaupt finde ich es ungewöhnlich, dass irgendein Programm auf die Anzahl der verwendeten Tabellen reagieren soll. Was programmierst du da?

- Sven Rautenberg

[Bär]

Hallo Sven,

Wenn du deine JOINs bislang nur durch Tabellenaufzählung hinter FROM realisiert hast, dann produzierst du dir sowieso einige Probleme.

ich verstehe deinen Beitrag nicht. Selbst im kompliziertesten SQL-SELECT stehen nach FROM die Tabellen, egal ob mit JOINs, mit AS... Natürlich können auch Subselects vor FROM kommen, das sehe ich ein - aber JOINS vor FROM habe ich noch nie gesehen.

Überhaupt finde ich es ungewöhnlich, dass irgendein Programm auf die Anzahl der verwendeten Tabellen reagieren soll. Was programmierst du da?

Das was ich programmiere, ist eine Funktion (ähnlich wie phpmyadmin), bei der man Datensätze löschen und editieren kann. Wenn mehr als zwei Tabellen benutzt wurden, kann man diesen Datensatz logischerweise nicht bearbeiten.

Ich merke gerade, dass das aber im Widerspruch mit GROUP BY stehen könnte:

SELECT Hersteller
FROM Artikel
GROUP BY Hersteller

oder

SELECT count(*)
FROM Kunden

In beiden Statements wird nur eine Tabelle benutzt, aber das Ergebnis lässt sich trotzdem nicht bearbeiten.

Ich bräuchte jetzt also einen Mechanismus, der mir sagt: "Ja, diesen Datensatz kannst du bearbeiten und löschen" oder "Nein, das kannst du nicht bearbeiten, geschweige denn löschen, weil...".

Lg
Bär

[Sven Rautenberg]

Moin!

»» Wenn du deine JOINs bislang nur durch Tabellenaufzählung hinter FROM realisiert hast, dann produzierst du dir sowieso einige Probleme.

ich verstehe deinen Beitrag nicht. Selbst im kompliziertesten SQL-SELECT stehen nach FROM die Tabellen, egal ob mit JOINs, mit AS... Natürlich können auch Subselects vor FROM kommen, das sehe ich ein - aber JOINS vor FROM habe ich noch nie gesehen.

Ja, aber es gibt halt zwei verschiedene Arten:

SELECT whatever FROM user, accounts, rights, documents WHERE join_bedingungen AND andere_bedingungen

Das ist die schlechte Variante.

Oder eben explizite JOINs:

SELECT whatever FROM user INNER JOIN accounts ON user.id = accounts.user_id INNER JOIN rights .....
 WHERE andere_bedingungen

»» Überhaupt finde ich es ungewöhnlich, dass irgendein Programm auf die Anzahl der verwendeten Tabellen reagieren soll. Was programmierst du da?

Das was ich programmiere, ist eine Funktion (ähnlich wie phpmyadmin), bei der man Datensätze löschen und editieren kann. Wenn mehr als zwei Tabellen benutzt wurden, kann man diesen Datensatz logischerweise nicht bearbeiten.

Das finde ich alles andere als logisch. Das Wesen eines JOINS ist ja, dass mehrere Einträge aus der einen Tabelle in einer direkten Beziehung zu einem Eintrag einer anderen Tabelle stehen. Aufgelöst in einer vernünftigen Admin-Oberfläche würde solch eine Beziehung erkannt werden, und die Bearbeitung dieser Datensatz-Konstruktion würde dann selektiv nur die Datensätze aktualisieren, die der Benutzer verändert hat. Das kann bedeuten, dass nur die eine der beiden Tabellen verändert wird, und dass nur ein Teil der Datensätze geändert werden, aber grundsätzlich spricht nichts dagegen, dass alle Tabellen und alle Datensätze geändert werden.

Ich gebe allerdings zu bedenken, dass solch eine universelle Oberfläche einen normalen User eventuell überfordern könnte.

Ich merke gerade, dass das aber im Widerspruch mit GROUP BY stehen könnte:

SELECT Hersteller
FROM Artikel
GROUP BY Hersteller

Gruppierte Ergebnisse kann man nur dann sinnvoll "bearbeiten", wenn Spalten geändert werden, die gruppiert wurden. Spalten mit Aggregatfunktionen sind nicht bearbeitbar. Aber die Grundsatzfrage ist sowieso, warum man das Ergebnis solch eine Abfrage bearbeiten wollen würde.

Ich bräuchte jetzt also einen Mechanismus, der mir sagt: "Ja, diesen Datensatz kannst du bearbeiten und löschen" oder "Nein, das kannst du nicht bearbeiten, geschweige denn löschen, weil...".

Universalität hat ihren Preis. Ich würde in einem Projekt entweder eine wirklich universelle Admin-Oberfläche wie PHPMyAdmin verwenden - und die wirklich nur dem wissenden Admin verfügbar machen, oder eine spezialisierte Oberfläche für den User, um ihn in seinen zu erfüllenden Aufgaben mit maximaler Effizienz zu unterstützen. Das bedeutet aber auch, dass die Oberfläche die Aufgabe genau kennt, deshalb auch das DB-Modell kennt, und aus diesem Grund genau weiss, welche Abfragen auftauchen, und welche Aktualisierungen vorzunehmen sind.

- Sven Rautenberg