Bon voila,  
je voudras faire un service de message privé dans mon site, mais je tombe sur le dileme suivant :
 
dois je avoir une base pour tous les messages privés du site
ou une base par personne seulement qui serait créé a son inscription ?
 
J'ai aucune idée des inconveniants (niveau vitesse, sécurité ...) de chacune de ces 2 solutions ... donc je fais appel a vous pour me decider !!!
 
merci d'avance pour vos reponses.

pas clair. c'est quoi ton site ?
 
et non, il ne faut pas faire une BASE, ni même une TABLE par utilsateur crée.
 
tu fait une table pour les messages privée avec l'ID du user

ok je ferais comme ca alors mais c'est quoi le defaut de faire une table par user ?
probleme de vitesse ?
probleme de securité lors d'une creation de table a l'inscription ?
probleme de rendement de place ?

mon site n'a aucune importance, ca serait un systeme de messagerie entre membre un peu comme les messages privé dans phpBB

et je me posais une autre question, peut on faire une table sans clé ?

la structure de ta base (tables) ne doit pas être modifiée en fonction du nombre d'utilisateur inscrit. c'est une règle de base dans les formes normales.
 
vitesse. pas de problème avec des index

non

non.

Au moins ca a le mérite d'être clair

ok merci pour vos reponses.

+1, je n'édite pas, même si je suis

une derniere question (désolé )
 
Quand est ce qu'on met une table dans une autre base ? lorsqu'il n'y a aucune depndance avec les tables d 'une base on en cré une autre ? ou toutes les table d'un site sont dans la meme base ?

il se peut qu'une table n'aie aucun lien avec les autres (par exemple les logs)
 
mais pourquoi la mettre dans une autre base ? ça n'apporte rien, si ce n'est du travail supplémentaire.

1 site/projet = 1 bdd

Si, on peut, et ça marche très bien.

USER
-----
LOGIN (PK)
PASSWORD
NOM
EMAIL (index unique / clé alternative)
 
 
MESSAGE
-----------
SENDER (FK vers USER.LOGIN)
RECIPIENT (FK vers USER_LOGIN)
MSGDATE (timestamp)
TITLE
BODY
 
 
-> Pour retrouver les messages d'une personne :
 
SELECT MESSAGE.MSGDATE, MESSAGE.TITLE, MESSAGE.BODY, USER.NOM
FROM USER, MESSAGE
WHERE MESSAGE.RECIPIENT = '$login'
AND USER.LOGIN = MESSAGE.SENDER
ORDER BY MSGDATE
 
=> Ca te retourne tous les messages reçu par "$login" triés par ordre chronologique.
 
Et il n'y a pas de clé primaire sur message, elle est rigoureusement unitile. Par contre, il faut un index sur RECEIPT, MSGDATE. Un second index sur SENDER, MSGDATE sera utile si tu veux afficher la liste des messages envoyés.
 
Et t'as besoin que de ces 2 tables pour gérer les messages entre autant de personnes que tu veux.
Si un message peut être adressé à plusieurs personnes à la fois (conversation à plusieurs) à ce moment tu devras faire une table de correspondance afin de remplacer le champ "RECIPIENT".

non!
 
Si tu arrives à le faire c'est que ton sgbd est pourri
De plus dans ton exemple les deux clés étrangères pointant vers une primary key, celles-ci sont considérées comme des primary keys...

 
T'as vu ça où ?
 
1) FK et PK n'ont rigoureusement AUCUN rapport.
2) Une PK n'est absolument pas obligatoire dans un SGBD, c'est au contraire les SGBD pourris qui obligent à utiliser une PK. Créer un ID "qui ne sert à rien" (qui ne participe à aucune jointure) ça n'est d'aucune utilité. A mieu, ce sera pour pouvoir localier une ligne pour la supprimer. Cependant, ça n'est en aucun cas obligatoire.
 
