Discussion :

[Titum]

Bonjour à tous,
Je fais une base de données dont plusieurs tables auront une colonne (ou plus) pouvant contenir plusieurs milliers de caractères.
Sachant qu'à terme il y aura plusieurs milliers d'enregistrement dans ces tables, je me demande à partir de quelle taille il est recommandé de sortir quelques grosses données pour les conserver en fichier à côté de la base.

Ces grosses données seront accédées plusieurs fois pendant un processus de travail puis ensuite très rarement.
C'est pourquoi je me dis que ça peut alléger les ressources de la base sans vraiment ralentir l'affichage des données complètes quand nécessaire.
Certaines sont des XML et d'autres juste du texte.

Merci pour vos éclairages sur cette question !

[CinePhil]

Je fais une base de données dont plusieurs tables auront une colonne (ou plus) pouvant contenir plusieurs milliers de caractères.

Ces grosses données seront accédées plusieurs fois pendant un processus de travail puis ensuite très rarement.

Dans un tel cas, en considérant que "plusieurs milliers de caractères", et pas systématiquement, ce n'est pas énorme, je serais tenté d'isoler ces colonnes dans d'autres tables.

Par exemple, une colonne de commentaire qui peut contenir de zéro à plusieurs milliers de caractères pourrait être isolée de cette manière...

Table_principale (id, [colonnes_importantes_souvent_interrogées])
Table_commentaire (id_table_principale, commentaire)

Ainsi, l'interrogation de la table principale ne sera pas pénalisée en temps par les commentaires, potentiellement vides ou très gros. On peut aussi, avec cette structure, afficher les données principales puis le commentaire seulement sur clic sur un bouton.

[escartefigue]

Pouvez vous préciser la nature du contenu de ces longvarchar pour s'assurer que nous ne fassions pas fausse route
Mais a priori, tout à fait d'accord avec Cinephil

[Titum]

Houla! excusez-moi, j'étais sur d'autres projets, j'ai laissé le temps filer

Le détachement vers une table centralisant ces colonnes est intéressant, en effet.

Il s'agit de séquences biologiques : des looongues chaines de lettres.

Je me pose la question par rapport à la taille des résultats de requêtes (mais là je peux choisir de ne pas inclure les colonnes) mais aussi de ressources utilisées par mysql.
En effet, j'ai cru comprendre que mysql garde les tables en mémoire vive pour les relire rapidement à la requête suivante. Or ça ferait conserver beaucoup de données inutiles en mémoire vive.

Si cela peut permettre de préciser les choses.

[CinePhil]

Justement, il vaut mieux qu'il conserve en mémoire les données les plus lues et n'aille chercher les données plus rares que s'il y en a besoin.
Si la loooongue chaîne de caractères est systématiquement retournée à l'utilisateur à chaque interrogation de la table censée la contenir, autant ne pas scinder la table. Si au contraire c'est rarement lu alors il vaut mieux scinder.

[Artemus24]

Salut Titum.

Je fais une base de données dont plusieurs tables auront une colonne (ou plus) pouvant contenir plusieurs milliers de caractères.

Si tu commençais par nous donner un exemple de ce que tu essayes de faire, cela pourrait nous aider à mieux comprendre ta problématique.

Sachant qu'à terme il y aura plusieurs milliers d'enregistrement dans ces tables, je me demande à partir de quelle taille il est recommandé de sortir quelques grosses données pour les conserver en fichier à côté de la base.

A priori, je suis du même avis que 'CINEPHIL'. Mais si dès le départ ta table contient une seule colonne, ce n'est en effet pas la solution de l'externaliser dans une autre table.

Ces grosses données seront accédées plusieurs fois pendant un processus de travail puis ensuite très rarement.

Mais c'est quoi la question que tu te poses ? Performance ou accessibilité ?

Par 'très rarement', qu'est-ce que tu entends comme fréquence ?
si c'est une fois par an, il faut mieux supprimer la table et la recréer quand tu en auras besoin.

Il s'agit de séquences biologiques : des looongues chaines de lettres.

Quel est le type que vous utilisez pour vos longues chaînes de lettre dans vos tables (text, longtext ...) ?
Quel jeu de caractères utilisez-vous ? Latin1 ? Utf8 ? Autre ?

Sachant que vous avez que quatre caractères : 'A', 'C', 'G' et 'T', ne serait-il pas plus judicieux de coder ces quatre lettres sur deux bits afin de gagner en volumétrie ?

Et quel genre de traitement faites-vous ?
Le 'full text search' permet de mieux optimiser une recherche mais sur des mots.
Là, vous n'avez aucun mot, juste une longue, voire interminable chaîne de lettre.

En effet, j'ai cru comprendre que mysql garde les tables en mémoire vive pour les relire rapidement à la requête suivante.

Pas les tables sauf si vous avez précisez 'engine=memory', mais juste le résultat des requêtes dans des buffers.
C'est secondaire comme problème. Au premier passage, la requête sera longue au traitement, mais au second passage, comme le résultat est stocké, mysql vous donnera son précédent résultat.

Or ça ferait conserver beaucoup de données inutiles en mémoire vive.

Ce n'est pas votre problème, mais celui de MySql pour gérer le résultat des requêtes précédentes.
Sinon, avez-vous assez de RAM sur votre serveur ?

@+

[Titum]

Merci pour vos réponses.

Il faut imaginer que j'ai plusieurs tables genre:

TABLE1 contient : id,colonne1,colonne2...,colonneSequence1
TABLE2 contient : id,colonne1,colonne2...,colonneSequence2

Les colonnes séquences sont utilisées à plusieurs reprises pour gérer une fabrication de produit durant quelques semaines, puis je pense qu'elle seront réutilisées 2-3 fois l'an max, j'imagine. Après c'est de l'archivage en gros.

Je ne fais aucune recherche dans le texte via la base, j'ai juste besoin de le charger et je le traite ensuite.

Il peut y avoir plus que 4 caractères mais seulement des lettres non accentuées, acsii suffirait. Mes tables sont en utf8.

La question est celle des performances (pour les requêtes majoritaires qui n'ont pas besoin de récupérer les séquences) et usage des ressources (mémoire vive).

[CinePhil]

Donc isolez les colonnes séquence dans des tables séparées ayant pour identifiant le même que celui de la table principale. C'est la première méthode que j'ai donnée plus haut. Inutile de charger ces séquences à chaque interrogation alors qu'elles seront rarement utilisées.
Faites des vues pour rassembler les données et interroger ces vues lorsque vous avez besoin des séquences.

Par contre...

TABLE1 contient : id,colonne1,colonne2...,colonneSequence1
TABLE2 contient : id,colonne1,colonne2...,colonneSequence2

Qu'est-ce qui justifie que ces deux tables aient la même structure ?
Je soupçonne une erreur de modélisation, pour le coup !

[Titum]

les exemples c'était vite fait pour la commodité, montrer qu'il y avait une séquence dans chaque table, mais les colonnes sont bien différentes

Il est clair maintenant que je vais externaliser ces données de leurs tables principales.

Merci pour vos avis !