Datensatz aus Datenbank in array schreiben

[Kurt]

ich möchte meine Ausgabe aus einer Select Anweisung in einem Array speichern um es öfters inerhalb des Scriptes herzunehmen. Aber wie bekomme ich ORT und LAND noch in meine Datensatz?

$ausgabe= array();
$sql =  "select id, name, ort, land from daten ";
$result = mysql_query($sql);

while($row = mysql_fetch_array($result))
{
$ausgabe[$row['id']] = $row['name'];
}

[M.]

Mahlzeit,

$ausgabe[$row['id']] = $row;

[Auge]

Hallo

ich möchte meine Ausgabe aus einer Select Anweisung in einem Array speichern um es öfters inerhalb des Scriptes herzunehmen. Aber wie bekomme ich ORT und LAND noch in meine Datensatz?

$ausgabe= array();

$sql =  "select id, name, ort, land from daten ";
$result = mysql_query($sql);

while($row = mysql_fetch_array($result))
{
$ausgabe[$row['id']] = $row['name'];
}

  
Die Struktur des Arrays sollte anders sein. Von der DB kommt folgende Struktur:  
  
~~~php
$resultrow[0]['id']  
$resultrow[0]['name']  
$resultrow[0]['ort']  
$resultrow[0]['land']  
$resultrow[1]['id']  
$resultrow[1]['name']  
$resultrow[1]['ort']  
$resultrow[1]['land']  
//…

Diese Struktur sollte auch $ausgabe bekommen. Und da du in den Ergebnissen eh mit den Feldnamen arbeitest, kannst du statt mysql_fetch_array auch mysql_fetch_assoc nutzen.

// Zähler für das Array  
$i = 0;  
while ($row = mysql_fetch_assoc($result))  
  {  
  // Zuweisung  
  $ausgabe[$i]['id'] = $row['id'];  
  $ausgabe[$i]['name'] = $row['name'];  
  $ausgabe[$i]['ort'] = $row['ort'];  
  $ausgabe[$i]['land'] = $row['land'];  
  // Zähler für den nächsten Durchlauf um 1 erhöhen  
  $i++;  
  }

Über kurz oder lang solltest du dir mal mysqli und PDO anschauen, da die alten mysql-Funktionen irgendwann aus PHP rausfliegen. Da die Hoster sich mit den Updates von PHP typischerweise sehr viel Zeit lassen, wird diese Änderung aber nicht morgen oder übermorgen geschehen.

Tschö, Auge

[M.]

Mahlzeit,

// Zähler für das Array

$i = 0;
while ($row = mysql_fetch_assoc($result))
  {
  // Zuweisung
  $ausgabe[$i]['id'] = $row['id'];
  $ausgabe[$i]['name'] = $row['name'];
  $ausgabe[$i]['ort'] = $row['ort'];
  $ausgabe[$i]['land'] = $row['land'];
  // Zähler für den nächsten Durchlauf um 1 erhöhen
  $i++;
  }

  
Ist das dein Ernst? Damit gewinnst du bestimmt den Preis für die aufwändigste Problemlösung ....  
  
~~~php
  
while ($row = mysql_fetch_assoc($result)){  
	// Zuweisung  
	$ausgabe[] = $row;  
}

Macht exakt das Gleiche aber wesentlich kürzer.

[Tom]

Hello,

// Zähler für das Array

$i = 0;
while ($row = mysql_fetch_assoc($result))
  {
  // Zuweisung
  $ausgabe[$i]['id'] = $row['id'];
  $ausgabe[$i]['name'] = $row['name'];
  $ausgabe[$i]['ort'] = $row['ort'];
  $ausgabe[$i]['land'] = $row['land'];
  // Zähler für den nächsten Durchlauf um 1 erhöhen
  $i++;
  }

>   
> Ist das dein Ernst? Damit gewinnst du bestimmt den Preis für die aufwändigste Problemlösung ....  
  

> ~~~php
  

> while ($row = mysql_fetch_assoc($result)){  
> 	// Zuweisung  
> 	$ausgabe[] = $row;  
> }

