SQL Abfrage bringt out of memory

[Nevada208]

Hallo zusammen,

ich habe eine eigentlich simple Abfrage über 2 Tabellen. In der ersten Tabelle sind Artikeldaten eines Warenwirtschaftssystems.
In der zweiten Tabelle, eine Art Transfertabelle für neue Artikel, sind auch Artikeldaten.

Die zweite Tabelle wird immer mit neuen aktuellen Artikeldaten aktualisiert.

Tabelle1 (nur die relevanten Felder)

Artikelnummer | HerstellerNr | EAN | ExtArtNr

Tabelle2 (nur die relevanten Felder)

HerstellerNr | EAN | ExtArtNr

Die Abfrage soll mir einfach im Ergebnis bringen welche Artikel aus Tabelle 2 schon in Tabelle 1 existieren.

Die Abfrage: select a.Artikelnummer from tabelle1 a, tabelle2 b where a.herstellernr = b.herstellernr

funktioniert ohne Probleme, auch die Abfrage über das Feld ExtArtNr funktioniert

Die Abfrage: select a.Artikelnummer from tabelle1 a, tabelle2 b where a.ean = b.ean

funktioniert nicht, hier liefert das PHP-Script "out of memory"

Das Feld EAN hat in beiden Tabellen den gleichen Datentyp nvarchar, nur die Länge unterscheidet sich.

Um ein sauberes Ergebnis zu haben muss ich aber die EAN der beiden Tabellen vergleichen.

Kann mir jemand sagen wo hier der Fehler ist?

Gruß

[defo]

Die Abfrage: select a.Artikelnummer from tabelle1 a, tabelle2 b where a.ean = b.ean

funktioniert nicht, hier liefert das PHP-Script "out of memory"

Um ein sauberes Ergebnis zu haben muss ich aber die EAN der beiden Tabellen vergleichen.

Kann mir jemand sagen wo hier der Fehler ist?

Out of Memory ist oofenbar kein SQL Problem, sondern clientseitig verursacht, also hier PHP.
Du hast also entweder auf Deinem (Miet-?) Server nicht genug Speicher zur Verfügung, schlecht konfiguriert oder Du hast keine Kontrolle über die Datenmenge, die Du da produzierst.
Da Deine Angaben zu den Referenzspalten und Datenmengen relativ dürftig sind, kann man zum Volumen der Ergebnismenge auch nur spekulieren, ist halt zu groß.
Du könntest mit einem Select count(*) from .. mal abfragen, wieviel da überhaupt raus kommt.
Wenn es eine kleine Menge ist, hast Du vermutlich eher ein Problem, bei der Übernahme des Ergebnis in PHP (Array Dimensionierung), wenn es groß ist (größer als erwartet), dann ist Deine Selektion nicht richtig eingeschränkt, es ergibt Permutationen oder was auch immer.

Und noch was:
"muss ich aber die EAN der beiden Tabellen vergleichen" klingt so, als ob du diesen Vergleich mit PHP machst. Das wäre mit ziemlicher Sicherheit unnötig (Fehlkonstruktion), es sollte ebenfalls per SQL geschehen. Damit wären auch riesige Datenmengen zu bewältigen.

[Nevada208]

Danke für Deine Antwort. Die Datenmenge ist nicht groß, insgesamt ca. 6000 Datensätze in Tabelle2. Wenn ich über die HerstellerNr und ExtArtNr abfrage müsste das Ergebnis ja genau so groß sein.
Es könnte ein paar Einträge geben mit gleichen EAN, das hat damit zu tun das der selbe Artikel als Karton oder als Unterverpackung verkauft wird. Aber das ist die Ausnahme.
Den Vergleich mache ich in SQL.

Ich hab mit select count(*) über 2 Mio Datensätze gezählt, warum auch immer, wenn ich die Hersteller ID mit einbeziehe in die Abfrage klappt es jetzt. Danke

[defo]

Die Datenmenge ist nicht groß, insgesamt ca. 6000 Datensätze in Tabelle2. ..Es könnte ein paar Einträge geben mit gleichen EAN,..Aber das ist die Ausnahme.

