Est-il bon de stocker de longues chaînes dans une base de données?

Question

Je dois stocker de longues chaînes dans une base de données. la chaîne peut comporter 5 ou 6 phrases. Pensez-vous que ceci est une bonne stratégie de conception? ou dois-je stocker un identifiant pour cette chaîne, puis créer une relation avec une autre table contenant l'emplacement du fichier stockant la chaîne. pourriez-vous s'il vous plaît donner des avantages et des inconvénients des deux.

les chaînes ont été prétraitées et stockées dans la base de données. toute modification lirait la chaîne entière et la remplacerait complètement. vous pouvez donc supposer que la chaîne est indivisible.

Answer 1

Il devrait être correct de stocker la chaîne dans la base de données. Si vous stockez un pointeur de fichier à la place, cela signifie que vous devez effectuer une opération d'E / S sur fichier à chaque fois que vous souhaitez lire la chaîne. Quelques phrases ne sont pas très longues et vous pouvez toujours utiliser un champ de données longtext si vous en avez besoin. Évidemment, votre base de données sera un peu plus grande parce que vous avez le texte, mais ça va. C'est certainement une meilleure alternative que de devoir stocker les fichiers.

Answer 2

Les chaînes que vous mentionnez ne sont pas du tout longues.

Lorsque vous avez fait référence à " long " Je pensais à 32 Ko et plus - certaines phrases sont < 1 Ko - ce n’est rien aujourd’hui.

Votre astuce, stocker un identifiant ralentit les choses car vous devez créer un accès indirect.

La seule chose que je recommanderais, lorsque les performances maximales sont requises, vous devez sélectionner uniquement les colonnes dont vous avez besoin (omettez SELECT *) - omettez donc la colonne de texte, si vous n'en avez pas besoin, car le transport de la chaîne à partir du serveur à l'application coûte le plus de temps. C’est une bonne pratique de ne pas toucher aux colonnes inutiles (spécialement quand elles peuvent contenir beaucoup de données).

Answer 3

La seule raison pour laquelle je voudrais créer une table distincte est si ces longues chaînes sont les mêmes pour de nombreux enregistrements. Sinon, il s’agit simplement d’une complication supplémentaire qui ne rapportera probablement rien.

Answer 4

Cinq ou six phrases n’est rien pour un SGBD moderne! Stockez le texte directement dans la base de données.

(L’autre technique que vous avez mentionnée - stocker une référence dans une autre table, elle-même référencée dans un fichier externe contenant le texte - serait beaucoup plus lourde à utiliser et aurait une performance bien plus médiocre.)

Answer 5

La réponse dépend vraiment du volume de chaînes que vous souhaitez stocker et de la base de données que vous souhaitez utiliser pour le stocker. Si vous ne stockez pas beaucoup de chaînes, vous pouvez envisager de les stocker dans un fichier XML ou un fichier de ressources et de les charger dans votre application dès le départ. Cependant, si vous avez beaucoup de données de chaîne, vous ferez probablement mieux de lire la chaîne en mémoire lorsque vous en avez besoin, plutôt que de prendre le risque de lire une chaîne en mémoire que vous n'utiliserez pas.

Answer 6

La base de données elle-même n'a aucun problème avec le stockage de chaînes longues. Certaines restrictions s'appliquent (comme la limite de taille d'enregistrement de 8 Ko sur SQL Server), mais même dans ce cas, vous pouvez stocker du texte de longueur arbitraire dans une base de données, car toutes les règles appropriées prennent en charge les types de données BLOB / TEXT sans limite supérieure.

Cinq à six phrases, ce n’est pas vraiment long. S'ils vont ensemble et qu'ils doivent être récupérés et manipulés dans leur ensemble, vous pouvez les enregistrer et les stocker dans un champ de type de données CHAR de dimensions appropriées.

La question de savoir si les séparer et y attacher un ID ne se pose que si votre modèle d’application / de données bénéficie directement de cette approche, c’est-à-dire qu’il s’agit en réalité de choses distinctes. Dans votre cas, il ne semble y avoir aucune raison d’agir de la sorte.

Answer 7

Tout le monde a parlé de performance, mais personne n’a soulevé l’autre grande raison pour laquelle stocker des pointeurs sur des fichiers du système d’exploitation est une mauvaise idée: la sauvegarde et la restauration. Si tout est dans la base de données, nous disposons d'un mécanisme unique pour la sauvegarde des données et d'un mécanisme unique pour la récupération. Tandis qu'avec les fichiers sur le système d'exploitation, nous avons deux mécanismes de sauvegarde différents, probablement à deux granularités différentes, et la récupération devient un cauchemar de synchronisation.

Il existe quelques cas où cela ne s'applique pas, tels que les entrepôts de données, qui effectuent des transactions très peu fréquentes et peuvent donc survivre sans journaux de redo ou de transactions.

Answer 8

Sauf dans des cas particuliers, je quitterais le champ où il se trouve.

La seule autre option serait de placer les chaînes dans une table différente (en y insérant les chaînes réelles) ... leur mise dans des fichiers distincts va tuer votre performance.