Fehler: column ... does not exist

Du weisst aber schon, das correlated subqueries eine miese Performance haben, weil sie den Ausdruck für jeden Tupel des inneren und jeden Tupel des äußeren Queries neu interpretieren müssen?
An deiner Stelle würde ich versuchen, so etwas zu vermeiden.

Wie’s scheint, ist es in komplexeren Projekten völlig unmöglich, portablen SQL-Code zu verfassen.

Willkommen in der Welt der Standards.

Auf irgendein System und dessen Fähigkeiten und Fehler muss man sich festlegen. Tut mir leid, aber MySQL und SQLite sind mir dabei wichtiger als PostgreSQL.

Sie sind dir wichtiger … aber hast du herausgefunden, welche Datenbank sich an den Standard hält und welche nicht?
Wenn sein System jetzt mit Mysql funktioniert aber das Verhalten wirklich nur auf ein oder zwei Datenbanken funktioniert, verschliesst du dir für immer den Weg, deine Anwendung noch mal portabel zu gestalten.

Die Alternative wäre die, die Sub-Abfrage in meiner PHP-Anwendung selbst zu implementieren. Und da wird ein nativ compiliertes Programm wie ein Datenbankserver wohl hoffentlich schneller sein. Die Zeilen, die für diese Abfrage infrage kommen, sollten nie allzu viele sein. Aber Performancetests mit vielen Daten stehen in der Tat noch aus.

aber hast du herausgefunden, welche Datenbank sich an den Standard hält und welche nicht?

Ja: Keins. Also orientiere ich mich als zweites Kriterium eben an der Verbreitung der Systeme. (Keiner der großen bekannten in DE bietet PostgreSQL an, während MySQL und SQLite mittlerweile überall zu haben sind.)

@akretschmer

Bezüglich des zitierens meines Text im Beitrag post9246 solltest Du folgende Rechtsauffassung mal lesen:



fristo

Du könntest (musst aber nicht) einfach mal versuchen, dein eigenes angesprochenes Posting mittels der Zitierfunktion zu zitieren und dann die Vorschau betrachten. Du wirst erstaunt sein, was dabei herauskommt.

Du kannst natürlich auch gleich mit Paragrafen und Gesetzen um dich werfen. Meiner Meinung nach hat akretschmer schlicht nicht mitbekommen, dass die Forensoftware einen Teil deines Beitrages beim Zitieren unterschlägt.


Was soll das zum Schluss werden, wenn wir uns gegenseitig Vorschriften an den Hals hängen. :angry: :angry: :angry:

Habe ich überhaupt kein Interesse dran. Nur im fehlenden Zitat stand nur (zufälligerweise) die Begründung für den Rest meines Textes und die Beantwortung seiner Frage drin. Das technische Problem war mir unbekannt. Soviel zum Thema.



fristo

Jungs! Ruhig bleiben. Sowas muss man nicht hier schreiben. Wenn Ihr interne Differenzen habt, macht das bitte per PM aus. Bei Problemen mit einem Post kann dies auch mir mitgeteilt werden und ich kann ggf. hier Änderungen durchführen.

cu tb.

  1. ist das hier der flasche Ort, um über Rechtsauffassungen zu diskutieren
  2. hab ich das auch nicht vor
select title, year from files AS aaa
group by title, year
having EXISTS (SELECT year FROM aaa);

hier haben wir IMHO ein Henne-Ei-Problem mit der Tabelle aaa. Man wird daraus nicht selektieren können (das in der Klammer) solange diese Tabelle nicht existiert (das vor der Klammer).

Außerdem kann ich, wenn ich Deinem Link folge, und mit den von mir gewählten Einstellungen für die Forensoftware, nur das Ursprungsposting sehen. Ich weiß nicht wirklich, was Du meinst. Aber ich glaube, wir sollten uns nicht streiten.

Andreas

Der Datentyp boolean und boolean_expression sind einfach was unterschiedliches, genau wie HAVING und WHERE völlig unterschiedlich sind.

Nö.
Einfach mal die Abarbeitungsreihenfolge der SQL-Befehle beachten.

FROM (wählt die Tabelle aus (kartesisches Produkt))
WHERE (Filtern der Zeilen gem. Bedingung (Auswahl))
GROUP BY (Bildet Gruppen von Zeilen gem. Bedingung)
HAVING (Filtern der Gruppen gem. Bedingung (Auswahl))
SELECT (Gibt Spalten für Anzeige an (Projektion))
ORDER BY (Sortierung der Zeilen für die Ausgabe)
OFFSET, LIMIT