Mysql tabellen verküpfen

[Split1989]

Tabelle_1
ID|Name|Geb

Tabelle_2
ID|Von|An


soo ...


Tabelle_1
1247|Split|01.01.1970

Tabelle_2
1|1247|2147

abfrage soll wie fogt aussehen

$ergebnis = mysql_query("SELECT * FROM Tabelle_2 WHERE An = '2147'");
while($row = mysql_fetch_object($ergebnis))
{
echo $row->ID;
echo "|";
echo $row->Von;
}
ausgabe sieht ja jetzt so aus
1|1247
ich will aber das es so aussieht
1|Split
sprich er soll in die tabelle_1 springen und nach dem Namen mit der ID suchen. Geht das mittels eines mysql befehls? oder soll ich eine weitere abfrage machen?

 

[dubberle]

Nur so aus dem Bauch raus würde ich eher

SELECT * FROM Table1 where Tabelle_1.ID=Tabelle_2.An

formulieren.

 

[Split1989]

habs rausbekommen

SELECT t1.Betreff, t1.Datum, t2.UserFirstname, t2.UserLastname FROM tabelle_1 AS t1, tabelle_2 AS t2 WHERE t1.An_ID = '1' AND t2.UserID = t1.Von_ID

 

[leller]

Hallo,

denke noch daran, auf die ID-Felder Indexe zu setzen, damit du keinen Performance-Problemen erliegst.

Viele Grüße aus Berlin

leller

 

[theHacker]

denke noch daran, auf die ID-Felder Indexe zu setzen, damit du keinen Performance-Problemen erliegst.

Jemand, der Strings als IDs verwendet, achtet sicherlich nicht auf Performance

Es empfiehlt sich, JOINs auch wirklich im SQL-Statement als JOIN zu schreiben. Is leichter lesbar, ggf. kann die DB die Abfrage besser optimieren und du hast mehr Möglichkeiten (z.B. bestimmten Index explizit zu wählen).

siehe https://dev.mysql.com/doc/refman/5.0/en/join.html

 

[Split1989]

Jemand, der Strings als IDs verwendet, achtet sicherlich nicht auf Performance

im code selber sind es keine strings ... ist nur ein platzhalter ... aber hast recht das ich nicht auf performance achte ... bin gerade am lernen von php und mysql.

bin für kritik also sehr offen

 

[theHacker]

bin für kritik also sehr offen

Das is gut

• SELECT * ist böse. Im dritten Post hast dus richtig. Warum alles abrufen, wenn du nicht alles brauchst?
• In Post #1 war aber noch ein String. Du zwingst MySQL die ID-Spalte zu einem String zu casten. Danach machst du einen String-Vergleich. Wieso nicht die 2147 als Integer lassen. Immerhin is die ID ja auch ein Integer.
• Ergebnis freigeben! Die Welt geht nicht unter, aber es gehört einfach zu guten Stil, dass immer, wenn du eine Resource anforderst, du sie auch wieder freigibst, wenn du sie nicht mehr brauchst. Post #1 lässt vermuten, dass du das nicht tust.

 

[ice-breaker]

• SELECT * ist böse. Im dritten Post hast dus richtig. Warum alles abrufen, wenn du nicht alles brauchst?

Du bist mir immernoch eine Begründung deiner These schuldig Denn ohne Begründung lasse ich dir diesen "falschen" zu weit holenden Rat nicht durchgehen.

• In Post #1 war aber noch ein String. Du zwingst MySQL die ID-Spalte zu einem String zu casten. Danach machst du einen String-Vergleich. Wieso nicht die 2147 als Integer lassen. Immerhin is die ID ja auch ein Integer.

Ist komplett falsch, auch MySQL konvertiert die Datentypen automatisch, wie es benötigt wird, mit String und Zahlen gibt es 2 Regeln:

1. Spalte ist ein Integer und Wert ein String: Der String wird in einen Integer gecastet um mit der Integer-Spalte vergleichen werden zu können (Index wird genutzt)
2. Spalte ist ein String und Wert ein Integer: Der Integer-Wert wird nicht in einen String gecastet sondern die Spalte in einen Integer, da viele Strings zu einer Zahlen werden können (nicht nummerische zu 0), es wird kein Index genutzt

Wir haben also Fall 1 bei dem einfach nur der Wert in dem SQL-Query einmal gecastet werden muss.

• Ergebnis freigeben! Die Welt geht nicht unter, aber es gehört einfach zu guten Stil, dass immer, wenn du eine Resource anforderst, du sie auch wieder freigibst, wenn du sie nicht mehr brauchst. Post #1 lässt vermuten, dass du das nicht tust.

Mikro-Optimierung, 90% der Anfragen werden ineffizienter sein als man durch das Freigeben der Ergebnisdaten wieder gewinnt. Außerdem nur wirklich relevant um den Speicherverbrauch gering zu halten, nice to have aber weit weg von einem muss oder können/sollen.
Sinnvoller wäre sogar unbuffered Queries zu nutzen, als die gebufferten MySQL-Funktionen, macht aber auch niemand ...



Ein Rat von mir: Nutze nicht mehr ext/mysql, das ist einfach total veraltet. Es gibt mittlerweile mysqli und PDO, welches beides weit bessere Alternativen sind, alleine schon dank dem mysqlnd-Connector in PHP 5.3

 

[Graccem]