Macht exakt das Gleiche aber wesentlich kürzer.

Macht nicht ganz das Gleiche.
Besser wäre daher:

  
while ($_row = mysql_fetch_assoc($result))  
{  
    $_ausgabeliste[$_row['id']] = $_row;  
}  

Dann wird die ID zwar redundant geführt, was aber in Anbetracht des eingesparten Aufwandes vertretbar ist. Der OP (TO) wollte ja die ID als Index für seine Ausgabeliste, was auch sehr praktisch ist und daher zu empfehlen.

Selbstverständlich kann man die Redundanz mit einer Zeile mehr auch wieder entfernen:

  
while ($_row = mysql_fetch_assoc($result))  
{  
    $_ausgabeliste[$_row['id']] = $_row;  
    unset($_ausgabeliste[$_row['id']]['id'];  
}  

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Auge]

Hallo

// Zähler für das Array

$i = 0;
while ($row = mysql_fetch_assoc($result))
  {
  // Zuweisung
  $ausgabe[$i]['id'] = $row['id'];
  $ausgabe[$i]['name'] = $row['name'];
  $ausgabe[$i]['ort'] = $row['ort'];
  $ausgabe[$i]['land'] = $row['land'];
  // Zähler für den nächsten Durchlauf um 1 erhöhen
  $i++;
  }

> >   
> > Ist das dein Ernst? Damit gewinnst du bestimmt den Preis für die aufwändigste Problemlösung ....  
>   
> > ~~~php

while ($row = mysql_fetch_assoc($result)){  

> > 	// Zuweisung  
> > 	$ausgabe[] = $row;  
> > }

Macht exakt das Gleiche aber wesentlich kürzer.

Macht nicht ganz das Gleiche.

Was macht es denn anders? Sowohl mein als auch Ms Code erzeugen ein identisches Array. Seiner eleganter als meiner, dafür sieht bei meinem ein Blinder was da geschieht. :-)

Besser wäre daher:

while ($_row = mysql_fetch_assoc($result))

{
    $_ausgabeliste[$_row['id']] = $_row;
}

>   
> Selbstverständlich kann man die Redundanz mit einer Zeile mehr auch wieder entfernen:  
>   
> ~~~php

while ($_row = mysql_fetch_assoc($result))  