Comme expliqué dans le topic à propos de l'optimisation de bases de données, je travaille tous les jours sur des ERP qui n'utilisent pas une seule clé primaire (et il n'y a pas toujours d'index unique dans les tables, car dans certaines c'est absolument superflu).
 
Pourtant, le SGBD est Oracle, alors Oracle c'est tout ce que tu veux, pas certainement pas un SGBD pourri.

 
De ce que je connais des SGBD, c'est complètement dégueu de pas avoir une PK sur une table... Bonjour le respect des normes de modélisation, que ce soit via MERISE, UML ou CASE.
J'ai fait des études en développement et analyse de données, du coupo j'ai des potes plus jeunes que moi étudiant qui me demandent conseil de temps en temps, et je me bats presque avec eux pour ça, c'est vraiment crado une table sans PK... Comme les champs calculés inscrit en dur dans la base.

C'est peut-être dégueux, mais quand elle est inutile, c'est encore plus dégueux d'en mettre une.
 
La théorie, c'est bien, moi aussi j'en ai bouffé tout mon content du MERISE (niveau 5) durant mes études. Seulement, au sein même de MERISE, qui est un très bon exemple, si tu utilise le niveau 3 (celui qui est utilisé sur les outils avec lesquels je bosse) c'est pourtant du MERISE, mais une chiée d'infos calculées sont stockées dans la base, les clés ne sont pas des champs uniques, mais des tuples redondants d'une table à l'autre, tout ce qui est interdit avec MERISE niveau 5.
 
Alors UML, MERISE, CASE ou je sais pas quoi, ouais, certes "versions" de ces normes interdisent ces systèmes. Seulement, ces mêmes méthodes le permettent par ailleurs, alors c'est pas parceque les profs n'ont aucune notion de la réalité qu'il faut gober les normes qu'ils nous inculquent sans sourciller. Oui, c'est très bien de ce baser sur une norme très stricte, mais il faut savoir aussi dénormaliser quand le besoin se fait sentir.
 
Dans une gestion de message, est-ce que tu vas supprimer "ce message particulier". Nan, tu vas plutôt supprimer tous ceux qui viennent d'une personne, ou qui sont arrivés depuis plus de x jours. La PK est alors TOTALEMENT inutile.

Je suis d'accord, il faut savoir passer outre certaines règles pour optimiser les choses. Par exemple, on dit qu'il ne faut pas avoir deux fois le même champ dans une base, mais il peut être utile de faire appraître un champ pour éviter la mise en relation de deux tables via 15 jointures, ce qui optimise le traitement, au détriment du stockage. Mais bon de là à gicler les clés les clefs primaires...
Dans le pire des cas, et pour éviter d'jouter un champ exprès pour la clef primaire, tu définis en clé primaire un ensemble de champs. Mais laisser une table sans clé primaire, je suis désolé mais ça me choque (tout choqué je suis ).
 
Edit : en plus, il est possible que l'on veuille supprimer "ce message particulier". Exemple : j'envoi un message à quelqu'un, et je me rend compte qu'en fait c'est n'importe quoi ce que j'ai mis, et que je veux même pas lui parler finalement. Comment j'annule mon message en espérant qu'il ne l'a pas encore lu ?

Ben disons que pour moi, un message board, c'est apparenté à une table de log. Hors des logs y'a pas de clé (bah ouais, imagine que tu fais un log chaque fois qu'il y a une erreur sur la base de données... et que ta requête qui insère le log provoque une violation de clé... bah tu fait tomber ton serveur comme un con )

Suffit de pas coder comme un porco, c'est tout. Charrie pas non plus, faire un insert dans un table log, faut vraiment s'y prendre comme un pied pour qu'il génère une erreur...

Même, une table de log n'a jamais de clé primaire.
 
Ceci-dit, pour info, pour localiser une ligne dans une table, c'est pas compliqué, car il y a systématiquement une clé internet, appelée ROWID (sous Oracle). Donc de toute façon, si la PK est inutile et apporte rien, cette clé peut très bien servir pour localiser une ligne particulière dans la table en l'absence de PK.

 
Et si ton SGBD est âs Oracle ? Parce que vu le prix des licences, moi je préfère bosser sous MySQL quand même... Et puis ça n'en reste pas moins dégueu finalement.

Tous les SGBD utilisent ce système.

euh si quand même un FK est forcément la PK d'une autre table

Moi je parle de la table qui contient la PK...
 
Avant de répondre à côté de la place à une de mes réponses, faudrait peut-être penser à lire ce à quoi je réponds, ça peut servir.

perdu. la FK est forcément une clef unique d'une autre table. rien de plus.

Tous les SGDB n'ont pas cette clef interne, et certains permettent ou non d'en mettre une pour chaque table.

Je veux bien te croire, mais tu m'étonnes. Parcequ'en interne, le SGBD doit forcément avoir une table d'adresses afin de retrouver les enregistrement, et cette table d'adresses joue forcément le même rôle que ROWID... Enfin c'est comme ça que je conçois la chose, je vois pas comment le SGBD peut bosser autrement.

bof, ca dépend comment est implémenté la structure en interne. S'ils se basent sur un format de liste, ils n'ont pas besoin d'une table d'adressage. C'est pas performant, mais ca fontionne. La lecture séquentielle aussi

Dans tous les cas on peut la calculer l'adresse
Si tu sais d'où tu part, la taille d'une ligne, et à quelle ligne tu vas, une simple multiplication te donne l'adresse de la ligne recherchée

la calculer, oui, la stocker, pas spécialement.

 
et la dénormalisation tu connais ?
 
quant aux données calculées, reviens quand tu auras bossé sur une grosse appli, on en reparlera

l'absence de PK et les données calculées, c'est même dans la norme MERISE niveau 3.
 
la preuve, l'ERP sur lequel je bosse est certifié MERISE niveau 3 (et ISO 9002) alors qu'il y a pas mal de redondances et de données calculées stockées, sans parler de l'absence de PK et FK (uniquement ds index uniques et des contraintes vérifier de façon logicielle)

 
T'es obligé de prendre cet air hautin de merde pour répondre aux gens où c'est juste une attitude de défense ?

 
je réponds sur le ton qu'on prend quand on avance des betises

 
je n'ai jamais dit le contraire
 
simplement je hais quand des gens annoncent des grandes "vérités" (qui ne le sont que pour eux), tout en ayant un manque flagrant d'expérience pratique derrière

 
OK ben reste seul avec ta science infuse et ta prétention, moi je me casse de ce topic où il me semblait pouvoir discuter calmement en échengeant des points de vue avant ton arrivée.