[SQL] dileme (besoin d'un conseil)

dileme (besoin d'un conseil) [SQL] - SQL/NoSQL - Programmation

Marsh Posté le 30-06-2004 à 17:59:57    

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.

Reply

Marsh Posté le 30-06-2004 à 17:59:57   

Reply

Marsh Posté le 30-06-2004 à 19:40:59    

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


---------------
What if I were smiling and running into your arms? Would you see then what I see now?  
Reply

Marsh Posté le 30-06-2004 à 19:43:56    

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 ?

Reply

Marsh Posté le 30-06-2004 à 19:44:32    

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

Reply

Marsh Posté le 30-06-2004 à 19:45:50    

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

Reply

Marsh Posté le 30-06-2004 à 19:46:56    

patastronch a écrit :

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 ?


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


---------------
What if I were smiling and running into your arms? Would you see then what I see now?  
Reply

Marsh Posté le 30-06-2004 à 19:47:04    

patastronch a écrit :

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

non

Reply

Marsh Posté le 30-06-2004 à 19:47:12    

patastronch a écrit :

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


non.


---------------
What if I were smiling and running into your arms? Would you see then what I see now?  
Reply

Marsh Posté le 30-06-2004 à 19:47:49    

Au moins ca a le mérite d'être clair [:ddr555]

Reply

Marsh Posté le 30-06-2004 à 19:49:17    

ok merci pour vos reponses.

Reply

Marsh Posté le 30-06-2004 à 19:49:17   

Reply

Marsh Posté le 30-06-2004 à 19:49:20    

harrysauce a écrit :

Au moins ca a le mérite d'être clair [:ddr555]


+1, je n'édite pas, même si je suis [:benou_grilled]


---------------
What if I were smiling and running into your arms? Would you see then what I see now?  
Reply

Marsh Posté le 30-06-2004 à 19:57:27    

une derniere question (désolé :D )
 
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 ?

Reply

Marsh Posté le 30-06-2004 à 20:02:37    

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.


---------------
What if I were smiling and running into your arms? Would you see then what I see now?  
Reply

Marsh Posté le 30-06-2004 à 20:02:57    

1 site/projet = 1 bdd


---------------
What if I were smiling and running into your arms? Would you see then what I see now?  
Reply

Marsh Posté le 30-06-2004 à 21:06:47    


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

Reply

Marsh Posté le 30-06-2004 à 21:13:43    

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".


Message édité par Arjuna le 30-06-2004 à 21:14:14
Reply

Marsh Posté le 01-07-2004 à 02:55:23    

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...


Message édité par harrysauce le 01-07-2004 à 02:55:45
Reply

Marsh Posté le 01-07-2004 à 09:11:40    

:heink:
 
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.

Reply

Marsh Posté le 01-07-2004 à 10:38:48    

Arjuna a écrit :

:heink:
 
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.

Reply

Marsh Posté le 01-07-2004 à 10:46:52    

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.

Reply

Marsh Posté le 01-07-2004 à 11:21:49    

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 ? :D


Message édité par Titalium le 01-07-2004 à 11:23:56
Reply

Marsh Posté le 01-07-2004 à 12:26:01    

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 :D)

Reply

Marsh Posté le 01-07-2004 à 13:16:44    

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...

Reply

Marsh Posté le 01-07-2004 à 13:40:10    

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.

Reply

Marsh Posté le 01-07-2004 à 17:38:18    

Arjuna a écrit :

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.

Reply

Marsh Posté le 01-07-2004 à 21:57:52    

Tous les SGBD utilisent ce système.

Reply

Marsh Posté le 02-07-2004 à 17:12:29    

Arjuna a écrit :

:heink:
 
T'as vu ça où ?
 
1) FK et PK n'ont rigoureusement AUCUN rapport.
 

euh si quand même un FK est forcément la PK d'une autre table :o [:aloy]

Reply

Marsh Posté le 02-07-2004 à 21:24:40    

:heink: 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.

Reply

Marsh Posté le 02-07-2004 à 21:33:40    

Glod 2 a écrit :

euh si quand même un FK est forcément la PK d'une autre table :o [:aloy]


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

Reply

Marsh Posté le 02-07-2004 à 21:35:09    

Arjuna a écrit :

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.


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

Reply

Marsh Posté le 02-07-2004 à 21:47:03    

gizmo a écrit :

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.

Reply

Marsh Posté le 02-07-2004 à 21:50:49    

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 [:spamafote]

Reply

Marsh Posté le 02-07-2004 à 22:14:43    

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 ;)

Reply

Marsh Posté le 02-07-2004 à 23:53:11    

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

Reply

Marsh Posté le 03-07-2004 à 01:02:05    

Titalium a écrit :

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.


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

Reply

Marsh Posté le 03-07-2004 à 02:51:34    

HappyHarry a écrit :

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


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)

Reply

Marsh Posté le 03-07-2004 à 03:11:52    

HappyHarry a écrit :

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


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

Reply

Marsh Posté le 03-07-2004 à 13:24:58    

Titalium a écrit :

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 :o

Reply

Marsh Posté le 03-07-2004 à 13:27:59    

Arjuna a écrit :

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)


 
je n'ai jamais dit le contraire [:spamafote]
 
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 [:spamafote]

Reply

Marsh Posté le 03-07-2004 à 13:29:08    

HappyHarry a écrit :

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


 
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.

Reply

Marsh Posté le    

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed