mehrdimensionales Array durchsuchen

[Gunnar Bittersmann]

Ich habe solch ein Array

$starships = [
  ['id' => 'NCC-1031', 'name' => 'Discovery'],
  ['id' => 'NCC-1227', 'name' => 'Shenzhou'],
  ['id' => 'NCC-1701', 'name' => 'Enterprise'],
];

und möchte nun zu einer ID den Namen haben.

$id = 'NCC-1701';
$results = array_filter(
  $starships,
  fn($starship) => $starship['id'] === $id
);
$name = $results ? $results[array_key_first($results)]['name'] : NULL;


var_dump($name); // string(10) "Enterprise"

Geht das noch irgendwie einfacher?

🖖 Живіть довго і процвітайте

[TS]

Hello Gunnar,

einfacher wäre es, wenn Du das Array gleich richtig™ aufbauen würdest:

  $_starships['NCC-1031'] = 'Discovery';
  $_starships['NCC-1227'] = 'Shenzhou';
  $_starships['NCC-1701'] = 'Enterprise';

Dann kannst Du direkt nach dem Key fragen.

Glück Auf
Tom vom Berg

[Gunnar Bittersmann]

@@TS

einfacher wäre es, wenn Du das Array gleich richtig™ aufbauen würdest:

Dann muss ich doch weiter ausholen. Ich habe solch ein JSON

[
	{
		"id": "NCC-1031",
		"name": "Discovery"
	},
	{
		"id": "NCC-1227",
		"name": "Shenzhou"
	},
	{
		"id": "NCC-1701",
		"name": "Enterprise"
	}
]

und generiere daraus das Array:

$json = file_get_contents('starships.json');
$starships = json_decode($json, TRUE);

Das Array ist so wie es ist.

🖖 Живіть довго і процвітайте

[Rolf B]

Hallo Gunnar,

$id = "NCC-1701";
$name = NULL;
for ($starships as $_id => $_name) {
   if ($id == $_id) {
      $name = $_name;
      break;
   }
}

ist auf jeden Fall schneller als die Callbackerei.

Wenn Du mehr als eine ID suchen musst, kann das Umformen in die von Tom vorgeschlagene Form effizienter sein.

Rolf

[Gunnar Bittersmann]

@@Rolf B

for ($starships as $_id => $_name) {

Du meinst vermutlich foreach? Aber auch damit geht’s nicht.

Was ist das für eine Magie mit $_?

🖖 Живіть довго і процвітайте

[TS]

Hello,

for ($starships as $_id => $_name) {

Du meinst vermutlich foreach? Aber auch damit geht’s nicht.

Das vermute ich auch. Rolf hat sich in der Eile nur um eine Ebene vertan...

$id = 'NCC-1701';
$name = NULL;
$_record = array();

foreach ($_starships as $key => $_record) 
{
   if ($_record['id'] == $id) 
   {
      $name = $_record['name'];
      break;
   }
}

Probier es mal so.

Was ist das für eine Magie mit $_?

Ich kennzeichne die Typen immer folgendermaßen:
$var für Skalare
$_rec für Arrays, also Datensätze
$__abc für Objekte und andere komplexe Typen

Das ist aber nur eine Privatmacke, aber die Programme lassen sich dann leichter lesen ;-)

Glück Auf
Tom vom Berg

[Gunnar Bittersmann]

@@TS

Danke dir. Eine Frage hab ich aber noch:

$_record = array();

Wozu ist die Vorbelegung gut? Es läuft auch ohne – …

Was ist das für eine Magie mit $_?

Ich kennzeichne so Arraytypen. Das ist aber nur eine Privatmacke ;-)

… nachdem ich dein $_starships in $starships geändert habe. 😉

🖖 Живіть довго і процвітайте

[TS]

Hello,

Danke dir. Eine Frage hab ich aber noch:

$_record = array();

Wozu ist die Vorbelegung gut? Es läuft auch ohne – …

Aber nur, wenn $_record nicht schon irgendwie vorbelegt war.
Wenn z. B. aus Versehen schon ein String drin steht, kracht es vermutlich. Das war zumindest "zu meiner Zeit" noch so. Die neueren PHP-Versionen habe ich noch nicht daraufhin untersucht.

… nachdem ich dein $_starships in $starships geändert habe. 😉

Anders herum wäre es konsequenter ;-P

Glück Auf
Tom vom Berg

[Gunnar Bittersmann]

@@TS

Ich kennzeichne die Typen immer folgendermaßen:
$var für Skalare
$_rec für Arrays, also Datensätze
$__abc für Objekte und andere komplexe Typen

Das ist aber nur eine Privatmacke, aber die Programme lassen sich dann leichter lesen ;-)

Die Striche von heute sind die Buchstaben von damals‽ aRec, oAbc, …

Hat man dafür nicht eine IDE, die den Typen einer Variablen anzeigt?

🖖 Живіть довго і процвітайте

[TS]

Hello,

Ich kennzeichne die Typen immer folgendermaßen:
$var für Skalare
$_rec für Arrays, also Datensätze
$__abc für Objekte und andere komplexe Typen

Das ist aber nur eine Privatmacke, aber die Programme lassen sich dann leichter lesen ;-)

Die Striche von heute sind die Buchstaben von damals‽ aRec, oAbc, …

Das ist reine Geschmackssache. Ich finde, dass man die Striche schneller sieht, als vorangetellte Buchstaben oder Typen-Kurzbezeichner.

PHP kennt ja ohnehin nur Skalare, "Arrays" und Objekte, bzw. Programme/Funktionen und Konstanten. Durch die automatische Typumwandlung verschwimmt das zu allem Überfluss auch noch.

Die generischen Datentypen muss man eigentlich nur bezüglich der möglichen Wertebereiche beachten.

Hat man dafür nicht eine IDE, die den Typen einer Variablen anzeigt?

Wenn man objektorientiert programmiert mit PHP sollte man tunlichst eine haben. Für den prozeduralen Stil ist die mMn eher hinderlich.

Ich mag z. B. auch gerne eine explizite Schreibweise im Allman-Style. Das kostet ja kein Papier, wenn man es nicht unbedingt immer druckt.

Glück Auf
Tom vom Berg

[Gunnar Bittersmann]

@@TS

Ich mag z. B. auch gerne eine explizite Schreibweise im Allman-Style.

Allman-Style war ich auch mal Fan von. Bin wieder von abgekommen, weil die Linter-Regeln auf Arbeit die öffnende Klammer noch in der alten Zeile verlangen. („Machen ja alle so.“)

Das kostet ja kein Papier, wenn man es nicht unbedingt immer druckt.

Fun fact: Zu Zeiten meines 640×480-Monitors (der konnte zwar 800×600, aber das Flimmern wollte man sich nicht antun) hatte ich mir den Code eines Projekts tatsächlich ausgedruckt. (Endlospapier – ihr kennt das noch?) Das hatte ich zum Lesen in S- und U-Bahn dabei und hab mit ’nem Stift Debugging gemacht. Wirklich, ich hab in der Bahn einige Fehler gefunden.

Das hinderlichste Werkzeug beim Programmieren ist ein Computer.

🖖 Живіть довго і процвітайте

[Rolf B]

Hallo Gunnar,

Du meinst vermutlich foreach?

Äh, ja.

Aber auch damit geht’s nicht.

Äh, nein. Man soll nicht zwischen Tür und Angel Forenbeiträge beantworten.

Es muss natürlich so aussehen, wie Tom schrub - bzw. auf die Key=>Value Notation im foreach kann man verzichten, weil's ja kein assoziatives Array ist.

$ships = [
   [ 'id' => 'CV-6'    , 'name' => 'Enterprise' ], 
   [ 'id' => 'D52'     , 'name' => 'Enterprise' ], 
   [ 'id' => 'L-5'     , 'name' => 'Enterprise' ], 
   [ 'id' => 'CVN-80'  , 'name' => 'Enterprise' ], 
   [ 'id' => 'NX-01'   , 'name' => 'Enterprise' ], 
   [ 'id' => 'NCC-1701', 'name' => 'Enterprise' ], 
   [ 'id' => 'XCV-330' , 'name' => 'Enterprise' ] ];

$id = "NX-01";
$name = null;

foreach ($ships as $_ship)
{
   if ($_ship[$id] == $id)
   {
      $name ? $_ship['name'];
      break;
   }
}

Was ist das für eine Magie mit $_?

Gar keine. Das hab ich als "interne Variable" vor die Schleifenvariablen gemacht. Abrakamööp.

