BDD amenée à devenir très lourde

Cpt Anderson · 15/01/2008, 11h09

Bonjour,

je recherche un peu partout quelles seraient les meilleurs solutions pour mon problème: j'ai une base de données, je sais que les utilisateurs vont ajouter environ 1 million d'enregistrements par an dans plusieurs tables. Toutefois, il faut que je fasse en sorte que si les utilisateurs fasse une recherche sur ces enregistrements, cela ne rame pas trop. Quelles solutions ai je ? historiser mes enregistrements ? charger mes enregistrements en mémoire ? Comment font les grosses sociétés ?

J'utilise Oracle et Delphi 7.

Merci

gregory.broissard · 15/01/2008, 13h23

Partitionner tes tables
Historiser et archiver effectivement

SQLpro · 15/01/2008, 22h51

1 millions de ligne par an avec une bonne indexation c'est peu si la base est bien indexée.

Un nom de personne comporte en moyenne 8 caractères. Indexé cette colonne nécessite la lecture de 2 pages de 8ko pour accéder à un quelconque des noms parmi 160 000 noms.
Pour 64 000 000 de noms, 3 pages de 8 Ko suffisent.
Pour
Pour 25,6 milliards de nom, il vous faut 4 pages...

Pensez vous que la lecture de 4 pages de 8 Ko soit un effort incommensurable pour un SGBDR ?

La condition sinéquanone de la légèreté de requêtage dans un tel volume est :

un bon modèle de données (donc fortement normalisé)
une indexation adéquates.

Sans cela la base peut effctivement être un veau !

Lisez l'article exemple que j'ai écrit à ce sujet :
http://www.sqlspot.com/INDEXATION-un...l-exemple.html

A +

15/01/2008, 11h09	#1
Cpt Anderson Membre actif Développeur informatique Inscription : novembre 2005 Messages : 210 Détails du profil Informations personnelles : Âge : 37 Localisation : France, Rhône (Rhône Alpes) Informations professionnelles : Activité : Développeur informatique Informations forums : Inscription : novembre 2005 Messages : 210 Points : 153 Points : 153	BDD amenée à devenir très lourde Bonjour, je recherche un peu partout quelles seraient les meilleurs solutions pour mon problème: j'ai une base de données, je sais que les utilisateurs vont ajouter environ 1 million d'enregistrements par an dans plusieurs tables. Toutefois, il faut que je fasse en sorte que si les utilisateurs fasse une recherche sur ces enregistrements, cela ne rame pas trop. Quelles solutions ai je ? historiser mes enregistrements ? charger mes enregistrements en mémoire ? Comment font les grosses sociétés ? J'utilise Oracle et Delphi 7. Merci __________________ Voici la méthode de mon chef: copy (DateTimeToStr(Now),7,4)+ copy (DateTimeToStr(Now),4,2)+copy (DateTimeToStr(Now),1,2)+copy (DateTimeToStr(Now),12,2)+ copy (DateTimeToStr(Now),15,2)+copy (DateTimeToStr(Now),18,2) Je lui ai dit que FormatDateTime irait surement mieux
	00

15/01/2008, 22h51	#3
SQLpro Rédacteur/Modérateur Frédéric BROUARD Expert SGBDR & SQL Inscription : mai 2002 Messages : 10 959 Détails du profil Informations personnelles : Nom : Frédéric BROUARD Localisation : France Informations professionnelles : Activité : Expert SGBDR & SQL Secteur : Conseil Informations forums : Inscription : mai 2002 Messages : 10 959 Points : 17 793 Points : 17 793	1 millions de ligne par an avec une bonne indexation c'est peu si la base est bien indexée. Un nom de personne comporte en moyenne 8 caractères. Indexé cette colonne nécessite la lecture de 2 pages de 8ko pour accéder à un quelconque des noms parmi 160 000 noms. Pour 64 000 000 de noms, 3 pages de 8 Ko suffisent. Pour Pour 25,6 milliards de nom, il vous faut 4 pages... Pensez vous que la lecture de 4 pages de 8 Ko soit un effort incommensurable pour un SGBDR ? La condition sinéquanone de la légèreté de requêtage dans un tel volume est : un bon modèle de données (donc fortement normalisé) une indexation adéquates. Sans cela la base peut effctivement être un veau ! Lisez l'article exemple que j'ai écrit à ce sujet : http://www.sqlspot.com/INDEXATION-un...l-exemple.html A + __________________ Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL Site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/ *Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.* Blog SQL, SQL Server, modélisation données : http://blog.developpez.com/sqlpro http://www.sqlspot.com : modélisation, conseils, audit, optimisation, formation * * * * * Enseignant CNAM PACA - ISEN Toulon - CESI Aix en Provence * * * * *
	00

15/01/2008, 13h23	#2
gregory.broissard Membre expérimenté Inscription : mai 2005 Messages : 414 Détails du profil Informations forums : Inscription : mai 2005 Messages : 414 Points : 589 Points : 589	Partitionner tes tables Historiser et archiver effectivement
	00

Outils de la discussion
Afficher une version imprimable Envoyer un lien vers cette page par email