> {  
>     $_ausgabeliste[$_row['id']] = $_row;  
>     unset($_ausgabeliste[$_row['id']]['id'];  
> }

Wäre es, einer einheitlichen Struktur wegen, nicht sinnvoller, auf die Verwendung von $ausgabe[]['id'] umzusteigen? Die anderen Felder sind ja auch so erreichbar.

Tschö, Auge

[Tom]

Hello,

Wäre es, einer einheitlichen Struktur wegen, nicht sinnvoller, auf die Verwendung von

  
  
$ausgabe[]['id']  
  

umzusteigen? Die anderen Felder sind ja auch so erreichbar.

Nö.
Man sollte keine neuen Indexe (1) einführen, wo sie nicht mehr notwendig oder sogar kontraproduktiv wären...

$_ausgabe[] = *neuerEintrag*

würde aber für [] bei jedem Schleifendurchlauf ein neues Increment eines Index einführen, der total überflüssig ist.

Ich versuche gleich mal zu zeigen, wie die drei unterschiedlichen Strukturen sich abbilden würden

+++ dauert ein paar Momente +++

(1) --- "Indexe" oder "Indizes"?
Angeblich soll "Indexe" heute erlaubt sein.
Ich hab's gerade mal mit Googlefight versucht, aber das hat bei mir gestreikt

(2) --- Anmerkung am Rande ---
Das "$name" ist meine persönliche Note, wenn Skalare erwartet werden.
Das "$_name" ist meine persönliche Note, wenn Arrays erwartet werden.
Das "$__name" ist meine persönliche Note, wenn Objekte erwartet werden.

PHP unterscheidet im Verhalten im Prinzip nur zwischen diesen wesentlichen Grundtypenklassen. Innerhalb dieser wird automatisch umgewandelt, wenn möglich.

Schau Dir einfach die entstehenden Strukuren an.

Ich bau gleich mal was zu Angucken:

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[1UnitedPower]

Meine Herren!

Wäre es, einer einheitlichen Struktur wegen, nicht sinnvoller, auf die Verwendung von $ausgabe[]['id'] umzusteigen? Die anderen Felder sind ja auch so erreichbar.

Nö. Man sollte keine neuen Indexe (1) einführen, wo sie nicht mehr notwendig oder sogar kontraproduktiv wären...

$_ausgabe[] = *neuerEintrag*

würde aber für [] bei jedem Schleifendurchlauf ein neues Increment eines Index einführen, der total überflüssig ist.

Das sehe ich anders, die Datenbank-Schlüssel müssen sich nicht ausdrücklich in unseren Array-Schlüsseln wiederspiegeln. Automatische Array-Schlüssel haben den Vorteil, dass sie numerisch, fortlaufend und lückenlos sind. Vom Datenbank-Schlüssel kann man das im Allgemeinen nicht behaupten.

Für die üblichen relationalen Operationen auf Arrays( array_map, array_reduce, array_filter usw.) verhält sich keine der beiden Varianten signifikant schlechter oder besser.
Beim Iterieren (mit gewöhnlichen for-Schleifen) und Zählen (mit count()) hat die generische Variante einen Vorteil.
Beim direkten Zugriff über einen bekannten Datenbank-Schlüssel dagegen ist deine Variante schneller.
Bei der Kommunikation sehe ich auch die generische Variante übrigens auch im Vorteil; über eine Ganzzahl ist es einfacher zu sprechen als über einen abstrakten Schlüssel, der beispielsweise mit MySQLs UUID() generiert wurde.

Letztlich bleibt die Frage von Anwendungsfall zu Anwendungsfall zu beantworten, ich wollte das nur nicht so pauschal stehen lassen.

Ich bau gleich mal was zu Angucken:

Ich bin gespannt.

[Tom]

Hello,

würde aber für [] bei jedem Schleifendurchlauf ein neues Increment eines Index einführen, der total überflüssig ist.

Das sehe ich anders, die Datenbank-Schlüssel müssen sich nicht ausdrücklich in unseren Array-Schlüsseln wiederspiegeln. Automatische Array-Schlüssel haben den Vorteil, dass sie numerisch, fortlaufend und lückenlos sind. Vom Datenbank-Schlüssel kann man das im Allgemeinen nicht behaupten.

Wozu soll der neue Schlüssel taugen?
Das "Array" bleibt sowieso in der Sortierung stehen, in der das Resultset geliefert wurde. Und für den Zugriff auf den Datensatz wird i.d.R. nur der Primärschlüssel benötigt.

Für die üblichen relationalen Operationen auf Arrays( array_map, array_reduce, array_filter usw.) verhält sich keine der beiden Varianten signifikant schlechter oder besser.

Dann musst Du eben den datentechnisch sinnvolleren Weg gehen, und ein "Spaltenarray" aufbauen. Das habe ich hier ja oft genug beschrieben und die vier Standardfunktionen dafür auch hier veröffentlicht. Da würden dann alle Standard-Array-Funktionen auf Anhieb funktionieren und man könnte außerdem die Ausgabe nach jeder Spalte ohne großen Aufwand sortieren.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[M.]

Mahlzeit,

Wozu soll der neue Schlüssel taugen?

Und einen Eintrag eindeutig zu identifizieren? Das ist im Allgemeinen der Sinn eines Schlüssels.

[Tom]

Hello,

Wozu soll der neue Schlüssel taugen?

Und einen Eintrag eindeutig zu identifizieren? Das ist im Allgemeinen der Sinn eines Schlüssels.

Mea Culpa. Ich hatte Deinen ersten Beitrag nicht berücksichtigt.

Mit "neuem Schlüssel" meinte ich den automatisch vergebenen "$_ausgabe[]", also mit leerer Array-Klammer. Der ist hier nutzlose Last.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[M.]

Mahlzeit,

Mit "neuem Schlüssel" meinte ich den automatisch vergebenen "$_ausgabe[]", also mit leerer Array-Klammer. Der ist hier nutzlose Last.

Und wieso sollte das schlechter sein, als einen Schlüssel explizit anzugeben? Mal abgesehen vom längeren Code und dem unnötigen umkopieren von Daten (wenn man den Schlüssel eh nicht braucht, wie du implizierst), sehe ich absolut keinen Sinn darin so etwas zu tun. Nur wenn jemand auch im kleinen den Code möglichst kompliziert machen will.

Oder anders, wenn der automatische Schlüssel nutzlos ist, wieso sollte eine redundante ID dann einen Nutzen haben, wenn kein Schlüssel nötig. Das Umkopieren in deiner Version ist die nutzlose last.

[Tom]

Hello,

Mit "neuem Schlüssel" meinte ich den automatisch vergebenen "$_ausgabe[]", also mit leerer Array-Klammer. Der ist hier nutzlose Last.

Und wieso sollte das schlechter sein, als einen Schlüssel explizit anzugeben?

Weil dieser Schlüssel ohne Grund neu eingeführt wird. Er hat keinerlei Bezug zu den Daten.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[M.]

Mahlzeit,

Er hat keinerlei Bezug zu den Daten.

Natürlich hat er das. Der Schlüssel zeigt die Reihenfolge an, wie die Datenbank die Daten bereitstellt.
Nur mit diesem Schlüssel ist eindeutig feststellbar, wie die Daten vom DBMS geliefert worden sind.

[Tom]

Hello,

Er hat keinerlei Bezug zu den Daten.

Natürlich hat er das. Der Schlüssel zeigt die Reihenfolge an, wie die Datenbank die Daten bereitstellt.
Nur mit diesem Schlüssel ist eindeutig feststellbar, wie die Daten vom DBMS geliefert worden sind.

Nö. Das stimmt nicht. PHP-"Arrays" sind verkettete Listen, die ihre Ordnung nicht nach ihrem Index ausreichten.

Außerdem wäre das dann aufgabe der Abfrage, einen Reihenfolgeindex hinzuzufügen und nicht der API. Die API erhält laut definition ein Resultset. Die Anordnung der Datensätze im Resultset ist keinesfalls garantiert.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[M.]

Mahlzeit,

Außerdem wäre das dann aufgabe der Abfrage, einen Reihenfolgeindex hinzuzufügen und nicht der API.

Dann erklär mir jetzt mal, wie ich die Daten aus der Datenbank eindeutig identifizieren kann, wenn ich keinen Schlüssel habe.

BTW: Hast du schonmal ein Array ohne Index erstellt? Erklär mal, wie das geht.

[Tom]

Hello,

Außerdem wäre das dann aufgabe der Abfrage, einen Reihenfolgeindex hinzuzufügen und nicht der API.

Dann erklär mir jetzt mal, wie ich die Daten aus der Datenbank eindeutig identifizieren kann, wenn ich keinen Schlüssel habe.

BTW: Hast du schonmal ein Array ohne Index erstellt? Erklär mal, wie das geht.

Mann ey, seid Ihr hier alle lesefaul? *grummel*

Dein erster Vorschlag, den ich aber leider zuerst übersehen hatte
[Link:http://forum.de.selfhtml.org/my/?t=216802&m=1487563],
war doch OK. Er hätte etwas ausführlicher sein können, aber
das steht ja auf einem anderen Blatt ;-P

Ich habe nur bemängelt, dass "man" einen Overhead einführen wollte

  
   $ausgabe[] = $row;  

der keinen Nutzen bringt.

Und ich habe deinen Vorschlag ergänzt, indem ich gezeigt habe, wie man bequem die Redundanz los wird und trotzdem universellen Code behält. Man muss die einzelnen Spalten des Resultsets namentlich gar nicht kennen, nur die des Primary Key.

https://forum.selfhtml.org/?t=216802&m=1487618

In der API durch "$ausgabe[] = $row;" einen weiteren Key einzuführen, wenn es schon einen PK gibt, ist vollkommen überflüssig.

Man muss allerdings wissen, welchen Ergebnistyp die Abfrage bringen soll. Der PK darf nur jeweils einmal in der Liste vorkommen.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[1UnitedPower]

Meine Herren!

Ich habe nur bemängelt, dass "man" einen Overhead einführen wollte

$ausgabe[] = $row;

> der keinen Nutzen bringt.  
  
Die Vorteile habe ich jetzt mehrfach erläutert und leider habe ich immer noch kein fundiertes Kontra-Argument von dir gelesen.  
  
Im Übrigen halte ich das nicht für einen Overhead. Die Einfüge-Position wird von PHP sowieso auf magische Weise mitgeschleppt, ja auch bei assoziativen Arrays. In anderen Programmiersprachen (z.B. JavaScript) unterscheidet man auch nicht zwischen Position und Schlüssel in einem Array, das ist eine Besonderheit von PHP, die ich sowieso kritisch beäuge. Ein Beispiel:  
  
$foo = array();  
$foo[1] = 'bar';  
$foo[0] = 'baz';  
  
Wenn ich dich nun fragte, was das 0-te Array-Element ist, was würdest du antworten? Sagst du 'bar', sag ich 'baz', weil ich das Element mit dem Schlüssel '0' meinte. Sagst du 'baz', sag ich 'bar', weil ich das Array an Position '0' meinte.  
  
Im Allgemeinen läuft eine MySQL-Ergebnismenge übrigens auch nicht mit einer ID auf, und spätestens dann müsstest du sowieso von deiner Konvention abweichen. Ich bevorzuge da Coding-Konventionen, die robuster sind.  
  
Der Primär-Schlüssel ist nunmal eine Maßnahme, die im Kontext von relationalen Datenbanksystem zweckmäßig ist, weil Zeilen schnell identifiziert werden können und man damit ein Merkmal hat, um Relationen zwischen verschiedenen Tabellen zu definieren. Meiner Meinung nach ist dieser Primärschlüssel ein privates Implementations-Detail des Datenbank-Entwurfs und ich sehe keine technische Notwendigkeit diesen Schlüssel zu zweckentfremden und auch in PHP als Array-Schlüssel wiederzuverwenden.  

-- 
“All right, then, I'll go to hell.” – Huck Finn

[dedlfix]

Tach!

Die Vorteile habe ich jetzt mehrfach erläutert und leider habe ich immer noch kein fundiertes Kontra-Argument von dir gelesen.

Es ist in vielen Fällen einfach nicht notwendig, einen fortlaufend nummerierten Schlüssel zu haben. Es gibt foreach, mit dem man durch die Menge laufen kann. Die Frage ist, ob man eine Vorteil aus dem Key ziehen kann. Das ist lediglich der Fall, wenn man positionsorientiert zugreifen möchte. Wie häufig braucht man das? Ich denke, es ist weitaus mehr nützlich, wenn man den Primärschlüssel aus der Datenbank als Key verwendet, dann kann man auch in PHP direkt auf bestimmte Datensätze zugreifen (deren Primärschlüssel man kennt) und muss sie nicht umständlich mit durch Iterieren oder ähnliche Methoden suchen.

$foo = array();
$foo[1] = 'bar';
$foo[0] = 'baz';

Wenn ich dich nun fragte, was das 0-te Array-Element ist, was würdest du antworten?

Nun, wenn man "x-te" sagt, meint man üblicherweise eine Position, die man durch Abzählen erhält. Auch wenn du hier mit 0 statt der geläufigeren 1 anfängt, ist das 0-te Element eindeutig das an erster Position, also das was man auch mir reset() bekommt.

Sagst du 'bar', sag ich 'baz', weil ich das Element mit dem Schlüssel '0' meinte. Sagst du 'baz', sag ich 'bar', weil ich das Array an Position '0' meinte.

Diese Verwechslung scheint mit ziemlich konstruiert und löst sich durch korrekten Sprachgebrauch in Luft auf. Das x-te Element wird durch Abzählen ermittelt, bei "Element x" hingegen ist es das Element mit dem Namen/Schlüssel x.

Im Allgemeinen läuft eine MySQL-Ergebnismenge übrigens auch nicht mit einer ID auf, und spätestens dann müsstest du sowieso von deiner Konvention abweichen. Ich bevorzuge da Coding-Konventionen, die robuster sind.

Eine Konvention sollte nicht allein einem Selbstzweck gerecht werden, sondern auch einen praktischen Nutzen haben. Besser fände ich es, wenn du die Konvention erstmal außen vor lässt und würde es begrüßen, wenn du statt hauptsächlich theoretischen Erörterungen mehr anhand von praktisch anwendbaren Beispielen die Geschichte durchleuchten würdest.

Der Primär-Schlüssel ist nunmal eine Maßnahme, die im Kontext von relationalen Datenbanksystem zweckmäßig ist, weil Zeilen schnell identifiziert werden können und man damit ein Merkmal hat, um Relationen zwischen verschiedenen Tabellen zu definieren. Meiner Meinung nach ist dieser Primärschlüssel ein privates Implementations-Detail des Datenbank-Entwurfs und ich sehe keine technische Notwendigkeit diesen Schlüssel zu zweckentfremden und auch in PHP als Array-Schlüssel wiederzuverwenden.

Und warum sollte man diesen Schlüssel nicht zum schnellen Zugreifen unter PHP nutzen können/dürfen? Ich finde ihn selbst dann nützlich, wenn man die Relationen des DBMS in eine direkt referenzierende Objektstruktur zu bringen gedenkt. Wenn man solchen eine baumähnliche Struktur aufzubauen gedenkt, muss man zunächst wissen, wo man die Datensätze aus der flachen Ergebnismenge einzuhängen hat. Ein zugriff per ID ist dabei wesentlich einfacher also die Elemente durch Iteratione zu suchen.

dedlfix.

[1UnitedPower]

Meine Herren!

Im Allgemeinen läuft eine MySQL-Ergebnismenge übrigens auch nicht mit einer ID auf, und spätestens dann müsstest du sowieso von deiner Konvention abweichen. Ich bevorzuge da Coding-Konventionen, die robuster sind.

Eine Konvention sollte nicht allein einem Selbstzweck gerecht werden, sondern auch einen praktischen Nutzen haben. Besser fände ich es, wenn du die Konvention erstmal außen vor lässt und würde es begrüßen, wenn du statt hauptsächlich theoretischen Erörterungen mehr anhand von praktisch anwendbaren Beispielen die Geschichte durchleuchten würdest.

Nagut, nehmen wir an, wir wollen keine HTML-Ausgabe erzeugen, sondern eine JSON-Ausgabe, weil wir eine AJAX-API bedienen wollen. Arrays mit automatischen Schlüsseln werden durch json_encode() zu gewöhnlichen json-Listen (1). Arrays, bei denen die Position nicht mit dem Schlüssel übereinstimmt werden zu JSON-Objekten.

Nun, gehen wir mal davon aus, dass unsere MySQL-Ergebnismenge tatsächlich einen fortlaufenden Schlüssel liefert der bei 0 anfängt. Und diesen benutzen wir wiederum als Array-Schlüssel. Dann basteln wir den JSON-String zusammen und alles läuft glatt. Das Array wurde auf eine Liste abgebildet (2). Wenn wir aber nun einen Datensatz aus der Datenbank löschen, hätte das Array eine Lücke und es würde beim Überführen in JSON auf ein Objekt-Literal abgebildet werden (3).

echo json_encode( array('foo', 'bar', 'baz') ); // ["foo","bar","baz"]
2)
echo json_encode( array( 0 => 'foo', 1 => 'bar', 2 => 'baz' ) ); // ["foo","bar","baz"]
3)
echo json_encode( array( 0 => 'foo', 2 => 'baz' ) ); // {"0":"foo","2":"baz"}