Wenn Du unbedingt mit Callbacks und funktionaler Programmierung arbeiten möchtest, könntest es auch so machen (und es wundert mich eigentlich, dass PHP diese Funktion nicht schon hat):

function array_find($array, $callback)
{
   foreach ($array as $key => $entry)
   {
      if ($callback($entry, $key))
         return $entry;
   }
   return null;
}

$ship = array_find($ships, fn($starship) => $starship['id'] === $id);
$name = $ship['name'] ?? null;

echo "Die $id heißt $name";

Ich halte array_filter für keine gute Idee, weil diese Funktion immer das ganze Array durchläuft. Eine generische Funktion sollte aber immer key und value eines Arrays bereitstellen, und sie sollte den value zuerst in den Callback schieben, damit der den Key nicht deklarieren muss, wenn er nicht interessiert (analog zu Array.prototype.find in JavaScript).

Die Schreibweise $arr['key'] ?? null ist der null coalescing operator, er verhindert sowohl die Warnung (sic!), die PHP ausgibt, wenn $arr kein Array ist, wie auch die Warnung, dass $arr keinen Key 'name' enthielte.

Rolf

[Raketenwilli]

einfacher wäre es, wenn Du das Array gleich richtig™ aufbauen würdest:

Dann muss ich doch weiter ausholen. Ich habe solch ein JSON

[
	{
		"id": "NCC-1031",
		"name": "Discovery"
	},
	{
		"id": "NCC-1227",
		"name": "Shenzhou"
	},
	{
		"id": "NCC-1701",
		"name": "Enterprise"
	}
]

und generiere daraus das Array:

$json = file_get_contents('starships.json');
$starships = json_decode($json, TRUE);

Das Array ist so wie es ist.

Soso. „Beharrungsvermögen“.

$StarshipsPerId = [];
foreach ( $starships as $item ) {
    $StarshipsPerId[ $item['id'] ] = $item['name'];
}
unset ( $starships );

Wusch! (Bruchteil eines Bruchteils einer Millisekunde) Jetzt hast Du ein neues, direkt befragbares Array.

• Womöglich willst Du die Datei mit dem Json-String neu erzeugen:

file_put_contents(
    'StarshipsPerId.json',
     json_encode( $StarshipsPerId, JSON_PRETTY_PRINT )
);

Freilich könnte man den Json-String auch in seiner Existenzform „Text“ umformen :-). Das wird aber teuer.

• Auf mögliche Probleme (leere oder nicht eindeutige ID) sei hingewiesen.
• Wenn noch mehr Eigenschaften hinzukommen (Baujahr, Update, Länge, Breite, Höhe, vMax, Antriebsart, Besatzung, ... ) und danach gefragt werden können soll, nimm sqlite statt json als Datendaseinsform.

[Rolf B]

Hallo Raketenwilli,

Freilich könnte man den Json-String auch in seiner Existenzform „Text“ umformen :-). Das wird aber teuer.

Ja. Weil man dann einen JSON-Parser selbst schreiben muss. Natürlich hat der gezeigte String den Anschein, man könnte sich da mit Regexen durchwühlen:

$id = "NCC-1701";
$regex = <<<END
/{\s*"id"\s*:\s*"$id"\s*,\s*"name"\s*:\s*"(?<name>[^"]+)"\s*}/
END;

		"id": "NCC-1031",
		"name": "Discovery"
	}

Es gibt zwar keinen Beleg für einen Schiffsnamen wie Dwight "Ike" Eisenhower, aber davon sollte man sich nicht zur Annahme verleiten lassen, dass das nicht vorkommen kann.

Wobei - ok, bei Gunnar kann das nicht vorkommen. Bei ihm hieße das Schiff ja Dwight “Ike” Eisenhower…

Rolf

[Gunnar Bittersmann]

@@Rolf B

Es gibt zwar keinen Beleg für einen Schiffsnamen wie Dwight "Ike" Eisenhower, aber davon sollte man sich nicht zur Annahme verleiten lassen, dass das nicht vorkommen kann.

Wobei - ok, bei Gunnar kann das nicht vorkommen. Bei ihm hieße das Schiff ja Dwight “Ike” Eisenhower…

So isses. 😊

