nicht angemeldet
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