Vous n'êtes pas identifié(e).
Pages : 1
Bonjour,
En ce moment je crée une base de données avec une table listant les comptes clients. Dans chaque compte j'ai 3 champs avec un gros texte de 60 ko chacun (26 000 caractères environ) , sur lesquels j'applique souvent des regex pour retrouver des phrases.
A votre avis, pensez-vous que cela va trop ralentir le système, ou bien c'est jouable avec par exemple 1 000 000 de comptes ?
Merci !
Hors ligne
Les regexp ne pouvant pas utiliser d'index, oui, ça va forcément ne pas être performant.
Guillaume.
Hors ligne
Le problème, c'est qu'il me faudrait une table imbriquée dans le champs d'une table, pour pouvoir gérer une liste propre à chaque client (chaque client possède une liste), mais on ne peut pas faire de table imbriquée.
Une solution serait de créer un tableau dans un champs, mais postgresql ne gère pas les array associatifs multidimensionnels.
Il reste l'ancienne solution : tout mettre dans une seule table, avec une clé qui serait l'ID du client pour chaque ligne de sa liste. Le problème c'est qu'à chaque fois qu'il rajoute une ligne à sa liste, il faut re-trier la table et recalculer les index pour placer l’occurrence au bon endroit dans la table, pour que ça donne à peu près ça :
ID|détails
26|aaaa
26|zzzz
26|cccc
26|rrrr
42|yyyy
42|cccc
99|zzzz
99|mmmm
...
Ça doit être assez lourd de tout re-trier à chaque fois, donc j'ai pensé mettre la liste de chaque client dans son occurrence dans la table compte, dans un champs, sous forme de XML :
<1>blabla</1><2>blibli</2><3>bloblo</3>
Donc en ce moment je cherche la technique qui soit la plus performante...
Dernière modification par debutant_24 (27/06/2011 16:48:24)
Hors ligne
Si vous voulez des performances, quelque soit le moteur de bases de données, oubliez les tableaux associatifs multidimensionnels en base. Ça ne peut pas marcher.
Vous pouvez par contre créer une table avec au moins trois colonnes : l'id du client, le nom de la propriété et la valeur de la propriété pour ce client. En espérant que j'ai bien compris ce que vous cherchez à faire.
Guillaume.
Hors ligne
Oui c'est sur quoi j'étais parti au départ, mais le problème c'est que les lignes de tous les clients sont mélangées entre elles, donc il faut à chaque fois les trier.
En fait j'aimerai bien savoir comment le SGBD s'y prend à ce niveau, est-ce qu'il ajoute systématiquement les nouvelles occurrences à la fin du fichier de la table, puis il remet seulement à jour l'index, ou bien est-ce qu'il réécrit la ligne au bon endroit ? Et s'il écrit la ligne au bon endroit, j'imagine qu'il est obligé de recopier toutes les lignes en dessous pour les décaler sinon il risque d'écraser les lignes suivantes.
Sinon j'ai pensé aussi à faire une table par client, mais je sais pas combien de tables au maximum peut gérer postgresql, et s'il est pas plus difficile de retrouver les tables après, quand il y en a 1 000 000.
Hors ligne
Il place les lignes là où il a de la place, donc généralement à la fin du fichier. En soi, ça n'est pas un problème. Avec de bons index, ça devrait bien fonctionner. En tout cas, bien mieux que le gros champ de données sérialisées.
Guillaume.
Hors ligne
Et si vous nous expliquiez vraiment ce que vous voulez faire? Je n'ai toujours pas compris quel était le but de l'énorme texte dont vous parliez au début : pourquoi ne pouvez-vous pas faire des tables en forme normale? Pourquoi chaque compte client a-t-il des informations de structure différente? Chaque client possède une liste, d'accord, mais une liste de QUOI?
Il y a peut-être une solution simple à votre problème, pour peu que vous l'exprimiez complètement.
Dernière modification par flo (27/06/2011 18:27:22)
Hors ligne
J'essaie de simplifier pour présenter mon problème, mais chaque client a une liste d'autres clients, une liste de contacts. C'est pour faire un réseau social.
L'énorme texte est situé dans un champs du compte client, c'est la liste de contacts du client, avec une mise en forme XML. Pourquoi ? Pour avoir tout dans la même ligne, pour éviter que les éléments de la liste de chaque client soient éparpillés dans une même table. A chaque ajout d'un contact sur la liste d'un client, il faudrait tout recalculer les index si la liste était présentée sous forme d'occurrences dans une autre table, alors que dans mon champs text avec la liste en XML dans la table compte, je n'ai qu'à rajouter des balises à la fin de la liste pour ajouter un nouveau contact.
Voilà donc, il y a sans doute plusieurs solutions, mais difficile de trouver la plus optimale. Imaginez que sur 1 000 000 de clients, chacun dispose d'une liste de 50 contacts, cela ferait 50 000 000 de lignes dans la même table, c'est beaucoup ! Alors qu'avec la liste en XML dans un champs du compte du client, il y a toujours 1 000 000 de lignes. Mais bon, la présentation sous forme de balises XML demande sans arrêt des regexp sur champs text pour récupérer les informations sur un contact de la liste.
J'espère que je me suis pas trop mal expliqué 
Dernière modification par debutant_24 (27/06/2011 18:59:48)
Hors ligne
50 millions de lignes dans une table, c'est une somme, mais c'est pas énorme non plus.
De toute façon, dans une base de données relationnelles, le plus important n'est pas le nombre de lignes mais la façon dont la base est structurée. PostgreSQL sera bien plus rapide avec la table que je proposais, même si elle fait 50 millions de lignes qu'avec la table que vous proposez. Autant dans mon cas, les index pourront facilement être utilisés, autant dans la votre, il y a de fortes chances que non.
Guillaume.
Hors ligne
A mon avis, votre solution (tout mettre sur la même ligne) est idéale... dans un fichier texte. Dans une base de données relationnelles, certainement pas... En fait, je suis tout à fait d'accord avec gleu.
Vous faites aussi une erreur en supposant que les données sont triées dans la table. Ce n'est pas comme cela que ça fonctionne dans une base de données. Les index sont disposés en général suivant un arbre balancé. Les données... euh je ne suis pas assez calée pour expliquer comment c'est dans PostgreSQL, mais ce qu'il faut retenir, c'est qu'on s'en moque éperdument (en tant que développeur, je veux dire, moi ce qui m'intéresse c'est que cela fonctionne 
). Donc ajouter des données n'est pas un problème, ce n'est pas comme dans un beau fichier trié (où là c'est vite le bazar).
Donc (tant pis si je me répète), écoutez gleu, il a raison Cela ne veut pas dire que vous n'aurez pas de souci, mais c'est sans doute la meilleure solution. Et puis 50 millions de lignes, de nos jours, c'est presque courant...
Hors ligne
D'accord, mais je me suis dit qu'à l'affichage, il était plus simple pour le SGBD de faire une simple requête en SELECT sur le champs, pour ressortir toute la liste d'un coup, comme un bloc de texte, plutôt que d'utiliser les index pour rechercher chaque ligne une à une. Par contre dès qu'il faut ajouter, supprimer ou modifier un contact dans la liste, là c'est effectivement plus lourd à gérer à cause des regex.
Le fait est est qu'il y aura toujours plus d'affichage de liste que de modifications sur celle-ci, donc je voulais ménager l'affichage...
Hors ligne
Sauf que vous dites : "sur lesquels j'applique souvent des regex pour retrouver des phrases."
Et la clairement ça va être mauvais... enfin si c'est bien sur l'ensemble de la table que vous cherchez. Parce que là encore ce n'est pas clair dans votre explication. Si vous êtes certains de toujours rechercher sur la clé primaire, c'est différent. Mais dans ce cas, je ne comprends pas votre question initiale. Votre dernier post et le premier me semblent absolument contradictoires (d'où j'en déduis qu'il y en a 1 que je n'ai pas compris, mais lequel?)
Dernière modification par flo (28/06/2011 08:21:06)
Hors ligne
Non, pas sur toute la table, voilà la structure :
Table COMPTE :
id | nom | prenom | ... | liste
Le champs LISTE est en type TEXT, ça donne à peu près cela :
<id58><1>nom</1><2>prenom</2></id58>
<id256><1>nom</1><2>prenom</2></id256>
<id9542><1>nom</1><2>prenom</2></id95428>
<id19><1>nom</1><2>prenom</2></id19>
...
le numéro dans la balise globale est celui de l'ID du contact du client (contact qui est aussi un client).
Par conséquent, quand j'applique une regex pour supprimer un contact de la liste du client par exemple, je sais exactement dans quel compte client il faut appliquer la regex, par exemple le compte client ayant pour ID = 654, puis, dans son champs liste je cherche avec la regex la balise globale contenant l'ID de son contact. La liste peut faire jusqu'à 60 ko soit environ 300 contacts listés en XML.
Les regexp sont donc appliquées sur un champs d'une ligne précise, déterminée par un ID précis : celui du compte client. Par contre au sein du champs LISTE de ce compte c'est un bloc de texte en XML donc la regex peut parcourir tout le texte de 60 ko (environ 300 lignes XML).
Dernière modification par debutant_24 (28/06/2011 20:06:24)
Hors ligne
Pages : 1