Allerdings sollte hier Postels Gesetz gelten: „Sei streng bei dem, was du tust, und offen bei dem, was du von anderen akzeptierst.“

🖖 Живіть довго і процвітайте

[TS]

Hello Gunnar,

Es gibt zwar keinen Beleg für einen Schiffsnamen wie Dwight "Ike" Eisenhower, aber davon sollte man sich nicht zur Annahme verleiten lassen, dass das nicht vorkommen kann.

Wobei - ok, bei Gunnar kann das nicht vorkommen. Bei ihm hieße das Schiff ja Dwight “Ike” Eisenhower…

So isses. 😊

Allerdings sollte hier Postels Gesetz gelten: „Sei streng bei dem, was du tust, und offen bei dem, was du von anderen akzeptierst.“

Das ist auch die verwissenschaftlichte Antwort auf deine Frage, warum man in PHP Arraybezeichner/-Zeiger immer mit dem leeren Arraytyp ($_arr = array()) initialisieren sollte. Dass es da Fehlermöglichkeiten gibt, schrieb ich ja schon.

Was würdest Du von einer "Blackboxfunktion" halten, die Dir die (zweidimensionalen) JSON-Daten entgegennimmt und Dir die Möglichkeit einräumt, in jeder Spalte zu suchen und den/die zum Treffer passenden Datens(a|ä)tz(|e) zu liefern?

Anmerkung: [ vorstehender Versuch, RegEx im Text zu benutzen, ist untauglich, da zu 'a' '' gehört und zu 'ä' 'e' ]

Glück Auf
Tom vom Berg

[Rolf B]

Hallo TS,

Allerdings sollte hier Postels Gesetz gelten: „Sei streng bei dem, was du tust, und offen bei dem, was du von anderen akzeptierst.“

Das ist auch die verwissenschaftlichte Antwort auf deine Frage, warum man in PHP Arraybezeichner/-Zeiger immer mit dem leeren Arraytyp ($_arr = array()) initialisieren sollte.

Es ist eine Sache, ob man einer uninitialisierte Variablen einfach eine Arrayzuweisung aufdrückt, also sowas wie

$schlumpf = null;
$schlumpf[2] = "Gargamel";

PHP lässt das idiotischerweise zu und derjenige, der so programmiert, gehört blau angemalt. Wenn in $schlumpf etwas anderes drinsteht, vor allem ein Skalarwert, dann macht's bum.

Es ist eine andere Sache, sowas hier zu tun - vorausgesetzt, $_record wird nach der Schleife nicht mehr verwendet:

$_record = array();
foreach ($_starships as $key => $_record) 
{
   // code code code $_record code code code
}

Diese Initialisierung ist dann und nur dann nötig, wenn $_record nach der Schleife verwendet wird. Sie deckt den Fall ab, dass $_starships leer ist und der foreach kein einziges Mal betreten wird. In dem Fall sollte man aber auch $key initialisieren. Ein hübsches Konstrukt wie foreachelse, dass bspw. Smarty kennt, fehlt im nativen PHP. Das wurde zwar schon mindestens drölfmal in verschiedenen Formen als PHP Verbesserungsvorschlag eingebracht, aber von den PHP Sprachbewahrern immer abgelehnt. Ist vermutlich besser so... 😉

Für den Code innerhalb der Schleife ist die Initialisierung irrelevant, weil PHP $key und $_record pro Durchlauf mit Werten aus dem Array befüllt.

Rolf

[TS]

Hello,

Allerdings sollte hier Postels Gesetz gelten: „Sei streng bei dem, was du tust, und offen bei dem, was du von anderen akzeptierst.“

Das ist auch die verwissenschaftlichte Antwort auf deine Frage, warum man in PHP Arraybezeichner/-Zeiger immer mit dem leeren Arraytyp ($_arr = array()) initialisieren sollte.

Es ist eine Sache, ob man einer uninitialisierte Variablen einfach eine Arrayzuweisung aufdrückt, also sowas wie

$schlumpf = null;
$schlumpf[2] = "Gargamel";

PHP lässt das idiotischerweise zu und derjenige, der so programmiert, gehört blau angemalt. Wenn in $schlumpf etwas anderes drinsteht, vor allem ein Skalarwert, dann macht's bum.

Es ist eine andere Sache, sowas hier zu tun - vorausgesetzt, $_record wird nach der Schleife nicht mehr verwendet:

