SQL-PHP-Problem

[LenaLuna]

hallo forumer

folgende sache:

wenn ich eine SELECT-anweisung über mehrere tabellen ausführe, dann muss ich ja wenn spalten in verschiedenen tabellen gleich heissen wie folgt vorgehen:

SELECT benutzer.vorname, benutzer.nachname ...

also mit dem punktoperator die tabelle davorsetzen.
soweit sogut.

nun wenn ich jetzt mit der php-funktion mysql_fetch_assoc() mir einen Datensatz hole wie lese ich dann die spalte aus?

bei eindeutigen spalten ist das ja klar

$datensatz["vorname"];
$datensatz["nachname"];

aber wie sieht der zugriff bei nicht eindeutigen spalten aus?

$datensatz["benutzer.vorname"];
$datensatz["benutzer.nachname"];

hätte ich gedacht das dies so geht. leider nicht.

weiss jemand/frau bescheid

gruss LenaLuna

[Cheatah]

Hi,

wenn ich eine SELECT-anweisung über mehrere tabellen ausführe, dann muss ich ja wenn spalten in verschiedenen tabellen gleich heissen wie folgt vorgehen:

...und ihnen mittels AS einen Alias-Namen zuweisen, der dann Eindeutigkeit garantiert.

Cheatah

[LenaLuna]

hallo, Cheatah

ja natürlich die aliase.
die vergesse ich immer wieder.

aber ehrlich. gibt es sonst keine direkte möglichkeit?

danke dir aber trotzdem.

gruss LenaLuna

[Cheatah]

Hi,

aber ehrlich. gibt es sonst keine direkte möglichkeit?

keine Ahnung. Ich halte die Vermeidung solcher Probleme für das in jeder Hinsicht am wenigsten problematische Vorgehen.

Cheatah

[Philipp Hasenfratz]

Halihallo LenaLuna

ja natürlich die aliase.
die vergesse ich immer wieder.

Huhu :-)

aber ehrlich. gibt es sonst keine direkte möglichkeit?

Tjö, Cheatah kann ich zwar zustimmen, dass es bei dir wohl das kleinste Übel ist mit
AS vorzugehen... Einen direkten Weg gibt es IMHO nicht (zumindest bei MySQL). Aber
ich kann dir etwas für die Zukunft anbieten:

Eine gute Nomenklatur der Attribute (a.k.a Namen der Spalten *g*) hilft dir den
Spaltennamen unique auf das ganze System (Datenbank) zu halten und hat sogar den Vorteil,
dass du Tabellen mit Leichtigkeit über NATURAL JOIN's joinen kannst.

einfach für jede Tabelle ein geeignetes (für schreibfaule möglichst kurzes) Präfix
definieren. Foreign Keys haben natürlich das Präfix der referenzierten Tabelle (s.
Tabelle Bestellung mit Foreign Key art_id)

Ein Beispiel:

Kunden

usr_id
usr_name
usr_login
usr_password

Artikel

art_id
art_name
art_price

Bestellung

bst_id
art_id
bst_anzahl

SELECT usr_name, art_name, bst_anzahl FROM Kunden NATURAL JOIN Artikel NATURAL JOIN Bestellung

=> Vorteil: Keine AS in SELECT, da alle Namen eindeutig sind
=> Vorteil: NATURAL JOIN macht den Query schön schlank
=> Nachteil: wer einen findet, soll ihn nennen.

Viele Grüsse

Philipp

[Cheatah]

Hi,

=> Vorteil: Keine AS in SELECT, da alle Namen eindeutig sind

ja.

=> Vorteil: NATURAL JOIN macht den Query schön schlank

Unwichtig.

=> Nachteil: wer einen findet, soll ihn nennen.

Die Namen werden äußerst unhandlich. Konventionen wie z.B. "ID => Primary Key" werden umwandert. Änderungen in Tabellennamen wirken sich auf Spaltennamen aus (okay, ist eher unwesentlich). Bei komplexen Verknüpfungen (die z.B. nicht über nur eine Spalte gehen) weiß am Ende niemand mehr, zu welcher Tabelle eine Spalte eigentlich gehört. Das Prefix einer Spalte, welches ja nun einem Tabellennamen(-kürzel) entspricht, hat nichts mit der Tabelle zu tun, zu der die Spalte gehört.

