Ist es gut, lange Strings in einer Datenbank zu speichern?

Question

Ich muss lange Zeichenfolgen in einer Datenbank speichern. Die Zeichenfolge kann 5 oder 6 Sätze lang sein. Glaubst du, das ist eine gute Designstrategie? oder sollte ich eine ID für diese Zeichenfolge speichern und dann eine Beziehung mit einer anderen Tabelle erstellen, die den Speicherort der Datei enthält, in der die Zeichenfolge gespeichert ist. könnten Sie bitte Vor- und Nachteile von beiden geben.

Die Strings wurden vorverarbeitet und in der Datenbank gespeichert. Jede Änderung würde die gesamte Zeichenfolge lesen und sie vollständig ersetzen. Sie können also davon ausgehen, dass die Zeichenfolge unteilbar ist.

Answer 1

Es sollte Es ist in Ordnung, die Zeichenfolge in der Datenbank zu speichern. Wenn Sie stattdessen einen Dateizeiger speichern, müssen Sie jedes Mal, wenn Sie die Zeichenfolge lesen möchten, Datei-E/A ausführen. Ein paar Sätze sind nicht sehr lang und Sie können immer ein Longtext-Datenfeld verwenden, wenn Sie müssen. Offensichtlich wird Ihre Datenbank ein bisschen größer sein, weil Sie den Text haben, aber das ist in Ordnung. Es ist sicherlich eine bessere Alternative als die Dateien zu speichern.

Answer 2

Fünf oder sechs Sätze sind nichts für ein modernes DBMS! Speichern Sie den Text direkt in der Datenbank.

(Die andere Technik, die Sie erwähnt - eine ref an einen anderen Tisch zu speichern, die sich einen ref auf eine externe Datei hat den Text halten - wäre viel umständlicher viel schlechtere Leistung zu verwenden und zu haben.)

Answer 3

Der einzige Grund, ich würde eine separate Tabelle erstellen, wenn diese langen Strings für viele Datensätze identisch sind. Ansonsten ist es nur eine zusätzliche Komplikation, die keine Rückzahlung verspricht.

Answer 4

Die Antwort hängt wirklich von der Menge der Zeichenfolgen ab, die Sie speichern möchten, und von welcher Datenbank Sie beabsichtigen, sie zu speichern. Wenn Sie nicht viele Zeichenfolgen speichern, sollten Sie in Erwägung ziehen, sie in einer XML- oder Ressourcendatei zu speichern und diese im Vorfeld in Ihre Anwendung zu laden. Wenn Sie jedoch viele String-Daten haben, werden Sie wahrscheinlich besser daran arbeiten, die Zeichenfolge je nach Bedarf zu lesen, anstatt die Möglichkeit zu nutzen, eine Zeichenfolge in den Speicher zu lesen, die Sie nicht verwenden.

Answer 5

Die Datenbank selbst hat kein echtes Problem beim Speichern langer Strings. Es gelten einige Einschränkungen (wie die Größenbeschränkung der 8k-Datensätze in SQL Server), aber selbst dann könnten Sie Text beliebiger Länge in einer Datenbank speichern, da alle richtigen BLOB/TEXT-Datentypen praktisch ohne Obergrenze unterstützen.

Fünf bis sechs Sätze ist nicht wirklich lang. Wenn sie zusammengehören und als Ganzes abgerufen und bearbeitet werden sollen, können Sie sie in einem CHAR-Datentypfeld mit geeigneten Dimensionen speichern.

Die Frage, ob sie zu trennen und eine ID an sie anzuhängen, entsteht nur, wenn Ihr Anwendung/Datenmodell direkt von diesem Ansatz profitiert, d. H. In Wirklichkeit sind sie getrennte Dinge. In Ihrem Fall scheint es keinen Grund zu geben, so zu gehen.

Answer 6

Außer in besonderen Fällen würde ich das Feld verlassen, wo es ist.

Die einzige andere Option wäre, die Zeichenfolgen in eine andere Tabelle zu setzen (die eigentlichen Zeichenfolgen einzufügen) ... wenn Sie sie in separate Dateien schreiben, wird Ihre Leistung beeinträchtigt.

Answer 7

Die von Ihnen erwähnten Strings sind nicht lang.

Wenn Sie auf "lange" Strings verwiesen, dachte ich über 32kB und darüber - einige Sätze sind < 1kb - das ist heute nichts.

Ihr Trick, Speichern einer ID macht die Dinge langsamer, da Sie einen indirekten Zugriff haben müssen.

Das einzige, was ich empfehlen würde, wenn maximale Leistung benötigt wird, sollten Sie nur die Spalten auswählen, die Sie benötigen (SELECT * weglassen) - so die Textspalte weglassen, da nicht der Transport der Zeichenfolge aus Server zu Anwendung kostet die meiste Zeit. Es ist eine gute Praxis, nicht benötigte Spalten nicht zu berühren (besonders wenn sie viele Daten enthalten können).

Answer 8

Jeder hat Leistung erwähnt, aber niemand hat den anderen Hauptgrund angesprochen, warum das Speichern von Zeigern auf Betriebssystemdateien eine schlechte Idee ist: Sicherung und Wiederherstellung. Wenn alles in der Datenbank ist, haben wir einen einzigen Mechanismus zum Sichern der Daten und einen einzigen Mechanismus für die Wiederherstellung. Bei Dateien auf dem Betriebssystem haben wir zwei verschiedene Sicherungsmechanismen, wahrscheinlich mit zwei verschiedenen Granularitäten, und die Wiederherstellung wird zu einem Albtraum der Synchronisation.

Es gibt einige Fälle, in denen dies nicht zutrifft, z. B. Data Warehouses, die sehr selten Transaktionen haben und daher ohne Redo oder Transaktionsprotokolle überleben können.