$_record = array();
foreach ($_starships as $key => $_record) 
{
   // code code code $_record code code code
}

Diese Initialisierung ist dann und nur dann nötig, wenn $_record nach der Schleife verwendet wird. Sie deckt den Fall ab, dass $_starships leer ist und der foreach kein einziges Mal betreten wird. In dem Fall sollte man aber auch $key initialisieren. Ein hübsches Konstrukt wie foreachelse, dass bspw. Smarty kennt, fehlt im nativen PHP. Das wurde zwar schon mindestens drölfmal in verschiedenen Formen als PHP Verbesserungsvorschlag eingebracht, aber von den PHP Sprachbewahrern immer abgelehnt. Ist vermutlich besser so... 😉

Für den Code innerhalb der Schleife ist die Initialisierung irrelevant, weil PHP $key und $_record pro Durchlauf mit Werten aus dem Array befüllt.

Dann hast DU den A-Postel nicht verstanden. Warum sollte man etwas untetlassen, was fast nichts kostet, aber im Zweifelsfalle für erheblich mehr Sicherheit und - vor allem - weniger Denkarbeit bei der Programmierung sorgt?

Warum sollte ich mir genau an dieser Stelle Gedanken für Microoptimierung machen, wenn es doch auf "meine Art" fast nichts kostet?

Außerdem kann man es dem Array-Bezeichner an dieser Stelle nicht ansehen, ob er eine übernommene Referenz oder ein neuer Bezeichner dieser Instanz ist.

Hier hat PHP einfach eine Designeigenschaft, die man berücksichtigen MUSS.

Glück Auf
Tom vom Berg

[Rolf B]

Hallo TS,

Dann hast DU den A-Postel nicht verstanden.

Oder Du. Denn Postel befasst sich mit den Daten, die man von außen geliefert bekommt, nicht mit der inneren Programmstruktur.

Außerdem kann man es dem Array-Bezeichner an dieser Stelle nicht ansehen, ob er eine übernommene Referenz oder ein neuer Bezeichner dieser Instanz ist.

