Je dois stocker de longues chaînes dans une base de données. La chaîne peut être de 5 ou 6 phrases de long. Pensez-vous que c'est une bonne stratégie de conception. Ou devriez-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 lit la chaîne entière et le remplacerait complètement. Donc, vous pouvez supposer que la chaîne est indivisible.
8 Réponses :
Cinq ou six phrases ne sont rien dans un SGBD moderne! Stocker le texte directement dans la base de données.
(l'autre technique que vous avez mentionnée - stocker une référence vers une autre table qui a lui-même une référence vers un fichier externe tenant le texte - serait beaucoup plus encombrant à utiliser et avoir beaucoup plus performant.)
"Les phrases de cinq ou six milliards n'est rien dans un SGBD moderne!"
Cela devrait être bien pour stocker la chaîne dans la base de données. Si vous stockez plutôt un pointeur de fichier, cela signifie que vous devez effectuer des fichiers d'E / S chaque fois que vous souhaitez lire la chaîne. Quelques phrases ne sont pas terriblement longues et vous pouvez toujours utiliser un champ de données à long terme si vous en avez besoin. Évidemment, votre base de données sera un peu plus grande parce que vous avez le texte, mais c'est bon. C'est certainement une meilleure alternative que d'avoir à stocker les fichiers.
La seule raison pour laquelle je créerais une table séparée est si ces longues chaînes seront les mêmes pour de nombreux enregistrements. Sinon, c'est juste une complication supplémentaire qui n'est pas susceptible de fournir une récupération.
Non ces longues chaînes sont différentes. Je comprends votre point, aucune table séparée ne doit être utilisée. Mais devrais-je stocker la chaîne dans le système de fichiers et détenir uniquement un pointeur sur le fichier dans la base de données ou stocker la chaîne dans la base de données elle-même. toute suggestion basée sur la performance.
@iamrohitbanga: Alors, Combien de temps sont-ils exactement? Quelque chose jusqu'à quelques kilo-octets (qui est assez grand pour le texte) est ok pour stocker dans la base de données. Tout ce qui précède cette limite est toujours d'accord, mais vous devez utiliser les types de données de texte que votre DBMS fournit. L'idée de les mettre au système de fichiers pour des raisons de performance a beaucoup de sens pour moi.
@iamrohitbanga: Ces chaînes ont vraiment besoin d'être d'une taille significative, nous parlons des multiples de 10k avant qu'il ne devienne viable de les stocker dans le système de fichiers avec toutes les complications qui apportent.
La réponse dépend vraiment du volume des chaînes que vous avez l'intention de stocker et de ce que vous avez l'intention d'utiliser pour la stocker. Si vous ne stockez pas de nombreuses chaînes, vous voudrez peut-être envisager de les stocker dans un fichier XML ou de ressources et le charger dans votre application à l'avance. Si vous avez beaucoup de données de chaîne cependant, vous serez probablement mieux en mémoire de lecture de la chaîne de la chaîne et lorsque vous en avez besoin, plutôt que de prendre la chance de lire une chaîne dans la mémoire que vous ne finissez pas.
La base de données elle-même n'a aucun problème réel avec le stockage de longues chaînes. Certaines restrictions s'appliquent (comme la limite de taille d'enregistrement 8K sur SQL Server), mais même dans la limite du texte de la longueur arbitraire dans une base de données, car toutes les options appropriées prennent en charge les types de données de blob / texte avec pratiquement aucune limite supérieure.
Cinq à six phrases n'est pas vraiment longue. S'ils appartiennent ensemble et sont destinés à être récupérés et manipulés dans son ensemble, vous pouvez aller de l'avant et les stocker dans un champ de type de données de caractère de dimensions appropriées.
La question de la séparer et de les séparer et de les attacher à leur identifiant uniquement si votre modèle d'application / données bénéficie directement de cette approche, c'est-à-dire qu'ils sont des choses distinctes. Dans votre cas, il ne semble y avoir aucune raison d'aller de cette façon.
Sauf case spécial, je quitterais le champ où il se trouve.
La seule autre option serait de mettre les chaînes dans une table différente (mettre les chaînes réelles dedans) ... les mettre dans des fichiers séparés tuera vos performances.
Les cordes que vous mentionnez ne sont pas du tout long.
Lorsque vous avez parlé de "longues" chaînes, je pensais à 32kb et au-dessus - certaines phrases sont <1kb - ce n'est rien aujourd'hui.
Votre truc, le stockage d'un identifiant rend les choses plus lentes puisque vous devez faire un accès indirect.
La seule chose que je recommanderais, lorsque des performances maximales sont nécessaires, vous ne devez sélectionner que les colonnes que vous avez besoin (OMIT SELECT *) - alors omettez la colonne de texte, lorsqu'il n'est pas nécessaire, car le transport de la chaîne du serveur aux applications coûte le plus de temps. C'est une bonne praxis, et non de toucher des colonnes non nécessaires (spécialement quand ils pourraient contenir beaucoup de données).
Tout le monde a mentionné la performance, mais personne n'a soulevé l'autre principale raison pour laquelle le stockage des indicateurs vers des fichiers OS est une mauvaise idée: la sauvegarde et la récupération. Si tout est dans la base de données, nous avons un seul mécanisme permettant de sauvegarder les données et un seul mécanisme de récupération. Alors que les fichiers du 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 des entrepôts de données, qui ont des transactions très peu fréquentes et peuvent donc survivre sans journaux de rétablissement ou de transaction.
En fait, c'est pourquoi SQL a le type de texte (OH et CLOB)