La seule technique c'est de regrouper les données qui se rapportent à une même entité (un membre, un groupe de membre, etc…), ce qui est normalisé avec la méthode MERISE.

[quote]Evidemment que tu mets tous tes membres dans une tables, tu comptais pas quand même en mettre 300 000 dans une et 300 000 dans l'autre ? [/quote]

Non justement :), le nombre d'entré etant important, je voulais savoir si il y avait des techniques que je ne connaissait pas afin que sa marche correctement, car vous l'aurait remarqué, je suis loin d'étre spécialiste en la matiére.

Je continue de lire le document, c'est trés interessant mais tout de meme un peu complexe, et j'aurais voulu savoir si vous connaissez d'autre exemple de shématisation de bdd avec son équivalent une fois terminé (table, champs...)

Merci de votre aide et depatience ;)

[quote="katagoto"]Je parlait de regrouper les petites tables, si on a 5-6 tables à 2-3 champs, s'il y a un point commun, faut les regrouper...[/quote]
:shock:
On crée une table pour enregistrer un type de données, point à la ligne.
Il est possible qu'un type de données se décline en sous-type, mais on ne mélange pas des pommes et des tables :?

Sinon, même avis que mes collègues, le nombre de tables/champs ne doit pas entrer en compte dans la conception d'une BDD.
On imagine les données à stocker, on modélise les tables pour les stocker ...

Pour moi, ce qu'il est important de surveiller, c'est de respecter les normes merise ... mais ça a déjà été dit également.

[quote="rif5"]
Autrement pour un site réunissant 600 000 membres, tous les membres sont regroupé dans la meme table ('membre' par exemple), ou il faut utilisé plusieurs table (ou autre solution), auquel cas je ne sait pas du tout comment faire...[/quote]
Evidemment que tu mets tous tes membres dans une tables, tu comptais pas quand même en mettre 300 000 dans une et 300 000 dans l'autre ? :shock:

Merci pour vos réponses, sa correspond trés bien a ce que je chercher, je commence a étudier le document, et ma premiére impression, est que sa ne semble pas spécialement simple lol, je pense que je vais le lire et l'étudier plusieur fois.

Autrement pour un site réunissant 600 000 membres, tous les membres sont regroupé dans la meme table ('membre' par exemple), ou il faut utilisé plusieurs table (ou autre solution), auquel cas je ne sait pas du tout comment faire...
Désolé pour les questions peut etre évidente :s, mon projet me semble de plus en plus complexe a mettre en oeuvre :) , je retourne lire et reviendrait surement avec encore des questions lol

[i][color=darkred][Note : ce message a été posté de manière anonyme avant d'être réattribué à son auteur][/color][/i]

[quote="katagoto"]
Bah en générale, à partir de 60 tables faut commencer à s'inquiéter s'il n'y a pas trop de modules...
[/quote]
J'aimerais savoir d'où tu sors ton chiffre…
Il n'y a pas de règle simple de cette sorte. Il y a des architectures de petites applications très axées sur les données qui demandent plusieurs bases à une quarantaine de tables, comme des gros sites plus éditoriaux qui nécessitent seulement une base de vingt tables.

Bref, moi aussi je pourrais sortir un chiffre, genre il t'en faut 23, c'est un nombre sympa, mais ce n'est pas cela qui va faire avancer le débat…

[quote="ouckileou"][quote="katagoto"]
il faut veillé à ce qu'il y a un nombre pas trop grand de table,
[/quote]
Pourquoi ? Tant que la modélisation est bien faite, peu importe. (D'ailleurs à partir de quel nombre de tables situes-tu le "trop grand" ?)

[quote="katagoto"]
peut-être regrouper les tables à deux champs fonctionnels[/quote]
:?:[/quote]

Bah en générale, à partir de 60 tables faut commencer à s'inquiéter s'il n'y a pas trop de modules...

immaginons un cas simple : un forum, un espace membre et des articles, faut pas avoir plus de 35 tables...

Je parlait de regrouper les petites tables, si on a 5-6 tables à 2-3 champs, s'il y a un point commun, faut les regrouper...

Oui, éviter la redondance, tout à fait...

[quote="animithra"]
pour te faire une meilleure idée, tu peux essayer de regarder du côté de la modélisation UML/Merise :

[url]http://cyril-gruau.developpez.com/uml/tutoriel/ConceptionBD/[/url]
[/quote]
Euh, soit dit en passant, c'est exactement ce que j'ai posté…

EDIT : leaule :)

je crois qu'il voulait dire qu'il faut éviter les redondances...

ce qui compte c'est de respecter une ou deux règles :

- une table ne doit pas comporter de doublons (sinon il y a une erreur logique)
- une table ne doit pas comporter plusieurs colonnes semblables
(par exemple sur une table pour un site commercial, tu ne peux pas avoir une table panier avec :
nomarticle1, coutarticle1, prixarticle1 puis nomarticle2, coutarticle2...., d'ailleurs ça te contraindrait à un certain nombre d'articles).

l'idéal est d'avoir un crayon est un papier, d'écrire explicitement ce que tu veux enregistrer dans la base et de regrouper selon 1 élément unique.

pour te faire une meilleure idée, tu peux essayer de regarder du côté de la modélisation UML/Merise :

[url]http://cyril-gruau.developpez.com/uml/tutoriel/ConceptionBD/[/url]

bon courage :)

