Hallo Ilja,
SELECT
ID,
Heim,
Gast,
ToreHeim,
ToreGast,
UserID,
UserName
FROM
spieltag
CROSS JOIN
users
ON
aktiv = true AND spieltag = 1
>
> ich kann mich täuschen, aber müsste hier nicht ein INNER JOIN anstelle des CROSS JOIN stehen ?
vermutlich. Hab' gerade kein MySQL zur Hand und MS SQL Server mag keinen CROSS JOIN.
> > ~~~sql
SELECT
> > st.ID,
> > st.Heim,
> > st.Gast,
> > st.ToreHeim,
> > st.ToreGast,
> > u.UserID,
> > u.UserName,
> > t.TippToreHeim,
> > t.TippToreGast
> > FROM (
> > spieltag st
> > JOIN -- auf CROSS kann man verzichten
> > -- dann verstehen's mehr SQL-Dialekte
> > users u
> > ON
> > aktiv = true AND spieltag = 1)
> > LEFT JOIN
> > spieltagtippen t
> > ON
> > u.UserID = t.IDSpieler
> > AND
> > st.ID = t.IDSpiel
> >
~~~ [1]
>
> hmm, ich habe leider keine datenbank, um es zu testen, aber zum einen wundert mich, dass du für die unterabfrage in der FROM klausel keinen aliasnamen brauchst und die inneren alias namen außen benutzen kannst. aber scheint offenbar so zu gehen.
Hab' keine Unterabfragen, nur hübsch geklammerte Joins - das kann auch Oracle :-)
> was mich aber noch mehr verwundert, fehlt da in der LEFT JOIn Bedinung nicht nich eine bedinung, nämlich der bgleich zwischen spieltag und spieltagtippen ?
Die fand' ich wie Du redundant - und hab' sie daher weggelassen. Spieljahr hatte ich - wie Du - ebenfalls vermisst, aber mir ging's vorrangig um das Prinzip, das [Du ja erwähntest](https://forum.selfhtml.org/?t=194705&m=1302337):
> > es gibt verschiedene möglichkeiten das zu lösen, zum beispiel mit deinem crossecheck in kombination mit mehreren korrelierten unterabfragen in der projektion oder aber mit joins und eine geschickt gewählten ON klausel.
Für die praktische Umsetzung denke ich, dass Dein Vorschlag
> > was du letzlich willst sind teilnahmen abbilden, sprich unabhängig davon, ob ein aktiver user einen tipp abgegeben hat oder nicht, hat er doch bei jedem saisonspiel eine teilnahme und diese solltest du auch persistieren.
sinnvoll ist. Dabei können bei einem Einsteigen während der Saison gleich alle Teilnahme-Datensätze erzeugt werden (ob für die gesamte Runde oder nur für die zukünftigen Spiele, wäre noch zu überlegen) - und somit gäb's später nur noch hübsche einfache UPDATE- und SELECT-Anweisungen. Das dürfte zu einfacherer Anwendungslogik führen und die paar Kilobyte "unnötig" belegten Plattenplatzes bereiten mir in Zeiten der Terabyte-Platten keine Kopfschmerzen mehr.
Freundliche Grüße
Vinzenz