[dedlfix]

Tach!

Nagut, nehmen wir an, wir wollen keine HTML-Ausgabe erzeugen, sondern eine JSON-Ausgabe, weil wir eine AJAX-API bedienen wollen. Arrays mit automatischen Schlüsseln werden durch json_encode() zu gewöhnlichen json-Listen (1). Arrays, bei denen die Position nicht mit dem Schlüssel übereinstimmt werden zu JSON-Objekten.

Das sehe ich nicht als Grund, auf IDs als Schlüssel zu verzichten. Um eine JSON-Liste zu erzeugen - oder allgemein gesagt, einen fortlaufenden Schlüssel zu bekommen - kann man mal eben schnell array_values() verwenden.

dedlfix.

[1UnitedPower]

Meine Herren!

Das sehe ich nicht als Grund, auf IDs als Schlüssel zu verzichten. Um eine JSON-Liste zu erzeugen - oder allgemein gesagt, einen fortlaufenden Schlüssel zu bekommen - kann man mal eben schnell array_values() verwenden.

Das ist im Grunde die selbe Argumentation, wie ich sie hier entgegen der Hash-Variante geführt habe. Fassen wir zusammen, es bleibt von Anwendungsfall zu Anwendungsfall zu entscheiden, und im Notfall sind beide Strukturen schnell in einander zu überführen:

