SQL Query

[Kirby.exe]

Also ich soll ein Query schreiben und verstehe nicht so wirklich wie ich das anstellen soll xD

Hier ist die Aufgabe für das Query:

Gesucht sind alle Komponisten in der Datenbank, die Zeitgenossen von Wolfgang Amadeus Mozart sind, deren Lebenszeit also mit der von Mozart u ̈berlappt. Es sol- len dabei auch Komponisten ausgegeben werden, die in dem Jahr gestorben sind, in dem Mozart geboren wurde, bzw. die in dem Jahr geboren wurden, in dem Mozart

gestorben ist (wenn die Uberlappung also etwas grenzwertig ist).
”Wolfgang Amadeus Mozart“ selbst soll in der Auflistung nicht erscheinen. (Sie können voraussetzen, dass Name und Vorname des Komponisten zusammen einen Alternativ- schlu ̈ssel darstellen, dass es also nicht zwei verschiedene Eintra ̈ge mit gleichem Namen und Vornamen gibt.)
Geben Sie Name, Vorname, Geburts- und Todesjahr der Komponisten aus, sowie das ”Alter“ des Komponisten im Geburtsjahr von Mozart (das kann natu ̈rlich negativ sein, wenn der andere Komponist erst nach Mozart geboren wurde).
Sortieren Sie die Ausgabe nach dem Geburtsjahr, bei gleichem Geburtsjahr nach dem Todesjahr.
Sie dürfen nicht die Lebensdaten von Mozart in die Anfrage einsetzen. Zwar werden die sich nicht mehr a ̈ndern, aber der Name ”Wolfgang Amadeus Mozart“ soll nur ein Beispiel sein. Ihre Anfrage könnte z.B. spa ̈ter in einem Programm verwendet werden, mit Parametern für den tatsächlichen Namen.

Meine Überlegungen hierzu:

Um zu filtern welche Personen in dem Zeitraum gelebt haben, muss ich doch genaue Daten der Person haben. Jedoch steht doch in der Aufgabe, dass ich die Lebensdaten nicht hardcodieren darf...Wie kann man es denn sonst machen?


Das DB Schema sieht wie folgt aus:



Zur Erklärung:

Unterstrichene Werte bedeuten, dass dies ein Primärschlüssel ist. Wenn ein Wert mit einem Pfeil auf eine andere Tabelle zeigt, dann ist dies ein Fremdschlüssel.

Ich bedanke mich schonmal für eure Hilfe im vorraus

 

[kneitzel]

Du die Daten doch in der Datenbank:
- Also kannst Du den Eintrag von Wolfgang Amadeus Mozart heraus suchen.
- Mit den Daten kannst Du dann die eigentliche Abfrage machen - Du musst Dir halt nur die Kriterien überlegen, was die genau bedeuten.

