tomgk: Speicherung von Seiten wie jimdo.com

Hallo!

Wie werden die Daten von Seiten wie jimdo.com gespeichert?
Ich möchte nämlich so was in der Art machen, aber ich weiß nicht wie ich das speichern soll

MfG
tomgk

--
Selfcode=ie:% fl:( br:> va:| ls:& rl:? n4:? ss:| de:] js:| ch:? sh:) mo:) zu:(
  1. hi,

    Wie werden die Daten von Seiten wie jimdo.com gespeichert?

    Frag die doch ganz einfach.

    Hotti

    1. Hallo!

      Glaubst du dass die das mir sagen?

      MfG
      tomgk

      1. Hallo!

        Glaubst du dass die das mir sagen?

        Wer denn sonst? Oder glaubst Du, dass es hier Leute gibt, die anhand der Betrachtung einer WebSite sagen können, wie dort die Daten gespeichert sind?

        Viele Grüße,
        Hotti

      2. Hi,

        Glaubst du dass die das mir sagen?

        Du möchtest einen Webseiten-Baukasten programmieren und weisst nicht, wie/wo man Daten abspeichert? Nicht Dein Ernst, oder...?
        Vielleicht probierst Du es doch erst mal mit einem weniger ehrgeizigen Projekt.

        Gruesse, Joachim

        --
        Am Ende wird alles gut.
  2. Hi!

    Wie werden die Daten von Seiten wie jimdo.com gespeichert?

    Serverseitig! Welche andere Antwort erwartest Du?

    Ich möchte nämlich so was in der Art machen, aber ich weiß nicht wie ich das speichern soll

    Serverseitig z.B. in einer relationalen Datenbank, als statische HTML-Dokumente, als Flat-File, als XML-Dokument etc. Wichtiger ist doch die Frage danach, welche Technik Dir zur Verfügung steht und Du idealerweise auch noch kennt!

    off:PP

    --
    "You know that place between sleep and awake, the place where you can still remember dreaming?" (Tinkerbell)
    1. Hallo!

      Serverseitig! Welche andere Antwort erwartest Du?

      Das ist ja klar.

      Serverseitig z.B. in einer relationalen Datenbank, als statische HTML-Dokumente, als Flat-File, als XML-Dokument etc. Wichtiger ist doch die Frage danach, welche Technik Dir zur Verfügung steht und Du idealerweise auch noch kennt!

      Ich möchte es auf jeden Fall in einer relationalen Datenbank speichern.

      Auf jimdo.com erstellt man eine Seite indem man verschiedene Elemente wie Überschriften, Paragrafen, Bilder und auch komplexere Elemente wie Formulare oder Gästebücher einfügt. Wenn es nur einfache Elemente wären, dann würde ich es als BBCode (nach einer wiki-ähnlichen Syntax) in einer TEXT speichern. Ich hab das schon versucht, aber das mit den komplexen Elementen ist ein Problem.

      Dann hab ich mir gedacht, das als XML zu speichern, aber der Text wird so lang und die "Sprache" könnte leicht mit (X)HTML verwechseln werden.

      Meine letzte Idee, alle Elemente extra als Datensätze in einer relationalen Datenbank zu speichern, verhindert eine Editierung des Quellcodes, was, wenn man die Syntax versteht, am schnellsten geht.

      Was davon ist eurer Meinung nach die beste Lösung oder weiß jemand eine bessere Lösung?

      MfG
      tomgk

      --
      Selfcode=ie:% fl:( br:> va:| ls:& rl:? n4:? ss:| de:] js:| ch:? sh:) mo:) zu:(
      1. moin,

        Was davon ist eurer Meinung nach die beste Lösung oder weiß jemand eine bessere Lösung?

        Hinsichtlich der Performance ist es am Besten, wenn die Seite, die der Server ausliefern soll, komplett als HTML Datei auf dem Server liegt. Das ist gleichzeitig auch CPU und RAM gefällig.

        Dynamic Content: Abstahiere, was an mehreren Seiten alles gleich ist und was veränderlich sein soll. Z.B. haben alle Seiten einen head-Bereich und einen body. Verschieden sind z.B. das Navigationsmenü, der body und der title-Tag usw.

        Die Wahl des Speicherorts für dynamische Inhalte (Attribute) ist jedoch immer eine Gratwanderung zwischen Performance und Sinnfälligkeit. Eine DB macht nur dann einen Sinn, wenn der DB Server auf derselben Maschine läuft, wie der Webserver. Das ist nicht bei jedem Provider der Fall. Textlich strukturierte Dateien hingegen, sind für größere Datenmengen ungeeignet, es frisst Zeit, z.B. die Attribute für 200 Seiten aus einer XML-Datei zu parsen, auch dann, wenn nur die Attribute für eine Seite gebraucht werden, muss die ganze Datei geparst werden. Hierzu gäbe es FastCGI-Lösungen, wo solche Tabellen im RAM gehalten werden. Eine sehr performante Alternative zur Datenhaltung sind Binärdateien.

        Hotti

        1. Hallo hotti.

          Eine DB macht nur dann einen Sinn, wenn der DB Server auf derselben Maschine läuft, wie der Webserver.

          Warum?

          Oder, mit anderen Worten: es wäre schön, wenn du deine Thesen mit Argumenten begründest.

          Servus,
          Flo

        2. Hallo Hotti,

          [..] zwischen Performance und Sinnfälligkeit. Eine DB macht nur dann einen Sinn, wenn der DB Server auf derselben Maschine läuft, wie der Webserver.

          Du wetterst gegen ganze Server- und Software-Architekturen, ohne dabei auch nur einen einzigen Ansatz zu liefern ?

        3. Hallo!

          Wie wäre es, wenn ich die Daten in einer DB speichere und dann in einer HTML-Datei speichere, die ich update, falls sich die Daten in der DB ändern?

          Eine sehr performante Alternative zur Datenhaltung sind Binärdateien.

          Werden DBs nicht in Binärdateien gespeichert?

          MfG
          tomgk

          --
          Selfcode=ie:% fl:( br:> va:| ls:& rl:? n4:? ss:| de:] js:| ch:? sh:) mo:) zu:(
        4. Eine DB macht nur dann einen Sinn, wenn der DB Server auf derselben Maschine läuft, wie der Webserver.

          Das ist ganz klar die neue "Nummer eins" meiner persönlichen WTF-Momente beim Lesen deiner Postings ;-)

          1. Bounjoun Pragma,

            Das ist ganz klar die neue "Nummer eins" meiner persönlichen WTF-Momente(...)

            Ich dachte immer, WTF steht für WHO-the-f...

            »Alice, Alice, who the f... is Alice?« [1]

            :)

            Adiou.

            [1] BTW: hat sich das damals auch das Kanichen gefragt, oder war Lewis Carrol zu höflich für solche f...ing Idioms?

        5. Hallo!

          Textlich strukturierte Dateien hingegen, sind für größere Datenmengen ungeeignet, es frisst Zeit, z.B. die Attribute für 200 Seiten aus einer XML-Datei zu parsen, auch dann, wenn nur die Attribute für eine Seite gebraucht werden, muss die ganze Datei geparst werden.

          Bei meiner Idee werden die Textdaten nicht in einer Text-Datei gespeichert, sondern in ein TEXT-Feld (heißt das so?) einer MySQL Datenbank. Ich finde meine Idee, die Daten als XML in der DB zu speichern nicht so gut. Ich möchte sie lieber in einer einfacheren Syntax speichern so was wie BBCode, nur halt an dem Problem angepasst. Es soll ja nicht nur bestimmt werden, ob was fett geschrieben ist, sondern auch beispielsweise die aktuellsten News eingebunden werden. Ich weiß aber nicht, wie ich die Syntax machen soll, damit sie nicht alzu komplex zum parsen ist, aber doch leicht verständlich.

          Oder soll ich, wie schon gesagt, nicht eine ganze Seite als Text in einen Datensatz speichern, sondern mit einer eigenen Tabelle? Die hat dann eine Spalte siteID, sodass sie der Seite zugeordnet werden kann. Da wird je nach Typ des Elements eine andere Funktion aufgerufen, die gegebenfalls Daten ladet und ein Model erstellt. Zum Schluss wird das ganze als XHTML an den Clienten geschickt.

          Hat jemand eine Idee oder einen Vorschlag?

          MfG
          tomgk

          --
          Selfcode=ie:% fl:( br:> va:| ls:& rl:? n4:? ss:| de:] js:| ch:? sh:) mo:) zu:(