Assoziativ -> Fortlaufend:

$rows = array_values( $rows );  

Fortlaufend -> Assoziativ:

$keys = array_column( $rows, 'id' );  
$rows = array_combine( $keys, $rows );

[1UnitedPower]

Meine Herren!

Der Primär-Schlüssel ist nunmal eine Maßnahme, die im Kontext von relationalen Datenbanksystem zweckmäßig ist, weil Zeilen schnell identifiziert werden können und man damit ein Merkmal hat, um Relationen zwischen verschiedenen Tabellen zu definieren. Meiner Meinung nach ist dieser Primärschlüssel ein privates Implementations-Detail des Datenbank-Entwurfs und ich sehe keine technische Notwendigkeit diesen Schlüssel zu zweckentfremden und auch in PHP als Array-Schlüssel wiederzuverwenden.

Und warum sollte man diesen Schlüssel nicht zum schnellen Zugreifen unter PHP nutzen können/dürfen? Ich finde ihn selbst dann nützlich, wenn man die Relationen des DBMS in eine direkt referenzierende Objektstruktur zu bringen gedenkt. Wenn man solchen eine baumähnliche Struktur aufzubauen gedenkt, muss man zunächst wissen, wo man die Datensätze aus der flachen Ergebnismenge einzuhängen hat. Ein zugriff per ID ist dabei wesentlich einfacher also die Elemente durch Iteratione zu suchen.

