Mehrere Sprachen

[dedlfix]

Tach!

Das hat jetzt konkret auf das Problem der Mehrsprachigkeit des Fragenden was zu bedeuten?

Meine Frage bezog sich auf den von mir davor zitierten Kontext. Du beantwortest sie nicht diesbezüglich, sondern sprichst von etwas anderem. Auch die anderen konkreten Fragen lässt du unbeantwortet. Und da wunderst du dich, dass deine am Thema vorbeigehenden und nichts konkret beantwortenden Beiträge negativ bewertet werden?

Den seine Frage bezog sich auf die Art und Weise der Daten-Speicherung. Und mal ehrlich, eine Anwwendung dermaßen vom DB-Design abhängig zu machen, das ist doch ein Gemurkse ohne Ende.

Das mag bei großen Projekte der Fall sein, bei kleinen geht es eher in Richtung unnötige Verkomplizierung. Man braucht einen ausgewachsenen ORM nicht zwingend in jedem Projekt. Seine Flexibilität ist zwar nett, aber seine Komplexität auch nicht zu verachten.

Eine Änderung der Feldnamen würde einem Neubau der Anwendung gleichkommen.

Ach, wirklich? Mein Editor kann Suchen und Ersetzen.

Wobei es in Fakt genügen würde, eine Spalte LANG hinzuzufügen womit ein jeder Record eindeutig einer bestimmten Sprache zugeordnet werden kann.

Das ist mal wenigstens ein Punkt, der in Richtung einer möglichen Lösung geht. Der Nachteil daran ist, dass man für die Verwaltung der Texte eine Oberfläche benötigt, die die zusammengehörigen Übersetzungen gleichzeitig darstellen kann, wenn man sie direkt vergleichen können möchte. Pro Sprache eine Spalte hingegen ist zwar nicht wirklich flexibel, aber man hätte dann mit dem vermutlich vorhandenen phpMyAdmin oder ähnlichen datensatzorientierten Werkzeugen bereits eine Oberfläche, die gleichzeitiges Darstellen und Bearbeiten eines Textes in allen Sprachen ohne weiteres Zutun bietet, nebst der einfachen Übersicht, in welcher Sprache welche Texte fehlen. Spalte leer - Text fehlt. Mach das mal mit der anderen Methode, da braucht es ein etwas komplexeres SQL-Statement, um diese Information zu gewinnen.

Ob der Vorteil, ohne die Datenbankstruktur anzupassen und gegebenenfalls noch das Programm drumherum erweitern zu müssen, eine neue Sprache hinzufügen zu können, den restlichen Aufwand wert ist, vermag ich aus "meine kleine Webseite" nicht direkt zu entnehmen. Das kann ja auch tiefgestapelt sein. Insofern wäre meine Antwort so ausgefallen, dass sie die beiden Möglichkeiten und deren Eigenschaften aufzeigt, so dass der Fragende möglichst selbst zu entscheiden in der Lage ist, was für sein Projekt angemessen ist.

Aber meine Lösung geht ja in Richtung objektorientierte Datenhaltung,

Und das muss ein offensichtlich noch nicht so weit fortgeschrittener Programmierer aus dem was du nicht gesagt hast herausnehmen?

d.h., nur die Anwendung bestimmt wie der Abstrakte Datentyp aussieht und ab da ist es der Anwendung egal ob der von CD, Diskette, Dongel, Oracle, MySQL oder sonstwoher kommt.

Schön, aber wozu braucht er denn für "meine kleine Webseite" eine Entkopplung zwischen dem Model in der Datenablage und dem Modell in der Anwendung? Was ist das echte und nicht nur hypothetische Problem, was damit gelöst werden soll?

Das Nächste wäre dann die Sprachauswahl an sich und dafür gibt es die Content-Negotiation. Insofern wird, wenn unter einunddemselben URL Inhalte verschiedener Sprachen ausgehandelt werden, eben nicht der URL sondern ein internes Attribut dafür zuständig sein, was auch wieder eher für eine objektorientierte Datenhaltung spricht.

Erkläre bitte, welche konkreten Vorteile die Objektorientiertheit für "meine kleine Webseite" bietet, die mit herkömmlichen Datenstrukturen nicht zu erreichen sind.

dedlfix.