Bonjour
 
Dans le cadre d'un projet, je dois modeliser une base de données qui doit abriter tous les abonnés d'un opérateur donc vous pouvez voir la taille. Est ce qu'il ya une méthode pour pouvoir optimiser cette base de données de facon à optimiser la  gestion de la memoire pour pouvoir après mettre le moins de temps possible pour faire des mises à jour ou des select ....
 
Merci d'avance

En gros ta question est comment faire une base de données?    
 
Je sais pas, au hasard:
 
Construire proprement les tables afin d'eviter la redondance d'informations
Mettre en place les bons indexes
Eviter le plus possible le varchar dans les tables
 
Pour le volume, je ne vois pas ce que ca represente. On ne sait pas de quel operateur il s'agit, ni des infos qu'il veux stocker. Est-ce une base destinée à la relation client? Est-ce une base de compta?, Bref, je ne peux que te conseiller d'en dire plus. Et de lire tout plein d'articles sur le net sur la mise en place d'une BDD.
 
Je suis aussi curieux de connaitre le volume que ca represente. Ainsi que le moteur utilisé
 
Sinon, optimisation de la taille ne rime pas avec rapidité d'execution. Par moment, il faut savoir dupliquer des infos pour gagner en temps.

Merci pour ta réponse
Voilà, je dois utiliser une base de données Oracle9i, c une base que je dois utiliser pour les statistiques d'abonnées d'un opérateur telecom ( 7 millions d'abonnes ).
 
Merci encore  
 

Les index sont très importants si tu gères des tables avec énormément d'enregistrement !!!  
Cela te permettra d'accélérer tes requêtes, et il faut bien prévoir à l'avance quelles requêtes tu vas faire pour mettre en place les bons indexes !  

Salut,
 
Je ne sais pas si c'est aussi valable pour Oracle, mais je sais que pour SQL Server tu as tout intérêt à mettre tes DB systèmes sur un autre disque que tes DBs. Ca va plus vite.
 
Tu as aussi tout intérêt à avoir deux partitions sur ton serveur: une pour l'OS et une pour les données... (mais bon ça c'est logique). Idéalement ce serait mieux d'avoir même ça sur des disques, voir des contrôleurs différents.
 
Je sais aussi que pour optimiser la vitesse d'accès, t'as intérêt à utiliser du RAID 5 (de mémoire, à vérifier).
 
Bref, voilà aussi des moyens d'optimiser ta DB par des "opérations" de plus bas niveau. Je ne sais pas si cela te sera utile...
 
A+

Oui mais là ce n'est plus de l'optimisation SQL, mais systeme.
 
Avant de commencer à preparer un modele, il faut aussi se demander quelles seront les interrogations futures sur la base. Ca influe sur la façon d'organiser les données.  
 
7 millions d'abonnés, ca doit etre plus que gerable. Bien organisé, il n'y aura pas de soucis.

Pas forcément : il est parfois judicieux de partiellement dénormaliser et d'introduire un peu de redondance pour des questions de perfs (ça me chagrine toujours, mais bon).

 
Il faut tout lire avant de repondre

Laisse béton l'optimisation... Oracle 9i avec 7M enregistrement ?
 
Tu le fous tranquillement sur un HP Unix, et roule ma poule, avec 3 pauvres index, ce sera plus rapide qu'un MySQL sous Windows avec 3K enregistrements.
 
Par contre, évite de faire un "select count(*)" sur une telle table, Oracle n'aime pas du tout (testé et approuvé, ça a mis 35 minutes à retourner le résultat dans une table contenant 25 000 000 lignes

D'autant plus que la clé primaire est de taille parfaitement fixe (numéro de tel), donc stockable dans un CHAR(10) (ou 12 si tu mets le format internationnal)

euh c'est quoi ton char(10) ou 12? le N° de tel? J'espere que ce n'est pas l'identifiant de l'abonné!!!

Bah... Mouais, t'as raison
 
M'enfin c'est pareil, le numéro d'abonné, ça a toujours une taille connue (format fixe) donc ça tiens toujours dans un char(x) , ce qui est selon moi, infiniment mieu qu'un ID numeric autoincrément qui ne sert à rien.