DB Abfrage Nach Zahlen

[Icke]

Hallo Leute,

ich möchte Länder nach Zahlen ausgeben.

also
if($vorkommen == 619) { $vorkommen = "Guadeloupe"; }

mein DB Feld muss Integr sein mit max 255 Zeichen.

daa werden aber keine Kommas akzeptiert!!! wie muss da die Abfrage lauten.

[Icke]

Hallo Leute,

ich möchte Länder nach Zahlen ausgeben.

also
if($vorkommen == 552) { $vorkommen = "Guadeloupe"; }

mein DB Feld muss Integr sein mit max 255 Zeichen.

daa werden aber keine Kommas akzeptiert!!! wie muss da die Abfrage lauten.

https://wasserwelt.org/tiere/detail.php?s=4&id=34099

[oxpus]

mein DB Feld muss Integr sein mit max 255 Zeichen.

Integer-Feld mit 255 Zeichen?

Integer sind Ganzzahlen von -32768 bis +32767.
Also ohne Nachkommastellen.

Wenn Du Nachkommastellen speichern möchtest, geht das nur mit dem Datentyp DECIMAL(5,2).
In diesem Beispiel mit 5 Stellen vor dem Komma und 2 Nachkommastellen.
Decimal ist dabei begrenzt auf maximal 65 Stellen, Vor- und Nachkommastellen dabei zusammengerechnet.

[Icke]

Guten Morgen Oxpus,

ja ist klar Feld Integer mit 255 Zeichen, aber wie löse ich das Problem mit dem Komma.

zB. 552, 701, 559, 845

[oxpus]

Verstehe ich immer noch nicht, was Du genau wissen willst.

INTEGER-Felder sind nummerisch und nehmen exakt eine Ganzzahl (also einen nummerischen Wert ohne Nachkommastellen) auf.
Kommata und andere Zeichen außer 1-9 und 0 werden folglich abgelehnt.