Ein Rat von mir: Nutze nicht mehr ext/mysql, das ist einfach total veraltet. Es gibt mittlerweile mysqli und PDO, welches beides weit bessere Alternativen sind, alleine schon dank dem mysqlnd-Connector in PHP 5.3

Ich würde gleich auf PDO setzen, da man dann unabhängig von der Datenbank ist. Wer weiß, wie lange es noch (die freie Version von )MySQL geben wird...

 

[ice-breaker]

Wer weiß, wie lange es noch (die freie Version von )MySQL geben wird...

MySQL steht unter der GPL, da wird auch Oracle nix ändern können, denn dann müsste man erst die Erlaubnis von allen anderen Entwicklern einholen, die lizenz ändern zu dürfen.
Und nebenbei sind Forks wie der Percona Server oder MariaDB meiner Meinung nach aktuell sogar sowieso besser, da die Entwicklung schneller geht und man viele Patches aus der Community integriert, womit sich Oracle sehr schwer tut.

An den Grund das RDBMS zu wechseln dachte ich auch früher mal, aber man wird in dem Moment soviele Dinge korrigieren müssen (abweichende SQL-Syntax), dass es durch ein einfaches Auswechseln des PDO-Treibers sowieso nicht klappt, bei dem Grund wären dann ORM-Systeme wie Doctrine2 die beste Wahl.

 

[theHacker]

Du bist mir immernoch eine Begründung deiner These schuldig

Die Begründung steht doch - hab extra an dich gedacht - im Thread:

Warum alles abrufen, wenn du nicht alles brauchst?

 

[ice-breaker]

Es wird sowieso alles abgerufen, da macht es keinen Unterschied ob du eine Spalte weglässt oder nicht. Es wird erstmal ein ganzer Datensatz von der HDD geholt und dann mittels Projektion eben nur die Daten in dem Ergebnis übrig gelassen, die angefragt wurden MySQL braucht somit sogar mehr Zeit um die unnötigen Spalten herauszufiltern. Im Gegenzug werden diese aber natürlich auch nicht übertragen.
So, warum sollte SELECT * nun noch böse sein?


Antwort: Das gilt nur, wenn Text-Spalten in dem Ergebnis drinne sind, da kann es sich dann in wenigen Fällen ein wenig negativ auswirken, da will ich nun aber nicht zu tief reingehen, in 99% der Fälle ist es absolut irrelevant.

 

[Graccem]

MySQL steht unter der GPL, da wird auch Oracle nix ändern können, denn dann müsste man erst die Erlaubnis von allen anderen Entwicklern einholen, die lizenz ändern zu dürfen.

Es geht doch gar nicht um eine Lizenzänderung. Es reicht doch schon, wenn die Entwicklung eingestampft wird bzw. nur noch für die kostenpflichtige Variante gemacht wird. Was willst du dann machen? Was passiert, wenn die Entwickler gar nicht mehr an MySQL arbeiten wollen, weil Oracle dahinter steht? Beispiel hierfür wäre eindeutig OpenOffice/LibreOffice. Da fasse ich mir als Anwender eindeutig an den Kopf...

 

[transversalis]

So, warum sollte SELECT * nun noch böse sein?

SELECT * ist spätestens dann böse, wenn Daten sortiert werden müssen, weil dann unnötig Platz und Zeit verbraten wird ( und ja, auch ein JOIN kann intern bereits einen Sortiervorgang auslösen ).
SELECT * kann auch dazu führen, dass Daten unnötigerweise aus einer Tabelle gelesen werden müssen, obwohl für die wirklich benötigten Daten ein Indexzugriff reichen würde

Und wenn in mehreren angesprochenen Tabellen der gleiche Spaltenname vorkommt, kann SELECT * zumindest zu Verwirrung führen.

Bei statischem SQL kann SELECT * auch noch weitere negative Auswirkungen auf Programme haben.

kurz gesagt: SELECT * IST böse

 

[ice-breaker]

Es reicht doch schon, wenn die Entwicklung eingestampft wird bzw. nur noch für die kostenpflichtige Variante gemacht wird. Was willst du dann machen? Was passiert, wenn die Entwickler gar nicht mehr an MySQL arbeiten wollen, weil Oracle dahinter steht?

Da sind schon Unmengen bzw. teilw. die wichtigsten weg
Und Arbeiten jetzt bei Percona (Percona Server), der neuen Firma des MySQL Gründers (MariaDB), SkySQL.
Oracle kann die Zukunft nur von dem Original MySQL kaputt machen, die Forks sind nicht tötbar, und dort arbeiten mittlerweile Unmengen Ex-MySQL Arbeiter.
Man könnte fast sagen, dass die ganzen MySQL-Entwickler zu Monty oder Percona abwandern, und die Support-, Training- usw. Leute zu SkySQL.

[...]

Ja das sind weitere Punkte, wenn theHacker seine Aussagen jemals begründen würde, habe ich ja auch nichts dagegen, ich habe ja auch gesagt, dass es im Grunde stimmt. Aber einfach zu sagen, dass es böse ist weil man mehr abfragt, als man benötigt ist einfach eine absolut unzureichende Erklärung um zu erklären, warum man etwas nicht nutzen sollte.

 

[transversalis]

... wenn theHacker seine Aussagen jemals begründen würde ...

Volle Zustimmung. Bei theHacker hätte ich mir auch schon öfters einen verbose-Modus gewünscht.
Aber
>theHacker +v
funktioniert leider nicht