Bekomme Inner Joins nicht hin

[mkinzler]

Normalisiert wäre es aber in die andere Richtung.

Eine Revision bezieht sich auf eine Item und nicht umgekehrt.

[Der schöne Günther]

Auch ein Argument. Meine Motivation war eher dass es später evtl. nicht "Item_Rev" sondern nur "Rev" ist. Das eine Revision nicht nur ein Item, sondern evtl. auch Wombatze enthält.

Ich denke sobald ich den Kram halbwegs am laufen habe mache ich noch einmal ein eigenes Thema um die Struktur von euch Profis bewerten zu lassen...

[Jumpy]

Ich finde die Struktur auch Suboptimal, aber sei es wie es sei, ist nicht einfach durch die höchste Rev_ID schon alles bestimmt?

SQL-Code:

Select * From Items
Left Join rev_items b on b.ID=a.rev
Where a.rev=(Select max(rev) From Items Where ID=a.ID)

Rom, viele Wege und so...

[Der schöne Günther]

Ich bin ja noch nicht einmal mit der Syntax klargekommen. Dass man einfach so sagen kann WHERE x = (Query) war mir z.B. auch neu.

Das sieht ja schon beschämend einfach aus und scheint zu gehen.

Warum grade Left Join? Das würde Sinn machen wenn man Items ohne Revision hat, aber die gibt es bei mir nicht 😎

[rokli]

Ja, Normalisierung ist wichtig und gut ... aber manchmal steht sie dem flexiblen und raschen Zugriff auf Daten auch ganz schön im Weg.

[mkinzler]

Ich sehe in diesem Fall nicht das Problem der Normalisierung sondern das Design der Tabellen

[Der schöne Günther]

Ok, wir haben schon jetzt ein handfestes Problem? Dann helft mir bitte doch am besten jetzt 😓

[MichaelT]

Du bist nicht allein. Viele denken so (kompliziert).

Diese Syntax bis Oracle 8i herausgebracht waren Subqueries schweineteuer. Die waren ähnlich teuer wie die Verwendung von Aggregatfunktionen. Ein Primary Key muss nicht als Index abgebildet werden und ein Foreign Key nicht als Constraint.

Es gibt einen gewaltigen Unterschied zwischen Record und Pageserver würde man heute sagen. Oracle hat schon immer viel Blöcke gepfuffert. (Der Block wurde in einer Art in der DB angesiedelten 'Middle Tier' in Eigenverantwortung verwaltet aka. as SGA).

Mit der Zeit wurden diese Themenkomplexe verheiratet und die Syntax einerseits entwicklerfreundlicher und benutzerfreundlicher zugleich. Die Aussage 'Ich kenne mich in SQL aus' ist gleichzustzen mit der Aussage der Bürokraft 'Ich kenne mich in Excel aus'. Well it depends.

Der Entwickler sitzt vor zwei Syntaxwelten und der User unterschrieb eine EDV-Anforderung. Bei Correlated Subqueries ist eigentlich bezogen auf die Beschreibung der Ergebnismenge die Magic teils verwirrend. (reingepfrimmelt)

---

Zur SQL Query. Im Regelfall geht es immer einfach(er). Viele Wege führen nach Rom und auf den meisten läuft man mit der Kirche ums Kreuz.

In den 90ern und hernach war ein Wettlauf um den 'besten' Optimizer. Auf einmal verschwanden die ganz normalen Queries bei denen es nicht viel zu optimieren gab aus dem Licht der Öffentlichkeit.

Ähnlich wie in Delphi das Wunder einer Ereignisbehandlung wird keiner mehr explizit wieder hinschreiben.

Stammdaten sind Prüftabellen die im Rahmen der E/R Bewegung und auch schon zuvor mit einer Semantik belegt wurden.

• NULL kann man auch eine Semantik verpassen.
• Fremdschlüssel muss man nicht als Constraint abbilden.
• Der Constraint prüft auf die Zugehörigkeit eines Werts zu einer Domäne (enum). Sobald du Enumeration in Listen verwalten musst, dann frohlockt die Prüftabelle.
• Die Liste ist beliebig verlängerbar ....

Der Zeitbezug hielt ob der verfügbaren Plattengrößen Einzug ist aber in E/R nicht explizit reflektiert. Der lebt in der Art der Modellierung als Beziehung. An sich gibt es einfach keine Stammdaten. Es gibt Datensätze ohne Zeitbezug die als solche angesehen werden. Eigentlich sind die Kopiervorlagen und genau das passiert beim herankarren aus den Transaktionsdaten im Rahmen der Auswertungen.

Relationale DBs waren zu Beginn aus der technisch Sicht einfach logische Überbauten über Files. Damals wurden in einer Art Middle-Tier Datenpuffer zu Transaktionsbeginn befüllt und im Rahmen einer 4GL orientierten Programmierwelt im Business einfach die Prüfungen in der Transaktion vorgenommen. 'SQL' lief im Hintergrund.

Zu Beginn wurden einfach Dokumente genommen und in Tabellen abgebildet. Aus dem entstand die Normalisierung. Aus der Normalisierung erwuchs Entity Relationship. Zu Beginn war der Fokus auf den Daten und deren Strukturen. Auf dem Weg wurde immer mehr Semantik in das Modell gepackt. SQL ist die Semantik schlicht und ergreifen egal.

Was ist NULL? In einem File wurden mit der Zeit zusätzlich Informationen abgebildet die zuvor nicht da waren und je nach Datensatzart befüllt. Die neue Information wurde einfach hinten drangehängt. Die Werte waren in den alten Datensätzen nicht vorhanden. Damit wurde der Record im die im Programm wurden gehalten in C - was wohl? Undefiniert.

Zitat von Der schöne Günther:

Ich bin ja noch nicht einmal mit der Syntax klargekommen. Dass man einfach so sagen kann WHERE x = (Query) war mir z.B. auch neu.

Das sieht ja schon beschämend einfach aus und scheint zu gehen.

Warum grade Left Join? Das würde Sinn machen wenn man Items ohne Revision hat, aber die gibt es bei mir nicht ��