Wenn Du dagegen INTEGER-Werte mit Kommata getrennt in ein DB-Feld speichern willst, muss das Feld ein alphanummerisches Feld sein, also z. B. VARCHAR oder TEXT (siehe hier: https://www.schmager.de/mysql.php)

Sofern die Integer-Werte in einem Array vorliegen, kann man diese mittels der Funktion implode() zusammenfassen, um sie in dem einen Feld mit Kommata getrennt zu speichern.
Umgekehrt kann man das Feld auslesen und mittels Funktion explode() die Zahlen nach Kommata getrennt in ein Array übernehmen, um dieses dann einzeln auszulesen.

Aber was genau möchtest Du mit dem Feld, den INTEGER-Werten und den Kommata bewirken?
Ein INTEGER-Feld mit 255 Zeihen gibt es nicht.
Entweder ist das Feld in der DB ein STRING-Feld mit einer definierten Länge (in diesem Fall vermutlich VARCHAR mit 255 Zeichen Länge) oder ein INTERGER-Feld für nummerische Ganzzahlen, bzw. DECIMAL für natürliche Zahlen mit möglichen Nachkommastellen.

Was genau ist also Deine Frage, bzw. Dein Problem?
Was ist Deine Ausgangssituation an Daten, welche in der DB gespeichert werden sollen?
INTEGER-Felder nehmen definitiv nur eine Ganzzahl auf, mehrere Werte müssen also immer in einem Text-Feld gespeichert und dazu vorab verkettet werden, um diese auch "trennen" zu können.

[Icke]

Guten Morgen Oxpus,

ich habe ein Feld 'vorkommen' in em Feld sollen alle Länder bzw Regionen des vorkommens angezeigt werden.

Da ich bisher nur ca.65000 Eintrüge habe, es werden Vermutlich weit über 460 000 werden ist die Frage was hat ein Datenbankfeld für eine Grösse?

1. DB Feld Varcher 500 Zeichen, mit Daten 552, 643, 541, 771

2. Text Feld mit 500 Zeichen, mit Daten 552, 643, 541, 771

und dann das Ergebnis X 460 000 ist gleich ?

[oxpus]

Ah, jetzt verstehe ich langsam.

Zunächst die einfache Rechnung:
"552, 643, 541, 771" = 13 Zeichen, inkl. Kommata, ebenfalls auch das zweite Beispiel. 16 Zeichen, wenn man die Leerzeichen hinzurechnet.
13 Zeihen x 460.000 Einträge = 5.980.000 Bytes = 5,7 MB Daten, mit Leerzeichen 7 MB, in einem Datenbankfeld.
Und das je Datensatz!

Dieser Datenbrocken will dann auch erst einmal zwischen Webserver/PHP und der Datenbank transferiert werden (lesen wie auch schreiben), was bei solchen Datenmengen viel Zeit kosten und Deine Webseite spürbar verlangsamen würde.

Solche Datenmengen speichert man auch nicht mehr in VARCHAR- oder TEXT-Feldern, sondern in LOB-Feldern (large objects).
LOB's sind aber eher dafür gedacht, jeweils ein einziges Objekt aufzunehmen, also einen zusammengehörenden Text oder eine Datei, wovei diese Objekte in der Regel unverändert ausgelesen oder gespeichert werden und daher eigenen sich diese Feldtypen nicht wirklich für zusammengekettete "Datensätze" von solchen Ausmaßen.

Mal ungeachtet dessen, wie die aktuelle Datenstruktur um "vorkommen" herum bereits aufgebaut ist, die ich zudem nicht kenne:
Es wäre sinnvoller, sondern auch dringend anzuraten, das Feld "vorkommen" in eine Untertabelle zu überführen, wenn man solche rießige Datenmengen veralten will.
Das kann zusammen mit einer laufenden Nummer über alle "Vorkommen" hinweg (auto_increment) und der ID auf den jeweils zugehörenden übergeordneten Datensatz als Verweis erledigt werden.

Ja, ist im Datenmodell anfangs etwas mehr Arbeit, dieses aufzubauen, aber das lohnt sich.
Allein beim Auslesen könnte man dann bereits mit der gleichen Abfrage auf andere Tabellen verknüpfen, um z. B. die Vorkommen mitsamt deren "Beschreibungen" und weiteren Daten in einem Schwung aus der Datenbank abzufragen.
Andernfalls müsste man den abgefragten Datenbrocken erst auseinandernehmen und die weiteren Daten erst anschließend mittels zusätzlicher Abfragen einzeln aus der Datenbank holen; was zudem auch extra Zeit und Server-Ressourcen kosten würde.

Ich würde mir das also stark überlegen, einen solch großen Datenberg in ein einziges DB-Feld quetschen zu wollen.
Das wäre jedenfalls bei solchen theoretisch riesigen Datenmengen absolut nicht sinnvoll.

[Icke]

Hallo Oxpus,

danke für deine Ausführung und dein Verständnis für meine Idee.

Jetzt möchte ich ersteinmal das Feld 'Varcher' mit explode() umsetzen.

Habe die Daten schon vorbereitet, wenn du auf 'https://wasserwelt.org/tiere/alle.php?s=4&page=1' klickstt die ersten beiden Einträge sind mit Daten gefüllt.

wenn du eines anklickst musst du ein stück runterscrollen bis zu Vorkommen.

da steht dann: Array ( [0] => 552 [1] => 656 [2] => 684 [3] => 700 [4] => 707 [5] => 733 ) folgt aus dem Code:

<?php // Vorkommen
include($_SERVER["DOCUMENT_ROOT"].'/includes/lang/'.$lang.'/vorkommen_de.inc');

if($vorkommen)
$raus = explode(' ', $vorkommen);
// Ausgabe
print_r($raus);

?>

Jetzt muss nur noch jedes Zahlenfeld einen Ort ausgeben.

[oxpus]

danke für deine Ausführung und dein Verständnis für meine Idee.

Gerne.
Wenn es dazu auch zukünftig ausformulierte Anfragen und vollständigere Code-Happen gibt, würde das Erarbeiten einer Lösung auch schneller vonstatten gehen können

[...]
Jetzt muss nur noch jedes Zahlenfeld einen Ort ausgeben.

Ähm, wäre es nicht besser, erst das Datenmodell wie in meinem letzten Beitrag genannt umzubauen, bevor man eine solche Abfrage erstellt?

Ich gehe jetzt nicht ins Detail, um für Dein aktuelles Datenmodell die Ortsnamen abzufragen, welche ich auch an Deiner Stelle besser in einer DB-Tabelle und nicht in einer Datei speichern würde.
Allein schon daher, da ich Dein Datenmodell nicht kenne und Dein aktuelles Datenmodell nach Deinen bisherigen Ausführungen auch für wenig sinnvoll halte (dazu weiter unten mehr).

Hier zunächst das vereinfachte SQL-Beispiel für Deine Anfrage:

Code: Alles auswählen

$sql = "SELECT id, ortsname FROM orte
WHERE id IN " . (string) $vorkommen;

Da muss natürlich noch die Variable $vorkommen zur Absicherung maskiert werden (hatten wir bereits an anderer Stelle ausgiebig behandelt) und die Feld- und Tabellennamen wären auf Dein Datenmodell anzupassen.
Und nein:
Man kann innerhalb einer SQL-Abfrage nicht ein Feldinhalt "zerlegen" und die somit "gewonnenen" Werte mit einer anderen Tabelle logisch verknüpfen.
Dazu wäre entweder eine in der DB gespeicherte Funktionen oder eben die nachträgliche Abfrage und Zuordnung der Detaildaten (hier: Ortsnamen) mit einer zweiten Abfrage im Script nötig. Beides kostet Zeit und wäre unnötig, wenn man eine Untertabelle erstellt und diese logisch mit der Haupttabelle verknüpft.

Situation fehlender Ort

An dieser Stelle von mir etwas zum Nachdenken, um das Dilemma mit Deinem Datenmodell besser zu verdeutlichen:
Bitte in Ruhe durchlesen, bevor wir hier weitermachen!

Du hast in einem Datensatz z. B. 5 Vorkommen gespeichert, also 5 Zahlen im Feld "vorkommen", mit Kommata getrennt.
Was passiert, wenn davon eine Zahl in der Tabelle für die Ortsnamen nicht vorhanden ist, die Zahl also entweder falsch eingetragen oder der Ort nachträglich gelöscht wurde?

Mit Deiner "Idee" wäre im Script dieses auf jeden Fall abzufangen, um ein "leeres" Feld in der Darstellung auf der Webseite zu vermeiden.
Man könnte allerdings erst nach Abfrage der IDs für die Ortsnamen und der daraufhin abgefragten Ortsnamen im Script mit der "Korrektur" der Daten durchführen, würde also bereits unnötig falsche Daten aus der Datenbank abfragen; welche zudem auch unnötig Speicherplatz belegen würden.
Wohlgemerkt:
Das geschieht für jeden einzelnen Besucher Deiner Webseite. Bei wachsender Besucherzahl würden die zusätzlichen Aktionen zur Datenkorrektur im gleichen Maße ansteigen und Performanceeinbußen nach sich ziehen können; von anderen möglichen Nachteilen mal ganz abgesehen.

Mit einer Untertabelle wäre das Problem logisch gesehen so nicht vorhanden:
Werden die ID's aus der Untertabelle für die "Vorkommen" mit den Orten aus der "Orte"-Tabelle in einer Abfrage verknüpft abgefragt, werden falsche Zahlen nie mit aus der DB ausgelesen. Die Abfrage liefert also damit immer ein fehlerfreies Ergebnis, welche auch Deine Webseite nicht unnötig verlangsamen würde.

Und es geht noch weiter:

Ein nachträgliches Löschen eines Ortes (lassen wir an dieser Stelle die Notwenigkeit dazu mal unbeantwortet) könnte auch gleich alle betreffenden Datensätze in der "vorkommen"-Untertabelle mit entfernen.
Dafür wäre letztlich eine einfache SQL-Anweisung nötig, um sogleich auch alle Hauptdatensätze mit einem Schwung zu aktualisieren.
Die Ausführung kann nur gemessen werden, wogegen die Korrektur von zusammengeketteten ID-Werten in einem DB-Feld spürbar sein könnte.
Und diese Korrekturen wären auch immer für alle Datensätze nötig.

Des Weiteren kann man auch nicht auf eine ID als Teil eines Text-Feldes referenzieren, um die betreffenden Datensätze korrekt einzugrenzen.
Beispiel? Gerne:
1. Datensatz: 1,2,3,100
2. Datensatz: 100,200,3
3. Datensatz: 1
Hier wäre die Abfrage nach ID "1" nicht sicher nur im ersten und dritten Datensatz zu finden, da die "1" auch in der "100" im zweiten Datensatz steckt.
Mit dem Suchwert "1," (also 1 mit Komma) könnte man aber auch nicht abfragen, denn das würde den 3. Datensatz wiederum ausklammern.

Und das wäre nur wenige von vielen Vorteilen für verteilte und logisch verknüpfte Tabellen, welche man durch eine relationale Datenbank nutzen kann und sollte.
Ich würde also an Deiner Stelle Deine "Idee" noch einmal stark überdenken.

[Icke]

Guten Morgen Oxpus,

habe deine Datenmenge empfangen und bin am lesen.

[Icke]

Guten Morgen Oxpus,

o.k. wie fangen wir an?

stell doch einmal eine Arbeitsliste auf!

[oxpus]

Wir nur, wenn du mich beauftragst und bezahlst.

Aufgaben kann ich nennen:
1. Verwaltung der Orte aufbauen
- DB Tabelle dafür anlegen
- Script mit Formular für die Verwaltung erstellen
2. Daten aus .Inc Datei in neue DB Tabelle importieren
3. DB-Tabelle für Vorkommen als Untertabelle anlegen
4. Bestehende Vorkommen dorthin übertragen
5. In die Verwaltung die neue Tabelle für die Vorkommen einbinden
6. Die Vorkommen für die Darstellung inkl. der Ortsnamen mit einbinden

Soweit meine 'Mitarbeit'.
Alles andere dann nur noch über einen kostenpflichtigen Auftrag.