Ich hab mit select count(*) über 2 Mio Datensätze gezählt, warum auch immer

Da Du noch nichts zur Datenmenge von Tabelle 1 gesagt hast, bleibt es weiter undeutlich. Aber eine Ergebnismenge von 2 Mio zeigt ziemlich sicher auf eine Permutation.
Das bedeutet, Dir ist die Modellierung (Datenstruktur bzw Abhängigkeit) zwischen den Tabellen nicht bekannt.
Wenn Du vorhanden Referenzen und Abhängigkeiten nicht berücksichtigst, ergibt das solche Phänomene. Das ist "gefährlich". Man kann nicht sicher sein, dass das SQL richtige Ergebnisse liefert.

Die Tatsache, dass Dein SQL nun "funktioniert", weil kein Out of Memory auftritt, ist ein erfreuliches Sympthom, würde mir allerdings nicht reichen.
Ich würde diese Abfrage mit einem SQL Tool ausführen und die Counts auswerten, um die Ursache der Vervielfachung genau zu bestimmen.
Man könnte natürlich auch die Dokumentation des Datenmodels bemühen, sofern soetwas existiert.

Ursache könnte zumindest zum Teil die von Dir bereits genannte Mehrfachnennung der Artikel sein, aber eine "Ausnahme" scheint es wohl nicht zu sein, wenn man damit von 6ooo auf 2 Mio Datensätze kommt.

[Nevada208]

Die Tabelle 1 hat ca 25000 Datensätze. Was ich mir vorstellen könnte das das Ergebnis so groß ist weil nicht alle Einträge eine EAN haben, auch in Tabelle 2 haben nicht alle Einträge eine EAN.

[defo]

Die Tabelle 1 hat ca 25000 Datensätze. Was ich mir vorstellen könnte das das Ergebnis so groß ist weil nicht alle Einträge eine EAN haben, auch in Tabelle 2 haben nicht alle Einträge eine EAN.

"Was ich mir vorstellen könnte" ist eine ziemlich lockere Umschreibung für ..?
Bitte schau Dir mal an, wie Joins genau funktionieren! Das ist nicht irgendwie ein großer Topf, wo mysteriöse Dinge passieren.

Ich frag mich, ob Du nur Vermutungen anstellst oder ob Du es nicht besser weißt. Was auch immer zutrifft, nimms nicht persönlich:

Gerade wenn Du die Join Kriterien in der Where Bedingung unterbringst, statt mit JOIN zu arbeiten, dann erhälst Du eine sehr fest definierte Menge, da outer joins so relativ unmöglich sind (je nach Datenbanksystem). NULL Einträge oder auch leerer Text werden dabei "sogar" separat und explizit berücksichtigt. Und zwar auf jeder Seite, also bei jeder Tabelle.
Besonders spannend ist dabei, auf welcher Seite des Joins dabei "nicht alle Einträge eine EAN" haben!

Du hattest bereits geschrieben, dass einige EAN mehrfach vorkommen. Das würde aus 25000x6000 wahrscheinlich nicht direkt 2 Mio machen. Erst wenn in beiden Tabellen EAN mehrfach vorkommen, nähert sich das Join Ergebnis wahrscheinlich den 2 Millionen.
Wenn aber auf beiden Seiten "einige" leere Werte vorkommen, dann ist das Chaos perfekt. Alle leeren Werte aus jeder Tabelle werden mit allen leeren Werten der anderen Tabelle gemischt.
Dann hat man tatsächlich alles in einen Topf gekippt und noch gut umgerührt.

Wenn Du nun eine Zusatzbedingung definierst, kannst Du das Problem (den Selektionsfehler) natürlich eingrenzen, aber der Fehler ist dadurch nicht ausgeschlossen!

Tu Dir einen Gefallen und schau Dir beide Tabelleninhalte genau an (per SQL).
Wieviel Datensätze sind insgesamt da,
wieviel mit gesetztem Schlüsselfeld,
wieviel mit gesetzter EAN
mache Dich dazu mit outer joins vertraut.