Webbasierte Datenbankanwendung mit php, MySQL, XML, XSLT, (X)HTML und CSS

[DAI_BA]

Hallo,

ich entwickle gerade ein Konzept für die Entwicklung einer webbasierten Datenbankanwendung. Ziel ist das Erstellen einer GUI, die per Browser abrufbar ist und für die Abfrage, Pflege und Eingabe von Daten dient.

Das vorhandene Datenbank-Modell besteht aus etwa 70 Tabellen, die gemeinsam etwa 2500 Spalten/Attribute besitzen. Da diese Datenbankstruktur als Grundlage für verschiedene Projekte dienen soll, die selten jeweils alle Tabellen der Datenbank benötigen, möchte ich die Anwendung modular aufbauen, um nur benötigte Module für die jeweiligen Projekte „freizugeben“.

Dieses Konzept möchte ich bis auf die Feldebene herunterbrechen, damit folgendes fiktives Szenario denkbar wäre:
Projekt A und B benötigen das Modul „Kundenkartei“. Jedoch benötigt nur Projekt B das Feld „Ansprechpartner“, andererseits benötigt nur Projekt A das Modul „Einkauf“.

An dieser Stelle würde ich beispielsweise über eine XML-Datei die Projekte konfigurieren, wobei in den einzelnen „Projektzweigen“ der XML-Datei die verwendeten Module mit den jeweils benötigten Feldern vermerkt sind. Allerdings bin ich mir über die effektive Realisierung der Eingabemasken noch nicht ganz klar.

Für die Ausgabe dachte ich an folgende Variante:
Die ausgelesenen / abgefragten Datensätze könnten in XML-Strukturen gespeichert werden, um dann mittels XSLT in (X)HTML-Code gewandelt zu werden, welcher dann per CSS ein Layout erhält. Durch Nutzung von XML würde sich an dieser Stelle vermutlich der Aufwand zur Implementierung geforderter Exportfunktionen (z.B. pdf) deutlich minimieren.

EDIT:
Die gesamte Anwendung soll (derzeit) MySQL als Datenbank nutzen - welche Möglichkeiten gibt es, die Anbindung so flexibel zu gestalten, daß auch ein (späterer) Wechsel zu einer anderen Datenbank (z.B. PostgreSQL) möglich wäre?
/EDIT

Für die gesamte Anwendung soll natürlich MVC als Architekturmuster zum Einsatz kommen, da davon auszugehen ist, daß die Anwendung langjährig im Einsatz sein wird und laufenden Anpassungen unterliegen wird, die möglichst leicht einpflegbar sein sollten.

Was haltet ihr von diesem Konzept? Ist diese Vorgehensweise „state-of-the-art“ und „zukunftssicher“ oder ist es in diesem Anwendungsfall ein völlig falsches Vorgehen? Für Anregungen, Hinweise und Feedback – insbesondere hinsichtlich der Dateneingabe - bin ich sehr dankbar.

Vielen Dank und viele Grüße

[tontechniker]

Wichtig ist von Anfang an darauf zu achten, das die Module miteinander agieren können und nicht zu stark von einander abhängig sind.

Die gesamte Anwendung soll (derzeit) MySQL als Datenbank nutzen - welche Möglichkeiten gibt es, die Anbindung so flexibel zu gestalten, daß auch ein (späterer) Wechsel zu einer anderen Datenbank (z.B. PostgreSQL) möglich wäre?

Zum einen musst du darauf achten, das die Queries in allen Treibern funktionieren die du unterstützten möchtest (wenn du MVC nutzen möchtest solltest du dich über Active Records informieren, da kannst du dann eine Menge Arbeit sparen), zum anderen solltest du von Anfang an mehrere Datenbanktreiber unterstützen.

[Quetschi]

Re: Webbasierte Datenbankanwendung mit php, MySQL, XML, XSLT, (X)HTML und CSS

Original geschrieben von DAI_BA

An dieser Stelle würde ich beispielsweise über eine XML-Datei die Projekte konfigurieren, wobei in den einzelnen „Projektzweigen“ der XML-Datei die verwendeten Module mit den jeweils benötigten Feldern vermerkt sind. Allerdings bin ich mir über die effektive Realisierung der Eingabemasken noch nicht ganz klar.

Ich habe mir für solche Sachen eine Formular-Klasse geschrieben - die Konfiguration erfolgt über die Tabellen 'Form', 'FormFieldsets', 'FormFields' und 'FormFieldChecks'. Man kann in Form dann eben grundsätzliche Eigenschaften des Formulars festlegen (action, id, enctype, usw.), FormFieldsets definiert dann eben Feldgruppen mit evtl. Überschriften, Beschreibungen usw. und in FormFields werden dann zu den Feldgruppen halt die Inputs (typ, label-Bezeichnungen, Default-Values usw.) festgelegt und ggf. eine CheckID eingetragen, die auf die FormFieldChecks-Tabelle verweist wo z.B. RegEx oder mustFilled usw. und passende Fehlerbeschreibungen abgespeichert werden.