Da geb ich dir Recht, in diesem Fall macht es tatsächlich Sinn den Primärschlüssel wiederzuverwenden. Angenommen, das Array läge jetzt aber bereits in der Struktur vor, wie ich sie hier versuche zu verteidigen, dann könnte man Toms Struktur für diesen Fall so herbei führen:

$keys = array_column( $rows, 'id' );
$rowsHash = array_combine( $keys, $rows );

[1UnitedPower]

Meine Herren!

würde aber für [] bei jedem Schleifendurchlauf ein neues Increment eines Index einführen, der total überflüssig ist.

Das sehe ich anders, die Datenbank-Schlüssel müssen sich nicht ausdrücklich in unseren Array-Schlüsseln wiederspiegeln. Automatische Array-Schlüssel haben den Vorteil, dass sie numerisch, fortlaufend und lückenlos sind. Vom Datenbank-Schlüssel kann man das im Allgemeinen nicht behaupten.

Wozu soll der neue Schlüssel taugen?

Das habe ich doch erklärt, oder? Nochmal:

1. Der Schlüssel ist ganzzahlig. Es ist einfacher über eine Zahl zu sprechen als zum Beispiel über eine kryptische Zeichenfolge a la '6ccd780c-baba-1026-9564-0040f4311e29'. Das ist ein Extrem-Beispiel, in den meisten Fällen, wird vermutlich ein Auto-Increment-Schlüssel verwendet, aber im Allgemeinen kann man davon nicht ausgehen.