Ich bevorzuge nach wie vor eine Benamsung, die nur innerhalb der Tabelle eindeutig sein muss; zusammen mit Nomenklaturen, die z.B. "ref_tabelle" oder "ref_tabelle_spalte" als Referenzen vorsehen. Die "[schema.]tabelle.spalte"-Schreibweise mit irgendeiner Nomenklatur unbedingt umgehen zu wollen, halte ich nicht wirklich für sinnvoll.

Cheatah

[Philipp Hasenfratz]

Halihallo Cheatah

=> Vorteil: NATURAL JOIN macht den Query schön schlank

Unwichtig.

Nein. Leserlich. Ich bevorzuge NATURAL JOIN's vor Equi/Theta-Joins. Mit ID als Indikator
für Primary Key verunmöglichst du NATURAL Joins; und das nur, um einer
Konvention zu genügen? - Zudem halte ich ID schon für eine Konvention, bin jedoch der
Meinung, dass ein Prefix nicht ausgeschlossen werden sollte.

=> Nachteil: wer einen findet, soll ihn nennen.
Die Namen werden äußerst unhandlich.

Ja.

Konventionen wie z.B. "ID => Primary Key" werden umwandert.

s. oben. Ob ID, id oder usr_id; ist für mich alles ein Indiz für Primary Key.

Änderungen in Tabellennamen wirken sich auf Spaltennamen aus (okay, ist eher unwesentlich).

Dennoch, deine Kritik trifft zu.

Bei komplexen Verknüpfungen (die z.B. nicht über nur eine Spalte gehen) weiß am Ende niemand mehr, zu welcher Tabelle eine Spalte eigentlich gehört.

Eben doch! - Genau _wegen_ der Prefixe. Wie kommst du zu dieser Überzeugung?

Das Prefix einer Spalte, welches ja nun einem Tabellennamen(-kürzel) entspricht, hat nichts mit der Tabelle zu tun, zu der die Spalte gehört.

Meinst du die Foreign Key's, welche die referenzierte Tabelle als Prefix verwenden?
Nun, stimmt, hier ist die Zugehörigkeit nicht mehr ersichtlich. Aber du vergisst, dass
NATURAL JOIN's im Gegensatz zum Theta- gleichnamige Spalten als _eine_ ausgibt.
Gleichnamige Spalten haben unter Verwendung des NATURAL JOIN's keinen Bezug zu einer
bestimmten Tabelle mehr, ein weiterer Grund prefixe zu verwenden.
Zudem, bei deiner Syntax ist eine Zuordnung überhaupt nicht möglich.

Ich bevorzuge nach wie vor eine Benamsung, die nur innerhalb der Tabelle eindeutig sein muss; zusammen mit Nomenklaturen, die z.B. "ref_tabelle" oder "ref_tabelle_spalte" als Referenzen vorsehen. Die "[schema.]tabelle.spalte"-Schreibweise mit irgendeiner Nomenklatur unbedingt umgehen zu wollen, halte ich nicht wirklich für sinnvoll.

Du hast recht, die "Technologie" darf nicht von einer Namensgebung abhängig sein.
Nur, wenn alle so denken wie du, dann gäbe es den Begriff des NATURAL JOIN's nicht und
dieser ist bei der Relationenalgebra fundamental, stimmt dich das nicht nachdenklich?

Danke für dein Feedback, ich werde zwar bei meiner geliebten (*g*) Notation bleiben, aber
deine Kritik ist gut[1]. Vielleicht noch etwas kleines: Ich verwende diese Notation nicht
ausschliesslich, weil es sich für NATURAL JOIN's etc eigenet; ich finde diese Notation
auch einfach nur "schön".

[1] sehr gut. Du machst mir eine Gegenargumentation schwer ;)

Viele Grüsse

Philipp