Gérer des millions de lignes

Bonjour,

J'ai une table qui va atteindre le million de lignes.
On me demande aujourd'hui la possibilité de créer un nouveau lot de données.
Les anciennes données seraient archivées mais encore modifiables.
L'opération doit pouvoir être répétées à l'envie, en pratique tout les 6 mois.

Question : comment sortir de cette impasse ?
Quel modèle de données java, quelle représentation en base ?

Cordialement
merci

Citation:

---

Envoyé par coincoinfou

J'ai une table qui va atteindre le million de lignes.

---

Rien d'exceptionnel en soit

Citation:

---

Envoyé par coincoinfou

On me demande aujourd'hui la possibilité de créer un nouveau lot de données.

---

Tu veux dire, comme des données complètement séparées, dans leur propre table séparée des anciennes?

Citation:

---

Envoyé par coincoinfou

Les anciennes données seraient archivées mais encore modifiables.

---

C'est pas vraiment de l'archivage ça :)

Il suffit de créer une deuxième table avec la même structure, genre Tatable_archive


Pour archiver:

Code:

---

1 2	insert into Tatable_archive values select * from Tatable; delete * from Tatable

---

Au niveau du mapping objet, il faudra dupliquer la classe: une qui pointera sur archive, l'autre sur la table de base.

Petite précision : il faut garder toutes les données, je ne peux pas faire écraser les données de la table d'archive

Et bien, je n'ai rien supprimé dans les archives avec le code :aie:

Bonjour,
Je suppose que tes données ont une date de création? si oui tu pourras rajouter une clause de filtre lors de l'archivage :

Code:

---

1 2	insert into Tatable_archive values select * from Tatable where date_creation<uneDatePivot; delete * from Tatable

---

.
Mais je ne comprends pas vraiment l'intérêt de cet archivage tout de suite,est ce pour des soucis de temps d'exécution lors d'une recherche? car il existe pour cela des index, je ne sais pas quel SGBD tu utilises.Je ne partage pour l'idée de duppliquer une structure de table pour résoudre un pb de volumétrie :mouarf:.Mais ça reste mon avis perso.

J'ai vu ce genre de chose sur des applis de type comptable. Ca permet d'éjecter les données de l'années comptable précédente sans avoir de code très complexe pour ce qui gère l'année en cours. C'est un peux comme repartir d'une base de données neuve chaque années ;)

C'est plus facile comme ça de certifier que l'année comptable précédente ne peux plus être trafiquée que de devoir inspecter toutes les requetes SQL pour voir si elles ont un critère 'année en cours' ;)