Mehrere Lösungswege eines Threads zulassen

[dedlfix]

Tach!

Wenn man nun z.B. zu einer Person mehrere Telefonnummern hat, dann kann man die Tabelle um eine entsprechende Anzahl von Spalten erweitern. Man erhält dann t.B. Tel1, Tel2, Tel3 usw.
Das Dumme daran ist nur, dass dann die Felder Tel2 und Tel3 in den Datensätzen der anderen Personen erstmal leer bleiben, denn die haben in unserem Beispiel nur eine Telefonnummer.
Das ist also schon mal vergeudeter Speicherplatz.

Arbeitet du etwa mit CHAR statt VARCHAR?

Wenn Du nun die Sprachen nicht mehr horizontal speicherst, sondern vertikal, dann sparst Du i.d.R. Platz.

Weil man da statt eines Kommas zwischen den Werten in jeder Zeile gegebenenfalls eine ID, auf alle Fälle aber ein Bezug zur Person (üblicherweise Integerfeld) verwendet werden muss?

Relationale Datenbanken sind entstanden, als Speicherplatz noch knapp war und Zugriffszeiten noch lang. Man hat daher verschiedene Dinge eingeführt:
Durch Datensätze mit fester Satzlänge und -Struktur und damit fester Feldlänge war der "Random Access" auf jedes Feld jedes Datensatzes möglich.

Die Zeiten sind vorbei, seit es VARCHAR gibt.

Deine Argumentation bezüglich des Speicherplatzes geht an der Frage vorbei, ob man alle Werte in einem Feld oder in mehreren Feldern oder in mehreren Zeilen speichert. Die eigentliche Überlegung sollte sich die Vor- und Nachteile bezüglich der Handhabung vor Augen führen, damit der Probleminhaber sich entscheiden kann, was zu seiner Aufgabenstellung am besten und mit dem geringstmöglichen Aufwand passt.

Die Mehrfelder-Lösung hat die Nachteile, dass das Schema angepasst werden muss, wenn Sprachen hinzukommen. Je nach Abfrage muss man sich das Statement individuell zusammenbasteln, wenn nach bestimmten Sprachen und -kombinationen gesucht werden soll, wel jedes Mal die Feldnamen berücksichtigt werden müssen.

Bei der Komma-Lösung lassen sich die Sprachen vergleichsweise einfach schreiben und lesen. Beim Abfragen wird es aber herausfordernd, weil man nun mit Stringfunktionen die Werte zwischen den Kommas ansprechen muss - zumindest dann, wenn man FIND_IN_SET() nicht verwenden kann.

Die Jede-Sprache-ein-Datensatz-Lösung ist aus DBMS-Sicht die beste, weil dieses damit die Rohdaten mengenbasiert verarbeiten kann und nicht teure Stringoperationen für jeden Datensatz der Tabelle ausführen muss, für die dann auch kein Index verwendet werden kann. Diese Lösung ist aber bei der Datenpflege aufwendiger, weil es bei Änderungen erforderlich sein kann, dass man mehrere/alle Datensätze berücksichtigen muss.

Es gibt sicher noch eine Menge weitere Szenarien, die mir gerade nicht einfallen. Auch weiß ich nicht, was der TO am Ende des Tages alles für Features in seiner Anwendung haben möchte, und ob sich dafür die eine oder andere Lösung besser eignet oder besser in die Sackgasse führt.

dedlfix.