Generell hast Du da ja erst einmal zwei Queries. Wie Du diese nun verknüpfen möchtest, sei Dir überlassen. Ich sehe da mehrere Möglichkeiten:
- Einfache Subqueries. Nicht unbedingt schön, aber da Du in der ersten Query genau einen Eintrag suchst, kannst Du die Query ja auch mehrfach als Subquery nehmen um halt die Daten zu bekommen, die Du brauchst. (Die Datenbanken dürften das intern optimieren, so dass die Query nur einmal ausgeführt wird.
- Die Optimierung könnte man der Datenbank abnehmen über ein CTE - dann hätte man eine CTE um z.B. genau diesen Eintrag zu bekommen. Boah - bei dem Gedanken schüttelt es mich gerade etwas ...
=> Die Idee hier ist dann halt, dass man im WHERE subqueries auf die Tabelle oder die CTE hat ...
Man kann aber auch einfach hingehen und sagen: Wir haben ja zwei Quellen - die kann man verbinden: JOIN. Das kann man mit einfachen Queries machen oder falls man eine Datenbank hat, die das WHERE nicht erst filtert und daher meint bei n Datensätzen wirklich n mal n Verknüpfungen prüfen zu müssen: CTE ...

Also das mit dem CTE ist nur eine Spielerei - das wird niemand ernsthaft machen hoffe ich
Ansonsten schau mal, ob Du eine Datenbank hast, de schöne Execution Plans ausspucken kann. zur Not unter Windows MS SQL Server -> Kostenlos in der Developer Edition zu haben und das ist unter dem Strich die Enterprise Edition (nur um es mal zu erwähnen) und kommt mit vielen tollen Tools, die ein Mausschubser nutzen kann zum spielen. -> Also ein Top grafisches Adventure - das kann man toll spielen wenn man Langeweile hat. Und ist auch garantiert nicht so schnell durchgespielt wie andere Spiele, die man teuer kaufen muss
(Generell ist diese Edition nicht notwendig - die Express Edition ist frei nutzbar und reicht selbst in vielen einfachen kommerziellen Projekten aus.
(Der Hinweis kommt einfach nur, weil ich bei MS SQL Server aus Erfahrung weiss, dass es da wirklich einfach einsehbar ist. Das SSMS zeigt das auf Wunsch schön an.)

 

[Kirby.exe]

Vielen Dank für die schnelle Antwort Mich hat es einfach verwirrt, welche Person ich wähle, also wie generisch die Anfrage sein soll xD Aber na dann werde ich mir einfach mal die Daten von Mozart ziehen und dann in meinem main Query verwenden

P.S.: Wir haben eine "wunderschöne" Postgresql Datenbank zur verfügen, welche wir über das Tool Adminer einsehen können xD

 

[kneitzel]

Also wichtig ist, dass das später eine Abfrage ist!

SELECT something FROM somewhere WHERE acolumn IN (SELECT whatever FROM whereever WHERE somethingelse = "foo");

Das einfach mal um ein typisches Query mit Subquery zu zeigen.

Edit_ Postgresql ist gut - Das ist wenigstens eine richtige Datenbank ... (Ich mag mysql nicht - aber das liegt an Zeiten, als diese angebliche Datenbank nicht einmal Foreign Keys konnte ... ach nee ... konnte sie, nur musste man dann vorher das Datenbankformat umstellen auf etwas, das nicht performant oder nicht 100% stabil war oder so ...)

 

[Kirby.exe]

Kann ich das Ergebnis des Subquery auch in einer Variable speichern? Da ich ja schauen muss ob diese Person im Intervall gelebt hat. SOmit bräuchte ich ja zwei Vergleiche und hätte das Subquery doppelt xD

 

[kneitzel]

Nach meinem Verständnis nicht, daher war meine Aussage ja, dass man so ein Subquery mehrfach haben kann und dass die Datenbank das dann schon entsprechend optimieren wird ....

Aber das würde dann ein Script als Ergebnis liefern und nicht ein Query. Sprich du hättest etwas wie:
- Variablen deklarieren
- Erstes SELECT in dem Du die Variablen füllst.
- Zweites SELECT, in dem Du die Variablen verwendest.

Mein Vorschlag wäre - Da du das ja auch lernen willst: Vertiefe es, indem Du mehrere Lösungen baust und dir die Execution Pläne anzeigen lässt.

EXPLAIN

www.postgresql.org

Also ohne und mit CTE

PostgreSQL Common Table Expression (CTE)

This tutorial shows you how to use the PostgreSQL common table expression (CTE) to simplify complex queries.

www.postgresqltutorial.com

Und dann halt mit Subqueries und als JOIN

Die Lösung mit den Variablen kannst Du auch ausprobieren. Wobei ich jetzt nicht weiss, ob das wirklich so funktioniert:

Als erstes die Variablen definieren mit den richtigen typen und dann im SELECT setzen, also sowas wie
WAMGeboren DATE;
WAMGestorben DATE;
SELECT WAMGeboren := geboren, WAMGestorben := gestorben FROM ...... WHERE .....;

In MY SQL haben wir sowas schon gemacht, da geht es. Bei Postgresql habe ich diesbezüglich keine Erfahrungen.... (Aber Zuweisung ist da wohl mit := ...)
Das aber auch nur als Übung ...

 

[LimDul]

Ich würde aber auch davon ausgehen, dass es hier nur ein Query sein soll. Man kann Queries ja beliebig schachteln. Ich schon Queries gehabt, die gingen über 3 Bildschirmseiten

Ich persönlich fang bei sowas meist von innen nach außen an.

SELECT k.GESTORBEN, k.GEBOREN FROM KOMPONIST k WHERE k.NAME = "Mozart"

Dann kann man das verschachteln bzw. joinen

SELECT * FROM KOMPONIST k2, KOMPONIST k WHERE k WHERE k.NAME = "Mozart" AND k2.GESTORBEN > k.GESTORBEN AND .... (Hier die Bedingungen fertig formulieren)

 

[kneitzel]

SELECT * FROM KOMPONIST k2, KOMPONIST k

Wobei ich implicit SQL Joins vermeide. Das geht und der Query Optimizer wird daraus das Gleiche machen. Aber es wird bei mehreren Joins einfach unübersichtlich. Und aus Clean Code Sicht bevorzuge ich, dass Dinge immer da sind, wo sie hin gehören und das was zusammen gehört, trennt man nicht....

SELECT ....
FROM t1, t2, t3, t4, t5, t6, ....
WHERE BedingungT1 AND BedingungT2, AND BedingungT3 AND ...

vs

SELECT ....
FROM t1
JOIN t2 ON BedingungT2
JOIN t3 ON BedingungT3
JOIN t4 ....
WHERE BedingungT1

Aber das nur am Rande. Außer bei Oracle (Oracle - muss man dazu überhaupt noch was sagen? Der Name triggert doch bei vielen direkt den Fluchtinstinkt ...) - da gibt es manch lustiges Erlebnis wo man dann durch geschicktes Umsortieren einen riesen performance-Gewinn erzielen kann ... Das ist etwas, das man bei explicit join vs. implizit join auch finden kann ...

Aber das ist nur eine kleine Anmerkung von meiner Seite. Es ist natürlich korrekt und es funktioniert und hat auch eine normale Laufzeit und der Execution Plan müsste sogar identisch sein (Bei MS SQL schon geprüft).

 

[Kirby.exe]

Also ich habe es jetzt so:

SELECT k2.vorname, k2.name, k2.geboren, k2.gestorben, (k2.gestorben-k2.geboren) as alter FROM KOMPONIST k2, KOMPONIST k WHERE k.NAME = 'Mozart' AND k.vorname = 'Wolfgang Amadeus' AND k2.GESTORBEN >= k.GESTORBEN AND k2.geboren <= k.geboren;

Jedoch spuckt er mir nur Personen mit Mozart im Name aus xD Und zwar nur 2 xD Es werden aber 8 Personen erwartet...xD

 

[kneitzel]

Die Bedingung ist ja auch falsch. Evtl. erst mal sauber in normaler Sprache formulieren, was Du meinst....

Derzeit bekommst Du nur Künstler, die vor Mozart geboren und nach ihm gestorben sind. Und Mozart bekommst Du ebenfalls ...
==> Hier die Logik richtig bestimmen!

Zur Not einfach einmal alle Möglichkeiten, die es gibt, bestimmen:
- Künstler sind vor Mozarts Geburt geboren worden und starben bevor er geboren wurde.
- Künstler sind vor Mozarts Geburt geboren worden und starben nachdem Mozart geboren wurde und bevor er starb.
- Künstler sind vor Mozarts Geburt geboren worden und starben nachdem Mozart starb.
- Künstler sind nach Mozarts Geburt geboren worden bevor Mozart Starb und starben ...... (Hier alle Fälle bilden)
- Künstler sind geboren worden nachdem Mozart starb ... und natürlich starben sie auch, nachdem Mozart starb ...

==> Wenn Du alle Fälle hast, kannst Du die Bedingungen ableiten

 

[mihe7]

In dem Fall hilft es, sich einen Zeitstrahl aufzumalen und die verschiedenen Möglichkeiten einzuzeichnen. Dann findet man sehr schnell eine recht einfache Bedingung heraus.

 

[mihe7]

Für den faulen Studenten

 

[Kirby.exe]

Für den faulen Studenten
Anhang anzeigen 14471

xD Langeweile ? xD Habe es mir vorhin etwas aufgemalt und dann wurde es recht schnell klar

Habe es jetzt so und es funktioniert:

SELECT k2.vorname, k2.name, k2.geboren, k2.gestorben, (k2.gestorben-k2.geboren) as alter FROM KOMPONIST k2, KOMPONIST k WHERE k.NAME = 'Mozart' AND k.vorname = 'Wolfgang Amadeus' AND (k2.vorname || ' ' || k2.name) != 'Wolfgang Amadeus Mozart' and (k2.geboren <= k.geboren AND k2.gestorben >= k.geboren or k2.geboren <= k.gestorben and k2.gestorben >= k.gestorben);

 

[mihe7]

xD Langweile ?

Gut gekontert

 

[kneitzel]

ARGH! Darf ich einen Schreikrampf kriegen?

AND (k2.vorname || ' ' || k2.name) != 'Wolfgang Amadeus Mozart'

In der WHERE Clause bitte nichts aktives machen. Das ist ein absolutes NO GO!

Dieses tolle "Ich baue mir einen String zusammen" bedeutet für den SQL Server, dass dieser absolut KEINE Optimierungen diesbezüglich machen kann. Er kann da bei k2.vorname oder k2.name keine Indices nutzen u.s.w.!

Daher: Mach bitte niemals so einen Scheiß, wenn es nicht wirklich sein muss.

Wenn Du in der WHERE clause bei Feldern filterst, dann ist das eine super Sache, denn da kann der Server ohne viel Aufwand sofort massiv filtern.

Dieses tolle FROM KOMPONIST k2, KOMPONIST k erzeugt erst einmal n^2 Datensätze - so in KOMPONIST n Datensätze sind.
Hast Du da aber über WHERE clauses direkt x und y Datensätze raus geschmissen, dann werden das im nu nur noch (n-x)(x-y) Datensätze. Das können also gleich extrem viel weniger sein. Dazu gehören Felder =, !=, < oder > einer Konstante ... Aber auch direkte Vergleiche mit einem anderen Feld (Das wäre dann das typische JOIN ON mit Feld1 = Feld2 oder so ... ). Da kann eine Datenbank super optimieren und Tabellen mit Millionen Datensätzen schnell verarbeiten ...

Aber wenn man da so Scheiße baut (sorry, für die klaren Worte), dann kriegt man tolle Abfragen hin. Das Problem ist nur, dass die Abfrage wächst ... dann kommt noch eine Tabelle dazu ... und dann noch eine Tabelle .... die Tabellen wachsen ... und intern baut dann die Abfrage ein Result zusammen das extrem viele Datensätze hat .. (halt n1 * n2 * n3 * n4 * .... mit nx die Anzahl der Datensätze aus Tabelle Nr. x).

Und ich würde da ja nichts sagen, wenn ich nicht schon dringend hoch eskaliert Leute unterstützen musste, weil irgendwelche wichtigen Reports nicht mehr liefen ... Da liefen die Abfragen auf Timeouts ... Webseite, wo wir Timeouts hochgesetzt haben, damit der Browser auch nach 20 Minuten noch das Ergebnis angezeigt hat und so ...)

Und nein - die Komplexität war gar nicht so hoch - nach der Optimierung waren die Queries, die über Nacht liefen, weil Laufzeit x Stunden Laufzeit dann so, dass sie nur noch Sekunden liefen!

Da kam noch etwas mehr zusammen ... da wurde massiv Daten zusammen gefügt und dann mit SELECT DISTINCT reduziert ...

Daher noch einmal: Mach sowas nicht! Sorg dafür, dass der Datenbankserver schnell und viel filtern kann ehe er Tabellen verknüpft. Und dann sorge dafür, dass bei der Verknüpfung möglichst wenig Datensätze entstehen.... Das wären die umgangssprachlichen Regeln ...

Und gewöhn Dir JOIN an - das hatte ich vorher schon erwähnt ... dann wäre dein WHERE kleiner weil aufgeteilt...

Das einfach mal als Denkanregung ... und hast Du vor mal diverse andere Dinge auszuprobieren und dir mal Execution Pläne anzusehen? Oder ist es genug, eine Lösung zu haben und man will nicht tiefer einsteigen?

 

[Kirby.exe]

Also ich gebe dir völlig recht, dass dies eine Laufzeitkatastrophe ist xD Leider bin ich gerade mit meinen Modulen so ausgelastet, dass ich es mir zeitlich nicht wirklich leisten kann mich so tief einzuarbeiten Ich werde mich mal in der Weihnachtspause etwas damit beschäftigen

 

[kneitzel]

Also ich gebe dir völlig recht, dass dies eine Laufzeitkatastrophe ist xD Leider bin ich gerade mit meinen Modulen so ausgelastet, dass ich es mir zeitlich nicht wirklich leisten kann mich so tief einzuarbeiten Ich werde mich mal in der Weihnachtspause etwas damit beschäftigen

Also ob Du Dich vertiefst oder nicht ist ganz alleine Deine Sache. Das sind nur Vorschläge, für denn Fall, dass man etwas vertiefen will. Das kann sehr interessant sein, aber ganz klar: Das ist ein Thema für sich und die Frage ist: Willst Du das? Als Entwickler braucht man das nicht zwingend.

Für Das Studium dürfte diese massive Vertiefung nicht notwendig sein und selbst mit entsprechend "schlechten" WHERE Bedingungen wirst Du problemlos durch das Studium kommen. Bei meiner Reaktion schlug bei mir nur die eine oder andere schlechte Erfahrung durch ....

 

[Kirby.exe]

Naja an sich währe es nicht schlecht sich mehr mit SQL zu beschäftigen, da ich gerne in die IT Sicherheit Richtung gehen möchte xD Aber erstmal muss ich step für step machen xD

 

[macaubas]

Hallo Kirby_Sike,
hier meine Lösung:
der innere select definiert alle Datensätze welche die Bedingung nicht erfüllen und der äussere select sucht die Datensätze welche nicht enthalten sind. Auch bei vielen Datensätzen dürfte das kein Timing-Problem sein: Hier die Lösung für Oracle

SELECT KNR FROM TABELLE WHERE KNR  NOT IN(
   SELECT KNR FROM
      TABELLE A,,
      (SELECT GEBOREN, GESTORBEN FROM TABELLE WHERE NAME='Mozart')B
    where
         A.GESTORBEN <= B.GEBOREN  OR  A.GEBOREN >=B.GESTORBEN);

 

[mihe7]

hier meine Lösung:

Die ist zwar auch nicht ganz richtig, aber wie bitte kommst zur Annahme, dass hier kein Problem bzgl. der Geschwindigkeit auftreten sollte? Wenn hier der Query Optimizer nicht gnadenlos zuschlägt, dann ist das so ziemlich das Übelste, was man machen kann: erstmal alles andere auswählen, um dann den kleinen, negierten Rest zu erhalten.

Beispiel: wenn Du die Mozarts dieser Welt haben möchtest, gehst Du doch auch nicht her und sagst: gib mir erstmal die IDs derjenigen, die nicht Mozart heißen und dann such mir alle IDs raus, die darin nicht enthalten sind.

 

[macaubas]

@mihe7:
Ich hab das vorher mit mehr als 1 Mio. Datensätzen von mir probiert, kein Problem bezüglich Geschwindigkeit. Da sind die Datenbanken gescheit genug. Ich hab damit kein Problem.

 

[mihe7]

Wie sieht denn der Ausführungsplan aus?

 

[kneitzel]

Also hier geht es um eine Tabelle! Und 1 Mio ist auch keine wirkliche Größenordnung.

Und selbst wenn es eine Datenbank hin bekommt - egal ob Ressourcen genug da sind (und die DB z.B. genug Hauptspeicher hat) oder der Optimizer es gut hinbekommen hat: Auf die Art und Weise ist die Chance hoch, dass man etwas baut, das der Optimizer eben nicht mehr hin bekommt.

Was spricht dagegen, es von Anfang an ordentlich zu machen? Wenn bei so einfachen, trivialen Abfragen (Sorry, aber darum geht es hier!) solche Lösungen heraus kommen, dann möchte ich nicht wissen, was da bei komplexen Dingen heraus kommen wird ..

Aber ich bin auch schon wieder ruhig und raus.

 

[mihe7]

Jetzt kam mir doch glatt noch der @kneitzel dazwischen

 

[LimDul]

Mit NOT IN / IN / EXISTS hab ich immer in Querys Bauchschmerzen. Je nach dem welche Datenbank man hat, wie gut der Optimzier ist, wie komplex die Querys sind, wie die Indexe verteilt sind kann das performant gehen. Aber ich sehe da immer die Gefahr, dass die Sub-Selects komplett ausgeführt werden müssen nur um eine true/false Bedingung auszuwerten. Manchmal ist das die einzige Lösung, aber ich versuche es eigentlich zu vermeiden

 

[mrBrown]

der innere select definiert alle Datensätze welche die Bedingung nicht erfüllen und der äussere select sucht die Datensätze welche nicht enthalten sind.

Irgendwie erschließt sich mit die Logik dahinter nicht.
Alle Suchen, für die etwas nicht gilt, um dann alle anderen zu suchen (also quasi doppelt negiert) – das geht doch viel einfacher, wenn man einfach direkt alle sucht, für die die Bedingung gilt 🤔

 

[macaubas]

na denn, klar gibt's da die einfachere Lösung:

  SELECT KNR
    FROM
      TABELLE A,
      (SELECT GEBOREN, GESTORBEN FROM TABELLE WHERE NAME='Mozart')B
    where
      NOT( A.GESTORBEN <= B.GEBOREN  OR  A.GEBOREN >=B.GESTORBEN);

 

[kneitzel]

Also ich finde das so immer noch extrem unübersichtlich. Alleine schon, weil die einzelnen Bedingungen wild durcheinander sind.


Warum wehrt ihr euch so gegen ein Join? Ein SELECT ... FROM A, B ist etwas, das ich aus schon genannten Gründen ablehne ...

DECLARE @NAME AS VARCHAR;
SET @NAME = 'Mozart';

SELECT
    A.KNR
FROM
    TABELLE A,
JOIN TABELLE B ON A.GESTORBEN >= B.GEBOREN AND A.GEBOREN <=B.GESTORBEN AND A.NAME <> B.NAME
WHERE
    B.NAME=@NAME;

Davon abgesehen erfüllt Deine Query nicht die Anforderung:
"Es sollen dabei auch Komponisten ausgegeben werden, die in dem Jahr gestorben sind, in dem Mozart geboren wurde, bzw. die in dem Jahr geboren wurden, in dem Mozart gestorben ist" Daher dürfen die Grenzen nicht ausgenommen sein wie bei Dir und der gesuchte Komponist ist separat durch eine WHERE Bedingung zu filtern.

Und da der Name selbst nicht im eigentlichen Query sein soll, ist die Frage, was da gefordert ist. Wobei das jetzt MS SQL Format ist - postgresql mag die Variablen evtl. etwas modifiziert.

Und was da auch noch fehlt: Der Vorname muss auch noch ebenso geprüft werden... Also Variable deklarieren und setzen und dann mit überprüfen sowohl im JOIN als auch in der WHERE Bedingung ...

Edit_ Jetzt habe ich natürlich auch das A und B übernommen ... die sind natürlich auch durch sinnvolle Namen zu ersetzen ... Ansonsten viel Spass bei einer Query in der Du dann von A bis Z durch bist und mit AA, AB, AC, .... weiter machst nur um zu erkennen, dass Du absolut keine Ahnung hast, für was die einzelnen Tabellen stehen

 

[LimDul]

Wobei ich bei Sql-Statements interessanterweise ein Freund kurzer Aliase bin, die sind bei uns in der Regel 1 bis 3 Buchstaben - allerdings haben wir in der Regel fixe Aliase für gewissen Tabellennamen und selten wirklich große Queries (POLICY => p, POLICY_VERSION => pv)

A und B würde aber auch anmeckern, wenn die Tabelle Komponisten heißt, wäre meine Aliase k und k2 bzw. k1 und k2

 

[kneitzel]

Wobei ich bei Sql-Statements interessanterweise ein Freund kurzer Aliase bin, die sind bei uns in der Regel 1 bis 3 Buchstaben - allerdings haben wir in der Regel fixe Aliase für gewissen Tabellennamen und selten wirklich große Queries (POLICY => p, POLICY_VERSION => pv)

A und B würde aber auch anmeckern, wenn die Tabelle Komponisten heißt, wäre meine Aliase k und k2 bzw. k1 und k2

Das handhabe ich ähnlich. Wobei k1 / k2 ist die Verwechlungsgefahr zu groß. War nun k1 mozart und k2 die Elemente, die man möchte? Oder umgedreht? Ok, hier ist es noch eindeutig, da die erste Tabelle vermutlich die für die Ergebnisse ist ... aber statt zahlen hätte ich da dann Kürzel, die einen gleichen Hinweis geben.

Und bei großen Queries sind 2 Zeichen schon recht wenig und daher selbst 3 eher die Ausnahme. Wenn man da mal eben so 20-30 Tabellen reinzieht und dann manche Tabellen womöglich 4 oder 5 Mal. Also Mitarbeiter dann als m1 bis m5 oder so finde ich unschön. Dann ist von der Abkürzung her, der ProjectLead_Mitarbeiter (pl_m), der ChiefDeveloper_Mitarbeiter (cd_m) u.s.w. und dann ist auch direkt klar, welcher Mitarbeiter über welches JOIN rein gekommen ist. pl_m war halt ein join auf den ProjectLead ...

Aber das ist dann etwas, da kann man ja gerne abweichen. Da soll jeder das machen, was er für richtig hält. Ich arbeite auch mit Datenbanken, da sind Tabellen und Spalten alles UUIDs. Das war scheinbar mal eine tolle Sache - denn ich habe zwei unterschiedliche DataLayer "Tools" erlebt, die dies gemacht haben ... Also ich will nicht behaupten, dass es nicht schlimmere Lösungen gibt bezüglich SQL (ich greife da in der Regel nicht per SQL zu, und wenn, dann nur mit Views, die einmal erstellt wurden )

 

[LimDul]

Das handhabe ich ähnlich. Wobei k1 / k2 ist die Verwechlungsgefahr zu groß. War nun k1 mozart und k2 die Elemente, die man möchte? Oder umgedreht? Ok, hier ist es noch eindeutig, da die erste Tabelle vermutlich die für die Ergebnisse ist ... aber statt zahlen hätte ich da dann Kürzel, die einen gleichen Hinweis geben.

Und bei großen Queries sind 2 Zeichen schon recht wenig und daher selbst 3 eher die Ausnahme. Wenn man da mal eben so 20-30 Tabellen reinzieht und dann manche Tabellen womöglich 4 oder 5 Mal. Also Mitarbeiter dann als m1 bis m5 oder so finde ich unschön. Dann ist von der Abkürzung her, der ProjectLead_Mitarbeiter (pl_m), der ChiefDeveloper_Mitarbeiter (cd_m) u.s.w. und dann ist auch direkt klar, welcher Mitarbeiter über welches JOIN rein gekommen ist. pl_m war halt ein join auf den ProjectLead ...

Aber das ist dann etwas, da kann man ja gerne abweichen. Da soll jeder das machen, was er für richtig hält. Ich arbeite auch mit Datenbanken, da sind Tabellen und Spalten alles UUIDs. Das war scheinbar mal eine tolle Sache - denn ich habe zwei unterschiedliche DataLayer "Tools" erlebt, die dies gemacht haben ... Also ich will nicht behaupten, dass es nicht schlimmere Lösungen gibt bezüglich SQL (ich greife da in der Regel nicht per SQL zu, und wenn, dann nur mit Views, die einmal erstellt wurden )

Die Querys mit denen ich zu tun, da sind selbst 5 Tabellen schon viel - da reicht es. Je mehr es wird, um so sprechender muss es logischerweise werden.