Ankündigung

Einklappen
Keine Ankündigung bisher.

Riesige Texte in Datenbank speichern

Einklappen

Neue Werbung 2019

Einklappen
X
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • Riesige Texte in Datenbank speichern

    Hallo,

    ich bin gerade dabei, meine Website dynamisch zu gestalten und würde gerne die Seiteninhalte aus einer Datenbank laden lassen.

    Nun habe ich Seiteninhalte mit über 200.000 Zeichen Text...
    In meiner Google-Recherche habe ich gelesen, dass der Datentyp TEXT zwar für längere Texte empfohlen wird, aber auf 65.000 Zeichen begrenzt sei.

    Habe ich das richtig verstanden und falls ja, welche Alternativen habe ich?

    Lg

  • #2
    Zitat von K.Beutler Beitrag anzeigen

    Habe ich das richtig verstanden und falls ja, welche Alternativen habe ich?

    Lg
    PostgreSQL. 1GB je Feld.
    PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

    Kommentar


    • #3
      Ahoi,

      LONGTEXT wäre da sicher eine Alternative
      dev.mysql.com
      ------
      Grüße Manü

      Kommentar


      • #4
        PostgreSQL. 1GB je Feld.
        Wird wahrscheinlich eher schwierig, wenn mein Host (Strato) nur MySQL anbietet...

        LONGTEXT wäre da sicher eine Alternative
        Ah super! Guter Link, vielen Dank! Ja 4 Mrd. Zeichen sollten ausreichen sein

        Eine Frage hätte ich noch:
        Woran merke ich, wenn mein zu speichernder Text die maximale Länge der Kapazität des DB-Feldes überschreitet?
        Wird dann ohne Fehlermeldung einfach so viel vom Text abgespeichert wie reinpasst oder gibt mir MySQL wenigstens eine Fehlermeldung zurück?

        Lg

        Kommentar


        • #5
          Zitat von K.Beutler Beitrag anzeigen
          Wird dann ohne Fehlermeldung einfach so viel vom Text abgespeichert wie reinpasst oder gibt mir MySQL wenigstens eine Fehlermeldung zurück?

          Lg
          MySQL schneidet ab, PG wirft Fehler.
          PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

          Kommentar


          • #6
            Zum MySQL-Verhalten, siehe Handbuch zum Strict Mode: http://dev.mysql.com/doc/refman/5.7/...ql-mode-strict
            If strict mode is not in effect, MySQL inserts adjusted values for invalid or missing values and produces warnings.
            Hab aber keine MySQL-Instanz hier wo ich das testen könnte.

            Kommentar


            • #7
              Nur die dynamischen Daten in der DB und die Templates und Grafiken flat speichern.
              [PHP]if ($var != 0) {
              $var = 0;
              }[/PHP]

              Kommentar


              • #8
                Woran merke ich, wenn mein zu speichernder Text die maximale Länge der Kapazität des DB-Feldes überschreitet?
                ich fürchte da muss ne Validierung vorher hin. http://php.net/manual/de/function.strlen.php

                http://dev.mysql.com/doc/refman/5.1/...-overview.html
                LONGTEXT hat wohl " 4.294.967.295" als maximale Länge

                LG
                https://github.com/Ma27
                Javascript Logic is funny:
                [] + [] => "", [] + {} => object, {} + [] => 0, {} + {} => NaN

                Kommentar


                • #9
                  Bei großen Texten halte ich es genau so wie bei Grafiken, die haben für mich in einer Datenbank nichts verloren. Den (statischen) Text bzw. die Grafik in einem speziellen Ordner abgelegt und die Referenz in der Datenbank.

                  Edit: Habs glatt überlesen, Wolla hat es schon so ähnlich formuliert.

                  Kommentar


                  • #10
                    Zitat von K.Beutler Beitrag anzeigen
                    Hallo,
                    ich bin gerade dabei, meine Website dynamisch zu gestalten und würde gerne die Seiteninhalte aus einer Datenbank laden lassen.
                    was spricht eigentlich gegen eine Datei fuer die Inhalte? statt eine datenbank? formate wie markdown eignen sich ziemlich gut fuer solche spaese
                    apt-get install npm -> npm install -g bower -> bower install <package> YOLO [URL]https://www.paypal.me/BlackScorp[/URL] | Mein Youtube PHP Kanal: [url]https://www.youtube.com/c/VitalijMik[/url]

                    Kommentar


                    • #11
                      Hallöchen,

                      Zitat von BlackScorp Beitrag anzeigen
                      was spricht eigentlich gegen eine Datei fuer die Inhalte? statt eine datenbank? formate wie markdown eignen sich ziemlich gut fuer solche spaese
                      Die Datenbank ist nunmal der Esel der Neuzeit

                      *IHH* *AH*

                      Viele Grüße,
                      lotti
                      [SIZE="1"]Atwood's Law: any application that can be written in JavaScript, will eventually be written in JavaScript.[/SIZE]

                      Kommentar


                      • #12
                        Zitat von BlackScorp Beitrag anzeigen
                        was spricht eigentlich gegen eine Datei fuer die Inhalte? statt eine datenbank?
                        Die Diskussion ist alt. Um Dir aber 2 Stichworte zu nennen: Transaktionskontrolle und konsistente Backups. Der Rest, und das ist auch eine alte Erkenntniss, ist Abwägungssache der Vor- und Nachteile.
                        PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

                        Kommentar


                        • #13
                          Zitat von akretschmer Beitrag anzeigen
                          konsistente Backups.
                          also .md dateien kann man doch wunderbar in ein gitrepository packen und man haette sogar versionkontrolle im content (aehnlich wie bei github wiki)
                          Zitat von akretschmer Beitrag anzeigen
                          Transaktionskontrolle
                          koennte man das dann nicht auch mit Git loesen?

                          egal. ich will diese diskussion hier nicht unnoetig ausdehnen
                          apt-get install npm -> npm install -g bower -> bower install <package> YOLO [URL]https://www.paypal.me/BlackScorp[/URL] | Mein Youtube PHP Kanal: [url]https://www.youtube.com/c/VitalijMik[/url]

                          Kommentar


                          • #14
                            Wieso sollte man die Datenhaltung jetzt anhand der Größe zerpflücken? Dass Ressourcen i.a. separat gehalten werden, ist nervig genug. Nur da hat es noch Sinn, weil/wenn der Server diese Dateien direkt ausliefern kann, und der Client direkt einbinden. Bei Markup ist das nicht mehr gegeben.

                            Einzige Ausnahme wäre komplette Dokumente zu speichern, was man gemeinhin als Caching bezeichnet.

                            Die Datenbank ist nunmal der Esel der Neuzeit
                            Witzig. Sonst heißt es hier ebi jedem Textzugriff: "Warum benutzt Du keine Datenbank?"
                            [COLOR="#F5F5FF"]--[/COLOR]
                            [COLOR="Gray"][SIZE="6"][FONT="Georgia"][B]^^ O.O[/B][/FONT] [/SIZE]
                            „Emoticons machen einen Beitrag etwas freundlicher. Deine wirken zwar fachlich richtig sein, aber meist ziemlich uninteressant.
                            [URL="http://www.php.de/javascript-ajax-und-mehr/107400-draggable-sorttable-setattribute.html#post788799"][B]Wenn man nur Text sieht, haben viele junge Entwickler keine interesse, diese stumpfen Texte zu lesen.“[/B][/URL][/COLOR]
                            [COLOR="#F5F5FF"]
                            --[/COLOR]

                            Kommentar


                            • #15
                              Zitat von nikosch Beitrag anzeigen
                              Einzige Ausnahme wäre komplette Dokumente zu speichern, ...
                              Zitat von K.Beutler Beitrag anzeigen
                              Nun habe ich Seiteninhalte mit über 200.000 Zeichen Text...
                              Ich lese das so.

                              Kommentar

                              Lädt...
                              X