Artikel speichern
0 3 
dedlfix
0 1 Felix Riesterer
0 0 0 dedlfix
1
0
Artikel speichern
marctrixMoin zusammen,
In meinem aktuellen Projekt muss ich längere Texte speichern und wieder zugänglich machen. Meine Frage(n) an euch ist:
Wie würdet ihr diese Texte speichern? Also würdet ihr die Texte in einer Datenbank speichern oder als einzelnen Dateien (txt, pdf etc.)?
Gruß MH
-
Hallo MH,
meine persönliche Meinung, ganz klar in einer Datenbank. Damit hast du die meisten Möglichkeiten. Auch das Anbieten einer PDF oder TXT Datei ist damit möglich.
Bis bald!
Meowsalot (Bernd) -
Tach!
Wie würdet ihr diese Texte speichern? Also würdet ihr die Texte in einer Datenbank speichern oder als einzelnen Dateien (txt, pdf etc.)?
Ohne genaue Kenntnisse des Anwendungsfalles ist es schwierig eine Entscheidung zu treffen. Auch die Art, wie sie weiterverwendet werden sollen, müsste man berücksichtigen. Wenn sie bereits als Datei vorliegen, kannst du sie auch als solche verwalten. Ansonsten spricht vermutlich auch nicht viel gegen eine Ablage in der Datenbank.
dedlfix.
-
Hi,
Ohne genaue Kenntnisse des Anwendungsfalles ist es schwierig eine Einscheidung zu treffen.
Das ist quasi sowas wie eine Zeitungsseite. Man kann sich anmelden, Texte schreiben und speichern. Man sollte die Texte jedoch auch bearbeiten können. Jeder andere angemeldete Nutzer kann diese Texte dann wieder aufrufen und lesen. "Mehr" jedoch nicht.
Gruß
MH-
Tach!
Das ist quasi sowas wie eine Zeitungsseite. Man kann sich anmelden, Texte schreiben und speichern. Man sollte die Texte jedoch auch bearbeiten können. Jeder andere angemeldete Nutzer kann diese Texte dann wieder aufrufen und lesen. "Mehr" jedoch nicht.
Dann Datenbank.
dedlfix.
-
Hej Marc Haunschild,
Ohne genaue Kenntnisse des Anwendungsfalles ist es schwierig eine Einscheidung zu treffen. Das ist quasi sowas wie eine Zeitungsseite. Man kann sich anmelden, Texte schreiben und speichern. Man sollte die Texte jedoch auch bearbeiten können. Jeder andere angemeldete Nutzer kann diese Texte dann wieder aufrufen und lesen. "Mehr" jedoch nicht.
Gibt es unter den vielen kostenlosen CMSen keines, dass dies für dich zufriedenstellend löst?
Ist billiger, sicherer und schneller…
Marc
-
Hi,
Ohne genaue Kenntnisse des Anwendungsfalles ist es schwierig eine Einscheidung zu treffen. Das ist quasi sowas wie eine Zeitungsseite. Man kann sich anmelden, Texte schreiben und speichern. Man sollte die Texte jedoch auch bearbeiten können. Jeder andere angemeldete Nutzer kann diese Texte dann wieder aufrufen und lesen. "Mehr" jedoch nicht.
Praktisch eine Erweiterung der Attribute eines angemeldeten Benutzers. Was ja auch wieder für eine objektorienierte Datenhaltung spricht.
MfG
-
Hej MH,
Hi,
Ohne genaue Kenntnisse des Anwendungsfalles ist es schwierig eine Einscheidung zu treffen. Das ist quasi sowas wie eine Zeitungsseite. Man kann sich anmelden, Texte schreiben und speichern. Man sollte die Texte jedoch auch bearbeiten können. Jeder andere angemeldete Nutzer kann diese Texte dann wieder aufrufen und lesen. "Mehr" jedoch nicht.
Sinnvollerweise würdest du nicht einen Text speichern, sondern einen Text, eine Überschrift, zugehörige Daten wie Bilder, eine ID für den Datensatz, der sich da entwickelt, einen Autorennamen, ein Veröffentlichungsdatum, Flags um zu wissen, wer welche Rechte auf diesen Datensatz hat (Autor, angemeldete Nutzer, Admin, nicht angemeldete Nutzer)…
Vielleicht gibt es Tabellen, Bildergalerien usw, die anders verwaltet, aber verknüpft sein wollen. — Noch einmal die Frage: warum willst du das selber entwickeln?
Es kann dafür Gründe geben. Aber es gibt wirklich schon für fast jeden Einsatzzweck ein CMS.
Es sei denn, du willst damit einfach lernen. Aber dann sollte es kein produktiv-System sein, dem eine größere Anzahl von Nutzern die eigene Arbeit anvertraut…
Marc
-
-
Lieber dedlfix,
eine Einscheidung zu treffen.
wieder ein neues Wort gelernt. ;-)
Liebe Grüße,
Felix Riesterer.
-
-
Klare Antwort:
"Das kommt drauf an."
Und zwar darauf, welche Anzahl sich hinter "Texte" verbirgt, welche Quantität das "längere" verbirgt und was GENAU mit "wieder zugänglich machen" gemeint ist. Es kann also vorteilhaft sein, die Texte - verschlagwortet und mit Metadaten - in einer Datenbank zu speichern, es kann aber auch Vorteile haben, dieses zu lassen. Man kann sogar Einiges in Dateinamen hineinkodieren.
Wenn man es so will ist nämlich das Dateisystem auch eine Datenbank. Es kann zwar kein SQL, aber die Gebrüder "ls, find,grep & Co" haben nette Werkzeuge im Schrank.
Ob die funktionieren? Gib hier mal wie "PHP", "Linux", "Feiertag" oder "Python" ein. Gern als Regex... Der "Server" ist sowas wie ein Raspi.
-
Liebe Regina,
Der "Server" ist sowas wie ein Raspi.
Odroid?
Liebe Grüße,
Felix Riesterer.
-
Odroid
… wäre wohl die bessere Wahl gewesen. Ist ein Banana Pi.
-
-
-
Moin,
nach einigem Überlegen und euren Antworten hab ich mich jetzt für die Datenbank entschieden. Danke auf jeden Fall für eure Antworten und Hilfe 👍
Nächste Frage die sich dadurch für mich anschließt:
Welchen Datentyp soll das Feld in der MySQL-Datenbank haben?Ich hätte als erstes Text bzw. Longtext gesagt, hab aber an anderen Stellen auch häufig BLOB gelesen. Das "besondere" an Text ist ja, dass beim Sortieren und Vergleichen nicht auf Groß- und Kleinschreibung geachtet wird. Dies wird aber eigentlich nicht gebraucht in diesem Fall.
Gruß
MH-
Tach!
Welchen Datentyp soll das Feld in der MySQL-Datenbank haben?
Ich hätte als erstes Text bzw. Longtext gesagt, hab aber an anderen Stellen auch häufig BLOB gelesen.BLOB ist für Binärdaten, nimm ein Text-Feld für Text.
dedlfix.
-
Welchen Datentyp soll das Feld in der MySQL-Datenbank haben?
DAS Feld gibt es nicht. Was mir 2stante pede" einfällt ist:
- int oder bigint für eine Dokument-ID.
- Blob für PDFs, andere binäre Dokumente und den originalen Text.
- Text für alles, was als Plaintext reinkommt. Vergiss nicht die Umkodierung wg. der Zeichensätze. Nutze das Textfeld auch für parallel gespeicherte, automatisch erzeugte Text-Präsentationen der binären Dokumente (pdf2text, html2text, ..., was auch immer). Diese Spalte muss dann den Text in konstanter, also festgelegter Kodierung enthalten.
- Text für Angabe des originalen MimeTyps (Es sei denn Du willst dafür eine Tabelle, dann Integer)
- Text (bei eigenet Tabelle: Int) für Angabe der originalen Kodierung
- Wenn Metadaten in anderen Tabellen stehen int oder ggf ENUM für Zugriff auf deren IDs (z.B. Autoren, Kategorien, Schlagwörter), Freilich kannst Du auch mit einer Dokument ID auf eine weitere n:m-Tabelle (eg. mit Spalten "dokumentID", "KategorieID") zielen.
- DateTime für alle Zeitangaben ...
lese über Normalisierung nach. Sowas will man sorgfältig planen und GLEICH daran denken, dass kleine Anwendungen GROSS werden können.
-
-
Kommt darauf an, wie die Texte reinkommen. Wohl am wenigsten in Form von Textdateien oder? Kriegst Du die Texte per Mail? Oder werden die als Word~Dokumente hochgeladen? Oder als PDF? Wahrscheinlich jedoch in sehr verschiedenen Dateiformaten:
Und das heißt, daß Du beim Erfassen schon einige Informationen mehr brauchst als nur die Texte. Also mindestens den Content-Type, damit Du den beim Wieder~zugänglich~machen richtig ausgeben kannst. Evntl gehört da noch der Name des Autors dazu und auf jeden Fall das Einsende~Datum.
Also ich würde jeden Dateneingang als Objekt betrachten mit unterschiedlichen Eigenschaften. Das alles spricht eher für eine objektorientierte Datenhaltung.
MfG