[thesecondjoker]

hi leuts,

habe ein abfrageproblem. Ich weiss wo der fehler liegt in meiner abfrage, weiss allerdings nicht wie ich ihn beheben kann.
hab zwei miteinander verknüpfte tabellen. in der einen stehen druckerpatronen und druckköpfe drin und in der anderen das druckermodell, welches die entsprechenden patronen haben kann. hierbei muss berücksichtigt werden, dass ein druckermodell mehrere patronen haben kann (sw,color,photo + druckköpfe).

die tabellen sehen folgendermaßen aus:

table patronen
patronenid serial not null primary key,
modellbezeichnung varchar(20) not null,
kurzbezeichnung varchar(5),
farbe varchar(10)

table druckermodell
druckermodellid serial not null primary key,
modellbezeichnung not null,
typ varchar(20),
patrone_sw_id integer -> patronen.patronenid,
patrone_color_id integer -> patronen.patronenid,
patrone_photo_id integer -> patronen.patronenid
druckkopf_sw_id integer -> patronen.patronenid

usw.

meine abfrage dazu sieht so aus:

SELECT 
druckermodell.modellbezeichnung,
druckermodell.typ,
patronen.modellbezeichnung AS patrone_sw,
patronen.modellbezeichnung AS patrone_color,
patronen.modellbezeichnung AS patrone_photo,
patronen.modellbezeichnung AS druckkopf_sw
FROM
druckermodell LEFT OUTER JOIN patronen(
patronen.patronenid = druckermodell.patrone_sw_id AND
patronen.patronenid = druckermodell.patrone_color_id AND
patronen.patronenid = druckermodell.patrone_photo_id AND
patronen.patronenid = druckermodell.druckkopf_sw_id AND)
  

ich denke, dass das problem ist, dass er die daten nicht den spalten zuordnen kann. mache ich den join mit AND, dann müssen die werte für patronen alle gleich sein. mache ich den join mit OR, bekomme ich für jede unterschiedliche id nen datensatz geliefert.

kann mir bitte einer helfen, möglichst schnell...pls


greets
tsj

[WarrenFaith]

patrone_sw_id integer -> patronen.patronenid,
patrone_color_id integer -> patronen.patronenid,
patrone_photo_id integer -> patronen.patronenid
druckkopf_sw_id integer -> patronen.patronenid

sorry aber das ist doppelte datenhaltung. mach lieber in tabelle patronen ein feld, in dem der typ der patrone hinterlegt ist (das wieder auslagern in eine extra tabelle)

mit der normalisierten struktur sollte deine abfrage auch wesentlich leichter werden (schau dir mal das Stichwort "Normalisierung" an)

kurzer abriss:

table patronen
id
modell
kurz
farbe
patronentyp_id -> patronentyp.id

table patronentyp
id
Typ

table druckermodell
id
modell
typ_id -> druckertyp.id
patrone_id -> patronen.id

table druckertyp
id
Typ

Dann Tabelle Druckertyp/Patronentyp mit Werten füllen und ni den eigentlichen Tabellen nur noch die IDs aus den beiden Tabellen nutzen.

//edits beendet

[thesecondjoker]

also mit normalisierungen musste ich mich leider schon genug beschäftigen.

wäre es nicht dann immer noch einfacher bzw. sinnvoller, wenn ich aus der einen tabelle patronen 7 stk. machen würde?

patronen_sw
patronen_color
patronen_photo
druckkopf_sw
druckkopf_cyan
druckkopf_magenta
druckkopf_yellow

ich sehe letztendlich keine großen sinn in deiner änderung. schon mal was davon gehört, dass man sich totnormalisieren kann? ich würde nicht unbedingt bis zur 6. normalisierung gehen!

also das bringt mir nun keine änderung. wenn ich das richtig verstanden habe, hast du mir die tabellen nur nochmal normalisiert! dadurch könnte ich aber die abfrage so immernoch nicht nutzen!
mir würde dazu nur noch einfallen die tabellen in die farben zu trennen!

[WarrenFaith]

du machst doppelte datenhaltung, wenn du deine tabellen einfach nur xmal erstellst. normalisierung hat nunmal den effekt der großen dynamik und der verhinderung der doppelten Datenhaltung. Überleg dir dann mal, wie oft du deine programmierte Patronensuche neu anpassen musst, blos weil ein neuer Patronentyp auftaucht?!
ich werde jedenfalls nicht dazu beitragen, dass uneffektive Datenbanken erstellt werden.
solltest du dich doch eher an die korrekte vorgehensweise halten und dann probleme haben, bin ich gerne bereit dir zu helfen.

[thesecondjoker]