2. Der neue Schlüssel ist fortlaufend und lückenlos. Er entspricht der Position im Array. Das macht im Kontext von PHP intuitiver.

Für die üblichen relationalen Operationen auf Arrays( array_map, array_reduce, array_filter usw.) verhält sich keine der beiden Varianten signifikant schlechter oder besser.

Dann musst Du eben den datentechnisch sinnvolleren Weg gehen, und ein "Spaltenarray" aufbauen.

Was ist daran sinnvoller? Ich finde Spaltenarrays unnatürlich und deine kleine Funktionssammlung bestätigt mich darin, dass man es sich unnötig kompliziert macht. Ich kann beim besten Willen keinen Vorteil erkennen.

Das habe ich hier ja oft genug beschrieben und die vier Standardfunktionen dafür auch hier veröffentlicht. Da würden dann alle Standard-Array-Funktionen auf Anhieb funktionieren und man könnte außerdem die Ausgabe nach jeder Spalte ohne großen Aufwand sortieren.

Zeilenarrays lassen sich auch ohne großen Aufwand nach Spalten sortieren. Nehmen wir an, wir haben ein Zeilenarray $mitarbeiter und wollen diese nach ihrem Alter sortieren:

usort( $mitarbeiter, function( $a, $b ){  
   return ( $a->alter <= $b->alter ) ? -1 : 1;  
});