Weshalb es eine gute Idee ist, diese Suchaktion in eine Funktion mit nur wenigen Zeilen auszulagern, so dass sich die Frage, ob die Schleifenvariable nach der Schleife noch verwendet wird, oder ob in der Schleife irgendeine von fern zugelieferte Variable rumgammelt, gar nicht stellt (Anwendung von Curly's Law).

"Vorsichts-Initialisierer" gab's zu allen Zeiten, ich gehöre nicht dazu.

Rolf

[Gunnar Bittersmann]

@@Raketenwilli

Wusch! (Bruchteil eines Bruchteils einer Millisekunde) Jetzt hast Du ein neues, direkt befragbares Array.

Warum sollte ich das tun und ein neues Array erstellen anstatt im Bruchteil eines Bruchteils einer Millisekunde das vorhandene zu befragen?

• Womöglich willst Du die Datei mit dem Json-String neu erzeugen:

Nein, will ich nicht. Das Format soll zu den Daten passen, nicht zu einer bestimmten Implementation der Verarbeitung. Ob PHP eine passende Funktion bereitstellt oder ob man sich diese selbst stricken muss, geht das Daten-JSON nichts an.

🖖 Живіть довго і процвітайте

[Raketenwilli]

Das Format soll zu den Daten passen,

Das vorgeschlagene, neue Format passt hervorragend zu den Daten. Jedenfalls so lange die ID eine ID ist.

[Gunnar Bittersmann]

@@Raketenwilli

Das Format soll zu den Daten passen,

Das vorgeschlagene, neue Format passt hervorragend zu den Daten. Jedenfalls so lange die ID eine ID ist.

Das JSON-Format wird u.U. von außen vorgegeben, bspw. durch JSON-LD-Syntax.

Hier soll nicht die ID der Key sein zu etwas Unbenanntem, sondern id und name die Keys und die ID und der Name die jeweiligen Werte dazu.

🖖 Живіть довго і процвітайте

[Raketenwilli]

Ah! Dann hast Du mit Deinem Beispiel sicher nicht nur mich in die Irre geleitet.

Das JSON-Format wird u.U. von außen vorgegeben, bspw. durch JSON-LD-Syntax.

Und die orientiert sich also wohl daran, auch von Programmiersprachen verarbeitet zu werden, welche „in Bezug auf Arrays nur wenige Vorteile zu bieten haben“. (Ich sollte Geld für meine Euphemismen nehmen.)

Deine Frage war:

Geht das noch irgendwie einfacher?

Nun, so lange Du an einer Datenstruktur fest hältst oder fest halten musst, welche einen “Full-Table-Scan“ bzw. ein Iterieren über (womöglich sogar das gesamte) Array erforderlich macht, geht es nicht „einfacher“. Oder suchst Du nur nach einer Notationsweise mit weniger Elementen (Zeilen, Wörter)? Die wäre längst nicht nur für mich nicht etwa „einfacher“ sondern „undurchsichtiger“.

JSON-LD-Syntax

Nach einem Blick auf das hier drängt sich der Eindruck auf, dass da jemand mit Biegen und Brechen versucht, bei der Nutzung von JSON mindestens die gleiche Heizleistung zu erzielen wie bei XML. Kein Wunder, dass Wärmepumpen gegenwärtig eine große Zukunft beschrieben wird, denn es wird ja von ganzen Konsortien jede Menge Luft heiß gemacht... Wäre doch gut, wenn das irgendeinen greif- oder fühlbaren Nutzen hätte.

Darüber, dass es in der IT-Welt Kreise gibt, welche (m)einen pragmatischen Ansatz ablehnen, muss ich nicht informiert werden.

[Rolf B]

Hallo Gunnar Bittersmann,

Das Format soll zu den Daten passen, nicht zu einer bestimmten Implementation der Verarbeitung.

Ist ein Primärindex in den Daten unpassend? Wo kommt dieses Array überhaupt her? Von Dir? Von extern? Liest Du es aus einer Datei? Ist es als Literal in Code notiert?

Rolf

[Gunnar Bittersmann]

@@Rolf B

Hallo Gunnar Bittersmann,

Das Format soll zu den Daten passen, nicht zu einer bestimmten Implementation der Verarbeitung.

Ist ein Primärindex in den Daten unpassend?

Ich habe den Begriff „Primärindex“ noch nie im Zusammenhang mit JSON gehört. Wir reden hier nicht über ein DBMS.

🖖 Живіть довго і процвітайте

[TS]

Hello,

Hallo Gunnar Bittersmann,

Das Format soll zu den Daten passen, nicht zu einer bestimmten Implementation der Verarbeitung.

Ist ein Primärindex in den Daten unpassend?

Ich habe den Begriff „Primärindex“ noch nie im Zusammenhang mit JSON gehört. Wir reden hier nicht über ein DBMS.

Aber schon über eine organisierte Anordnung der Daten, die die Datensätze durch Abbildung ins DOM dann sogar über eine "Zeilennummer" erreichbar macht.

Glück Auf
Tom vom Berg

[Rolf B]

Hallo Gunnar,

Ich habe den Begriff „Primärindex“ noch nie im Zusammenhang mit JSON gehört. Wir reden hier nicht über ein DBMS.

Wir reden hier über eine Tabelle mit einem eindeutigen Schlüsselbegriff.

Die Speicherung als Map (a.k.a. assoziatives Array in PHP) führt zu einem möglichen Direktzugriff über diesen Schlüssel.

Wenn das kein Primärindex ist, was denn sonst?

Die Speicherung als JSON-Objekt ist eine Effizienzsteigerung, die Dir den Rebuild des Index bei jedem Laden in den RAM erspart.

Rolf

[TS]

Hello,

Das Format soll zu den Daten passen, nicht zu einer bestimmten Implementation der Verarbeitung.

Ist ein Primärindex in den Daten unpassend?

Ich habe den Begriff „Primärindex“ noch nie im Zusammenhang mit JSON gehört. Wir reden hier nicht über ein DBMS.

Das ist übrigens ein weiteres Problem bei dieser Art von Low-Level-Datenspeicherung. Da bist Du selber dafür verantwortlich, dass der Schlüssel nicht mehrfach vorkommt in der Datensammlung.

Was wäre denn, wenn eine ID mehrfach in der Liste stände?

Müsstest Du nicht schon aus diesem Aspekt zuerst eine Überprüfung vornehmen und bei Doubletten eine Warnung generieren, bzw. eine Korrektur vornehmen?

Glück Auf
Tom vom Berg

[Gunnar Bittersmann]

@@TS

Was wäre denn, wenn eine ID mehrfach in der Liste stände?

Dann sind die Daten halt so.

Ein Schiff kann ja umbenannt werden, bspw. die Völkerfreundschaft. Dann gehören halt zu einer ID mehrere Namen.

Die Anwendung, die die Daten verarbeitet, bestimmt, was dann geschehen soll: ob der erste Name relevant ist oder der letzte oder ob man eine Liste mit allen Namen haben will.

Die Daten sollen jedenfalls bezüglich ihrer späteren Verarbeitung agnostisch sein. Es kann auch mehrere Anwendungen geben, die die Daten unterschiedlich verarbeiten.

Auf jeden Fall soll das Format die Daten richtig beschreiben – und dabei auch gut menschenlesbar sein.

[
	{
		"id": "NCC-1031",
		"name": "Discovery"
	},
	{
		"id": "NCC-1227",
		"name": "Shenzhou"
	},
	{
		"id": "NCC-1701",
		"name": "Enterprise"
	}
]

erfüllt das. Die IDs sind als IDs gekennzeichnet und die Namen als Namen.

{
	"NCC-1031": "Discovery",
	"NCC-1227": "Shenzhou",
	"NCC-1701": "Enterprise"
}

erfüllt das nicht. Es steht nirgendwo geschrieben, dass das vor dem Doppelpunkt eine ID ist und das dahinter ein Name.

---

Müsstest Du nicht schon aus diesem Aspekt zuerst eine Überprüfung vornehmen und bei Doubletten eine Warnung generieren, bzw. eine Korrektur vornehmen?

In meinem speziellen Anwendungsfall werde ich das nicht müssen. Aber ja, man sollte sich Gedanken machen, s.o. Aber wie gesagt ist das Sache der Anwendung, nicht des Datenformats.

---

Womöglich will man die JSON-Datei nicht nur einfach per json_decode() in PHP einlesen, sondern wie Raketenwilli sagte aufbereiten. Wenn man etliche Zugriffe auf die Daten machen muss, ist das sicher sinnvoll.

In meinem speziellen Anwendungsfall wäre das wohl Overkill. Ich brauche den Namen zu einer bestimmten ID nur ein einziges Mal.

🖖 Живіть довго і процвітайте

[TS]

Hello,

Nein, will ich nicht. Das Format soll zu den Daten passen, nicht zu einer bestimmten Implementation der Verarbeitung. Ob PHP eine passende Funktion bereitstellt oder ob man sich diese selbst stricken muss, geht das Daten-JSON nichts an.

Die Modellierung der Daten ist aber immer ein Spaghat zwischen den Datenzusammenhängen und den tgechnischen Möglichkeiten des Programmiersystems. Man sollte dabei aber immer einige Punkte beachten:

• Konformität von Eingangsdaten muss grundsätzlich überprüft werden
• atomistische Auflösung/Normalisierung vorzugsweise nach Boyce-Codd
• Verwendung von direkt gekoppelten Primärschlüsseln, wo immer es möglich ist.
• Polymorphe/tabellarische Darstellung der Daten, ggf. in relationalen Tabellen *1)

Direkt gekoppelt bezeichnet hier einen Primärschlüssel, der für immer und ewig und eineindeutig mit dem Datensatz verbunden wird. Ob er dabei eine zweite Funktion erfüllen darf, z. B. Kennzeichnung der zeitlichen Reihenfolge der Vergabe, bleibt hier zunächst umstritten.

*1) hier gibt es als Gegenpol auch Verfechter einer objektorientierten Modellierung, eher chaotisch organisiert und damit cryptisch für die Nachverfolgbarkeit. Im Gegensatz dazu ist Human readability zusätzlich gerade bei den Darstellungen von PHP Arrays und JSON eines der obersten Ziele.

Glück Auf
Tom vom Berg

[Felix Riesterer]

Lieber Gunnar,

  fn($starship) => $starship['id'] === $id

da hätte ich jetzt das Schlüsselwort function erwartet. Dass PHP auch Pfeilfunktionen kann, habe ich erst jetzt durch die Beschäftigung mit Deinem Posting gelernt.

Liebe Grüße

Felix Riesterer