Schlägt eine oder mehrere der Prüfungen fehl, wird das Formular natürlich mit den eingebenen Werten wieder dargestellt, oben drüber kommt dann ein per CSS schön rot hervorgehobener Kasten mit den Fehlerbeschreibungen und zusätzlich werden auch die Label-Bezeichnungen und Inputs entsprechend per CSS auffällig markiert.

Ist alles OK geschieht eigentlich in dieser Klasse nichts mehr weiter - was mit den _POST/_GET Daten weiter geschieht entscheidet sich dann in anderen Klassen, die die Daten z.B. eben in ne DB schreiben, per Mail versenden oder sonst was.

Original geschrieben von DAI_BA
Für die Ausgabe dachte ich an folgende Variante:
Die ausgelesenen / abgefragten Datensätze könnten in XML-Strukturen gespeichert werden, um dann mittels XSLT in (X)HTML-Code gewandelt zu werden, welcher dann per CSS ein Layout erhält. Durch Nutzung von XML würde sich an dieser Stelle vermutlich der Aufwand zur Implementierung geforderter Exportfunktionen (z.B. pdf) deutlich minimieren.

Ich arbeite nun fast ca. 2 Jahre eigentlich nur noch so und im Moment fällt mir nichts praktikableres und anpassungsfähigeres nicht ein. Auch die Formular-Klasse basiert letztenendes darauf, dass aufgrund der Konfiguration ein Xml erstellt wird das zum Schluss per Xslt ins gewünschten html geformt wird.

[Quetschi]

Original geschrieben von tontechniker
Wichtig ist von Anfang an darauf zu achten, das die Module miteinander agieren können und nicht zu stark von einander abhängig sind.

Jau - leider eine Schwäche von mir .
Muss manchmal doch feststellen das mir gewissen Abhängigkeiten der Klassen untereinander entstehen, die es dann eben erfordern die Abhängigkeiten zu beseitigen oder bestimmte Funktionen neu aufzusetzen.

Hab halt eben rein prozedural angefangen und das kriegt man irgendwie in meinem Alter wohl nicht mehr vollständig weg - so wie mir jedes Frühjahr auch auf dem Rennrad erst wieder angewöhnen muss schön rund zu treten

[DAI_BA]

Hallo,

zunächst vielen Dank für die Antworten. Als Anfänger finde ich es sehr angenehm und gibt es mir Sicherheit, wenn erfahrene Spezialisten Feedback geben.
Leider ist mir die Funktionsweise Deiner Formularklasse noch nicht ganz klar. Einerseits würde ich gern wissen, ob die Klassen letztlich XML ausgeben, um dann per XSLT in XHTML transformiert zu werden und andererseits frage ich mich, wie Du die Konfiguration realisierst. Du sprichst von meheren Tabellen - definierst Du also Module und Felder in einer Datenbank statt einer XML-Konfigurationsdatei? Der Vorteil liegt hier sicher z.B. in der Redundanzfreiheit, sobald ein Feld in verschiedenen Formularen auftritt.

Viele Grüße und ein schönes Wochenende

[Quetschi]

Original geschrieben von DAI_BA
...wenn erfahrene Spezialisten Feedback geben.

erfahrener Spezialist? Ich? Na, ned wirklich...

Original geschrieben von DAI_BA
Leider ist mir die Funktionsweise Deiner Formularklasse noch nicht ganz klar. Einerseits würde ich gern wissen, ob die Klassen letztlich XML ausgeben, um dann per XSLT in XHTML transformiert zu werden und andererseits frage ich mich, wie Du die Konfiguration realisierst. Du sprichst von meheren Tabellen - definierst Du also Module und Felder in einer Datenbank statt einer XML-Konfigurationsdatei? Der Vorteil liegt hier sicher z.B. in der Redundanzfreiheit, sobald ein Feld in verschiedenen Formularen auftritt.

Jup - kommt ein Xml raus, das dann transformiert wird - hat halt den Vorteil, dass man z.B.
<label for="Name">Name</label><input type="text" name="Name" id="Name" />
oder
<input type="text" name="Name" id="Name" /> <label for="Name">Name</label>
transformieren lassen kann oder für Feldgruppenüberschriften halt zwischen h1, h2 usw. durchs xsl wählen kann.

Ja, hab mich hier damals für DB-Tabellen-Config entschieden, was aber ned sein müsste - ich glaub ich würde heute auch ne Xml-Config vorziehen. Die Redundanzfreiheit hab ich bei meiner Lösung übrigens übersehen und war bisher zu Faul das noch zu normalisieren (soviel nochmal zum Thema erfahrener Spezialist)