nicht angemeldet
Hi,
Ich möchte einen Internetauftritt eines Landkreises realisieren.
Woraus ich Seriosität und vor allem Zuverlässigkeit ableite.
Neben den üblichen Tourismus seiten, Umwelt, Sport, Gemeinden, Sehenswürdigkeiten soll auch ein "virtuelles Rathhaus" integriert werden.
(Onlineformulare, Verantwortliche und alles für was ein Rathhaus sonst so zuständig ist).
Online-Behördengänge?
Das wäre ein Projekt, mit dem ich mich sofort identifizieren könnte. (Technisch anspruchsvoll und nützlich für den Normalbürger.)
Datenverlust ist also offensichtlich *nicht* tolerierbar - wenn der Anwender etwas irgendwo eintragen will, dann *muß* es funktionieren.
Also ist eine "echte" Datenbank mit Transaktionskonzept wichtig - und Oracle wäre bei Deiner Größenordnung in der Tat das Produkt meiner Wahl gewesen. Gut, wenn die Betreiber sich damit schon auskennen.
Bis dahin ist ja alles kein Problem, das ginge ja auch mit statischen Seiten,
Je nachdem, ob "statisch" das ist, was Deine Anwender wollen (weiter unten erzählst Du von "Bilder austauschen", was ich nicht mehr als "statisch" empfinde).
das Problem ist, das die Ihre fertigen Seiten nachdem ich sie umgesetzt habe selbst pflegen wollen und keine HTML-Kenntnisse besitzen,
Das ist der wichtigste Punkt Deiner Fragestellung.
1. Wollen Deine Anwender "nur" die Inhalte pflegen (*dann* wären sie mit einer Oracle-Maskenoberfläche, z. B. SQL*forms, gut bedient, welche sie ggf. auch bereits kennen) *oder*
2. wollen sie auch das Aussehen der Dokumente ändern (Layout, "eigentlich" statische Texte usw.), *dann* geht die Aufgabenstellung in Richtung *Redaktionssystem*. (Und dieses *zusätzlich* zur Datenbank, nicht *statt* dieser.)
das heißt ich stelle das mir so vor, das die Änderungen über eine einfache Eingabemaske gemacht werden können und dann nur die neue Datei auf den Server geladen wird.
Gelegt? Da fehlt mir wieder die genaue Information, welcher Art die Änderungen sind.
1. Geht es um Inhalte der Datenbank, die sich jederzeit (durch Eingriff einees Beamten über seine SQL*forms-Maske oder gar durch Eingabe eines Besuchers via Browser) ändern können? Dann werden sich solche Dokumente sinnvollerweise *nur* voll-dynamisch erzeugen lassen (CGI oder Vergleichbares).
2. Oder geht es um Daten, die sich nur zu wenigen, genau bekannten Zeitpunkten ändern können (monatliche Eingabe etc.), so daß man als success event dieser Änderung einen Generatorlauf starten kann, welcher die betroffenen Seiten nun in der Tat einmalig neu berechnet und als Dateien abspeichert?
Beide Modelle haben etwas für sich: Das erste ist flexibler, das zweite performanter bei der Abfrage und weniger last-intensiv auf dem Server.
Zusätzlich wollen sie nicht nur Text sondern auch Bilder selbst ändern/aktuallisieren.
Und das ohne HTML-Kenntnisse? Das ist, äh - tapfer. Denn ich finde, die elementaren Kenntnisse, um in einer vorgegebene HTML-Seite Text zu ändern, sind leichter zu erwerben als die Kenntnisse, eine Graphik in einem vernünftigen, webtauglichen Format zu erstellen und sinnvoll (!) in eine HTML-Seite einzubinden.
(Die Wahrscheinlichkeit, daß Du ein Redaktionssystem haben willst, ist mit diesem Punkt etwas gestiegen ...)
Zusätzlich stelle ich mir vor, das zum Beispiel ein vorhandener Datensatz an Gaststätten integriert wird und der Benutzer dann zum Beispiel die PLZ eingibt und seine Daten dann ausgewertet werden und er alle Adressen mit der bestimmten PLZ bekommt.
Hm, das war ziemlich vage (was ist "integriert"? Von wem? Wer pflegt diese Daten?)
Letzten Endes versuchst Du offenbar, eine Suchmaschine zu beschreiben - das wiederum ist ein separates Problem, das sich angesichts des Datenbestands in einer Datenbank jederzeit nachträglich lösen läßt (es nagelt zumindest keine anderen Entscheidungen zu). Dazu wären dann genaue Suchfunktionen und ein Rohentwurf des Benutzer-GUI notwendig, welche wiederum Auswirkungen auf das Tabellendesign der zu durchsuchenden Daten haben würden - und der Entwurf einer relationalen Datenbank erfordert *mehr* als rudimentäre SQL-Kenntnisse ...
Zur Zeit arbeitet die Gemeinde mit Oracle und SQL.
Heißt das, daß die Anwender Deines Systems selbst SQL(-DML) beherrschen (und Queries im Dialog eingeben, was man z. B. in SQL*forms in eingeschränkter Form auch kann, oder in SQL*Plus nahezu uneingschränkt?)
Oder willst Du damit nur sagen, daß sie irgendwelche Anwendungen bedienen, welche ihrerseits SQL-statements an die Datenbank absetzen?
Die Antwort auf diese Frage würde viel über die Kompetenz Deiner Anwender aussagen ...
In wie weit kann ich jetzt meine "normalen" HTML-Seiten gestalten und ab wo kommt die Datenbank ins Spiel.
Wie verknüpfe ich dann den Code der die Abfrage stellt mit dem HTML-Teil.
Das hängt u. a. davon ab, wie sich diese Verknüpfung verhalten soll (statisch7dynamisch, siehe oben).
Letzten Endes sieht es so aus, daß Du Programme brauchst, welche Abfragen (SQL) an die Datenbank stellen und die empfangenen Ergebnisse in HTML formatieren. Dazu müßtest Du sowohl SQL beherrschen als auch eine Dir genehme Anwendungssprache (bei Oracle ist einiges dabei, die Sprache könnte C oder C++ sein; genauso gut wäre Perl denkbar, wenn Du den passenden DBI-Modul dazu hast).
Eine naheliegende Trennung zwischen Daten und Layout wäre dadurch denkbar, daß Du den zu generierenden HTML-Code nicht fest in diesen Programmen einbrennst, sondern ihn als Code-Schablonen in Dateien ablegst. Diese Dateien kann jemand nachträglich editieren, der zwar HTML verstehen muß, nicht aber Deine Programmiersprache(n).
Das wiederum würde die Verwendung einer Sprache nahelegen, die sehr gut mit Zeichenkettenersetzungen klar kommt - und in dieser Hinsicht kenne ich nichts Besseres als Perl. (Jede andere Sprache, die regular expressions unterstützt, wäre eine taugliche Alternative.)
Ich baue auf dieser Basis übrigens gerade selbst eine Suchmaschine, deren Aussehen der spätere Betreiber in einer solchen Schablonen-Datei vollständig selbst konfigurieren kann ...
Was muss auf dem Server installiert werden.
Im Prinzip:
1. das RDMBS (also in Deinem Falle Oracle), inklusive eventueller Dialoganbindungen zur Pflege des Inhalts (SQL*forms und SQL*Plus hatte ich genannt, die sind dabei, darauf basierend wären dann ggf. eigene Anwendungen zu schreiben),
2. der Webserver. über den die Besucher auf die Daten zugreifen,
3. Compiler/Interpreter Deiner Anwendungssprache (sind möglicherweise beim Betriebssystem dabei; Perl ist PD und schnell installiert)
Bei hinreichend hoher Last wäre es denkbar, Datenbank- und Webserver auf verschiedene Maschinen zu legen (Lastverteilung) und miteinander kommunizieren zu lassen; diese und vergleichbare Ideen sind der Grund, weshalb ich das UNIX-Prinzip, ein großes System nicht als Monolith zu gestalten, sondern aus vielen kleinen, flexiblen und stabilen Bausteinen flexiben (über shell-skripts) zusammenzustecken, so liebe.
Wie kann ich das ganze offline (ohne Server) testen?
Hm, das ist nicht so einfach. Den Webserver kriegst Du auf jeden PC drauf (etwas Anderes als Apache würde ich nicht guten Gewissens empfehlen können), aber der Datenbankzugriff ... hm.
Es könnte sein, daß Du den Modul, welcher die SQL-query ausführt und das Ergebnis zurückliefert, doppelt bauen mußt (in einer Testumgebung müßte er dann aus einer Datei lesen oder fest eingebrannte Ergebnisse liefern). Das ist ein nicht unwichtiges, aber separat lösbares Problem.
Ich hoffe, dass ich das Problem etwas besser dargestellt habe und freue mich über euere Hilfe.
Ja, das war *viel* besser - und daß es viele neue Rückfragen ausgelöst hat, liegt in der Natur der Sache.
Am Ende einer solchen Diskussion solltest Du eine Spezifikation des gesamten Projekts schreiben können - und in Deinem Falle dürfte die Seitenzahl nicht unter 50, vielleicht über 100 liegen ... (keine Panik jetzt - besser, die Fragen werden vorher gestellt und beantwortet als zu spät).
mfG - Michael