Hier dann noch ein komplementäres Beispiel zu deiner Funktionssammlung, wie man mit Zeilenarrays arbeiten kann:

// Datensatz einfügen:  
$mitarbeiter[] = new Mitarbeiter();  
  
// Datensatz auslesen:  
$werner = &$mitarbeiter[ 0 ];  
  
// Datensatz updaten:  
$werner->alter = 43;  
  
// Datensatz löschen:  
unset( $mitarbeiter[0] );

[Tom]

Hello,

2. Der neue Schlüssel ist fortlaufend und lückenlos. Er entspricht der Position im Array. Das macht im Kontext von PHP intuitiver.

Muss er nicht, braucht er nicht und hat auch keinen Bezug zur Abfrage. Die _zufällige_ Reihenfolge der Datensätze im Resultset hat überhaupt keine Bedeutung.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Auge]

Hallo

2. Der neue Schlüssel ist fortlaufend und lückenlos. Er entspricht der Position im Array. Das macht im Kontext von PHP intuitiver.

Muss er nicht, braucht er nicht und hat auch keinen Bezug zur Abfrage.

Nöö, der Bezug ist jener zum Array. Dafür und nur dafür ist der Schlüssel auch da.

Die _zufällige_ Reihenfolge der Datensätze im Resultset hat überhaupt keine Bedeutung.

Eben, aber darüber reden wir auch nicht. Hier geht es nur und ausschließlich um ein Array, welches zufälligerweise die Daten eines Resultsets einer Datenbankabfrage enthält.

Da ist aber etwas, was ich an deinem System viel unlogischer, nach meinem Gefühl geradezu abweisend empfinde.
Ich greife (z.B.) mit $ausgabe[2]['ort'] auf die Angabe des Ortes in der entsprechenden Zeile zu, auf die ID des Datensatzes muss ich aber auf eine andere Weise zugreifen, weil sie nicht analog dazu als $ausgabe[2]['id'] zur Verfügung steht. Ich empfinde das als äußerst unintuitiv.

Tschö, Auge

[M.]

Mahlzeit,

Besser wäre daher:

while ($_row = mysql_fetch_assoc($result))
{
    $_ausgabeliste[$_row['id']] = $_row;
}

  
Aus dem Grund hab ich das in [meinem ersten Beitrag](https://forum.selfhtml.org/?t=216802&m=1487563) auch schon vorgeschlagen ...  

-- 
42

[M.]

Mahlzeit,

Macht nicht ganz das Gleiche.

Wo ist der Unterschied?