nu bleib mal locker....

wer redet den davon sich nicht an korrekte vorgehensweisen zu halten? aber sag mir mal bitte was du unter einem patronentyp verstehst. vielleicht reden wir aneinander vorbei. solltest du hier von den druckköpfen und den patronen reden, so muss ich dich nämlich entäuschen! druckköpfe sind in der regel kein patronentyp. ich rede eher von den druckköpfen, wie man sie in officejets von hp vorfindet.

ich werde definitiv keine doppelten daten haben! hätte ich so oder so net, denn selbst wenn die kurzbezeichnung identisch mit einer anderen ist (kommt bei druckköpfen öfters vor), dann unterscheidet die modellnr immer noch jeden tupel, denn diese modellnr ist unique!! da die kurzbezeichnung bekannterweise in der regel nur aus zwei zahlen besteht (z.b. bei hp für die c6615x -> 15), werde ich hierfür nicht eine weitere entität erstellen, das ginge nämlich dann richtung 6. normalisierung...ich gehe bei meinem dbs aber grundsätzlich nur bis zur dritten, alles andere macht in meinen augen keinen sinn.
ich will damit ja nicht sagen, dass du irgendwie mist gemacht hättest, nur sind wir vollkommen vom thema abgekommen.
vorerst habe ich (zumindestens um meine probleme schnell zu lösen) für alle 7 eine entität erstellt, so bekomme ich zumindestens dann meine abfrage sinnvoll hin.

ich bin auch weiterhin für jede hilfe dankbar (auch wenn dies vorgehen nicht jedem als korrekt erscheint -> dann sagt es ruhig, aber bitte vernünftig)


greets
tsj

[WarrenFaith]

falls ich du mein post als aggressiv interpretiert hast oder dich sonstwie angegriffen fühlst, entschuldige ich mich schonmal, das lag nicht in meiner absicht.
Mein problem ist eher, dass Leute, die die Suche nutzen auch diesen Thread finden würden, weshalb ich generell nicht gutheißen kann, dass bewusst auf grundlegendes verzichtet wird.

Ich kann natürlich nur begrenzt in deine Gedankenwelt hineinschauen, aber wenn du der Meinung bist, dass du mit den Entitäten besser fährst ist das soweit ok. Es klang für mich anfangs nur nach "Lernverweigerung".

Also sorry nochmal.

[J33d3X]

PHP-Code:

eine etwas andere herangehiensweise:
zuerst des select statement

$statement = 'select 
  druckermodell.modellbezeichnung,
  druckermodell.typ,
  patronen.modellbezeichnung AS patrone_sw,
  patronen.modellbezeichnung AS patrone_color,
  patronen.modellbezeichnung AS patrone_photo,
  patronen.modellbezeichnung AS druckkopf_sw
from
  druckermodell
left join patronen on patronen.patronenid = druckermodell.patrone_sw_id';

jetzt eine gültige where clausel

$where = 'where 1=1';

jetzt where bedingungen

$where .= "and (
                patronen.patronenid = druckermodell.patrone_color_id
                and
                patronen.patronenid = druckermodell.patrone_photo_id
                and
                patronen.patronenid = druckermodell.druckkopf_sw_id
                )
                ";
                
query basteln

$objSQL->query($statement.$where);

while (fetch_assoc(...))

.... 


wäre dochmal ein ideenansatz ?!

lg
J

[thesecondjoker]

wäre dochmal ein ideenansatz ?!

jo, aber ich wollte nen full join gerne vermeiden! das könnte mal sehr viele daten werden und wenn dann der join (ich nenn den where-join jetzt einfach mal nur join) quasi alles mit allem vergleicht, kann des selbst mit sql ein bissl länger dauern. das möchte ich gerne verhindern, deswegen mache ich lieber explizite joins.

ich habe das problem nun umgangen, wie ich es oben beschrieben habe, also einfach für jede farbenart getrennt. damit ist mir auch schon geholfen und ich habe trotzdem noch keine doppelte datenhaltung, da jede patrone nur einmalig einer entität zugewiesen wird.

[WarrenFaith]

mit doppelter datenhaltung sind nicht nur doppelte einträge gemeint, sondern auch 2 tabellen, die eigentlich zusammengehören.
wenn du einen erfahrenen DBler in deinem Freundeskreis/Schulkreis hast/kennst, dann frag den mal, er wird mir zustimmen

[thesecondjoker]

mit doppelter datenhaltung sind nicht nur doppelte einträge gemeint, sondern auch 2 tabellen, die eigentlich zusammengehören

ach so...das wusste ich nicht. ich dachte das bezieht sich nur auf die redundanz! aber danke für den tipp!