[EDIT] on sent les habitués => Sékiltoyai 3 minutes de moins pour chercher le bon tuto :agenouille:

Avec ca t'as de quoi faire :
ftp://ftp-developpez.com/cyril-gruau/ConceptionBD.pdf

[quote="katagoto"]
il faut veillé à ce qu'il y a un nombre pas trop grand de table,
[/quote]
Pourquoi ? Tant que la modélisation est bien faite, peu importe. (D'ailleurs à partir de quel nombre de tables situes-tu le "trop grand" ?)

[quote="katagoto"]
peut-être regrouper les tables à deux champs fonctionnels[/quote]
:?:

En fait, il faut séparer les informations logiques par table exemple :
le profile du membre : pseudo, nom, nombre de post etc, ils seronts tous afficher dans la page profile
les pramètres du membre, hop, nouvelle table, etc...
il faut veillé à ce qu'il y a un nombre pas trop grand de table, peut-être regrouper les tables à deux champs fonctionnels, ça sort du cadre mais, si tu conçoit bien ta base de données, tu aqura toujours le problème de la charge, m'arcevant que je dérive, je termine mon message ^^

Bonjour,
Je suis actuellement entrain de concevoir un site, et j'en viens (meme si je ne suis pas encore tout a fait rendu la) a me poser des questions sur la base de donnée.
Mon projet nécessitera de stocker pas mal de donnée, et devrait recevoir pas mal de requete, en imaginant que mon projet sera une réussite (ce que j'espére) et en me referrant au stats des sites identifiés comme concurrent, je constate qu'ils ont une communauté de 600 000 membres inscrit avec toutes les info que cela comporte, je voudrait que ma base soit créer pour pouvoir gerer cela.

Chaque membre aura différente option qu'il activera ou pas, et aura accés par exemple a un nombre défini de photos gratuite par jour (avec enregistrement des photos vu, pour un historique que le membre pourra consulter).

Je voulais donc vous demandez les méthodes idéals de devellopements de base de données qui puisse correspondre a l'exemple cité, en tout qu'a me communiqué les bonnes démarche a effectué, ainsi que toutes les bonnes questions a ne pas oublié de ce posé (j'avait un site avec une base de donnée de environ 40000 membres, mais pas optimisé du tout, j'avais une table membre avec le nom, pseudo..... toutes les infos du membre, ainsi que toutes les options, et a chaque fois que je rajouté une option, je rajoutais un champ, sa fonctionné, mais lorsque j'ai voulu changé de serveur et qu'il a fallut transféré la bdd j'ai eu des difficultés, et je pense qu'il y avait moyen de faire bcp mieux).
Je prend également tout les liens vers des tutoriaux/livres :)

Merci de vos réponses :)

[i][color=darkred][Note : ce message a été posté de manière anonyme avant d'être réattribué à son auteur][/color][/i]