Dilemme sur la gestion des tables

Bonjour !

Développer un logiciel, c'est aussi faire des choix de conception.
Avec mon manque d'expérience, je me permet de vous demander votre avis avant de me lancer dans une mauvaise direction...

Voilà :
Mon application gère une base de données avec de nombreuses tables et un grand nombre d'enregistrement. (environ 100 000)

Sur une version précédente de mon application, (en langage Pascal, mono utilisateur sur un ordi), j'avais découpé ces enregistrements en fichiers distincts (un fichier par jour, soit environ 200 enregistrements par fichiers) pour accélérer les fonctions de recherche et éviter d'avoir des fichiers trops lourds à manipuler.
En Pascal, et sans utiliser une base de donnée SQL, créer un nouveau fichier chaque jour sur son disque dur ne pose pas de problème, c'est rustique, mais facile et efficace.

Avec JAVA et JPA, de nouveaux problèmes se posent :

1) Est-il possible de créer "à la volée" c'est à dire de manière dynamique par le logiciel une nouvelle table ? (pour segmenter les enregistrements, mon application devra pouvoir créer une nouvelle table chaque jour...
Comment faire ?

2) Si je crée une seule table pour tous les enregistrements, comment va se comporter le système lorsque je vais commencer, au bout de plusieurs mois, à approcher les 50 000 fiches-clients, puis les 100 000 ? (lenteur sur les opérations CRUD, etc...)

pour info, chaque fiche client fait un peu moins de 1Ko...

Je n'ai pas trop idée de la puissance actuelle des ordis pour ce genre d'opération, en encore moins sur un web serveur qui tourne avec Glassfish !

Merci de votre avis !!!

Jean-Michel

Citation:

---

1) Est-il possible de créer "à la volée" c'est à dire de manière dynamique par le logiciel une nouvelle table ? (pour segmenter les enregistrements, mon application devra pouvoir créer une nouvelle table chaque jour...
Comment faire ?

---

Oui, il te suffit de lancer la requête SQL idoine ("CREATE TABLE...") une recherche google pour avoir la bonne syntaxe et c'est bon. Il faut juste que l'utilisateur avec lequel tu te connectes à ta base ait les droits pour créer des tables. Par contre, c'est une TRES mauvaise pratique

Citation:

---

2) Si je crée une seule table pour tous les enregistrements, comment va se comporter le système lorsque je vais commencer, au bout de plusieurs mois, à approcher les 50 000 fiches-clients, puis les 100 000 ? (lenteur sur les opérations CRUD, etc...)

---

Pour accélérer les recherches, tu peux indexer des colonnes de ta table. Ainsi, le temps de recherche augmentera de façon logarithmique en fonction du nombre d'éléments contenus dans la table.
Au niveau des index, l'important est de savoir que ça accélère grandement les lectures mais ça ralentit les écritures (puisqu'il faut maintenir ces index). Si tu te retrouves à définir plus de 3 index sur une table, c'est que tu dois avoir des problèmes de design.

Il faut voir aussi à quel moment tu écris dans ta base. Si c'est un batch de nuit, on se fout que ça mette du temps à écrire dans la base...

Ok, merci des infos !
:ccool:
Je pense utiliser une solution intermédiaire, à savoir création de 12 tables (une par mois) ce qui va répartir les données dans des fichiers à taille "humaines" tout en évitant la création de tables dynamiques

Merci !

Jean-Michel

Sauf... Si quelqu'un a une autre idée ;)

J'ai effectivement une autre idée 8-)

Tu dois te renseigner sur les partitions.
Je n'en ai personnellement jamais utilisé mais c'est particulièrement adapté à ton cas d'utilisation : découper une table en plusieurs parties de même volumétrie. ça évite de faire plusieurs tables ayant la même structure et ça simplifie donc la structure de ta base.

Je pense qu'il te faut:
- une table partitionée par mois ou par semaine.
- un index sur les colonnes utilisées comme critère de recherche.