J’aimerais faire un petit systeme de messagerie en ligne. Pour cela, j’utilise une base de données MySQL.
J’ai une table qui contient les données concernant les utilisateurs (identifiants et autres)
Et je ne connais pas grand chose encore en termes de performances des recherches dans les bases de données.
Donc, tout naif, j’imaginais que j’allais créer une table de messages, qui serait une ‘mailbox’ pr chacun de mes utilisateurs.
Mais le problème, c’est que j’aimerais que ma base de données soit capable, par l’utilisation des clés étrangères, de garder une certaine intégrité: si je supprime un utilisateur (en supprimant la ligne de l’utilisateur ds la table des utilisateurs), j’aurai voulu que la base supprime toute seule la table mailbox correspondante, et ca a pas l’air d’etre possible ( si?)
Donc, doit on créer une seule table de messagerie qui contiendrait le contenu de ttes les boites ou y’a t’il un moyen intelligent pour utiliser une table par utilisateur?
Tu peux créer une contrainte entre une table maître UTILISATEURS et une table fille MESSAGES
Voici 2 liens utiles sur ce sujet (cherche le mot CASCADE):[ul]
[li]nexen : MySQL, CREATE TABLE[/li][li]nexen: Mysql, clés étrangères[/li][/ul]
ben justement, les cascades peuvent supprimer des lignes d’une table, mais pas la table elle meme : ca m’oblige donc a stocker tous les messages de tous les utilisateurs dans la meme table, et c’est ca qui me tracasse : est ce que c’est raisonnable?
Si tu arrives à créer une table de message pour un utilisateur (et je ne sais pas comment tu va t’y prendre), il doit y avoir moyen de supprimer la même table au moment de la suppression de l’utilisateur. Tu ne veux faire ça qu’en SQL ? En gardant dans une autre table par exemple pour un ID d’utilisateur le nom de la table message associé. Au moment de la suppression de l’utilisateur tu recherche le nom de la table message qui lui est associé et tu supprimes. C’est faisable ?
Non non une table Messages avec les messages de toute le monde. Et le CASCADE ON DELETE c’est le mal, mais bon a ce niveau la je suis pret a negocier B)
J’ai pas encore beaucoup d’expérience dans le domaine, mais il me semble que c’est un peu contre-nature de créer des tables, dynamiquement, comme ça, pendant l’exploitation de la base. Si je ne m’abuse, les tables d’une BDD sont figées lors de la création de la base et on n’y touche plus après, non ?
Par contre, pourquoi « CASCADE ON DELETE » c’est le mal?
Ca me parait au contraire très bien de bien décrire la BDD afin qu’elle garde d’elle meme un maximum de cohérence, non?
Non les foreign key c’est le bien, le cascade on delete c’est le mal parceque en dehors des cas triviaux c’est un bordel infernal a gerer et tu peux avoir des effets de bord qui sont difficile a comprendre et potentiellement dangereux pour tes donnees (et les transactions avec un lock du bon niveau c’est bien++). Vaut bien mieux se taper une erreur qui dit “je peux pas effacer, y a une FK” et travailler de bas en haut dans une trasaction propre, que de faire un delete qui va se mettre a fouttre a la poubelle la moitiee de la DB en cascade parceque “oups” ca ramene pas tes donnees B).
En fait je n’ai jamais utilisé le CASCADE ON DELETE, je n’en ai jamais eu l’utilité. J’ai toujours tout fait par transaction.
D’ailleurs Glop j’ai une question à te poser:
Autant je pense maîtriser la base de données et la programmation client/serveur tout au moins en base de données (Delphi), autant j’ai du mal à comprendre comment les environnements asynchrones (les clients légers jsp, .net) peuvent gérer les transactions ?
Sous .net et jsp je n’ai fait que des “Hello World”. As tu une explication ou un lien pas trop technique sur le sujet, assez synthétique ? Quand je dis pas trop technique c’est technique du point de vue de la base de données mais sans des notions trop extrêmes d’architecture client léger vu que je n’y connais pas grand chose en client léger.
Le peu que j’ai compris:
BDD<----transaction------>Apache/IIS------- comment ça se passe ? ------->Client léger
En fait je suis pas sur de comprendre la question. T’es asynchrone entre les requetes, pas au sein d’une requete, la tu peux y faire des transactions comme d’hab, avec ou sans stored proc. Apres tu peux devenir funky et faire des choses un peu plus originales mais c’est au cas par cas.
[quote=“phili_b, post:9, topic: 32732”]En fait je n’ai jamais utilisé le CASCADE ON DELETE, je n’en ai jamais eu l’utilité. J’ai toujours tout fait par transaction.
D’ailleurs Glop j’ai une question à te poser:
Autant je pense maîtriser la base de données et la programmation client/serveur tout au moins en base de données (Delphi), autant j’ai du mal à comprendre comment les environnements asynchrones (les clients légers jsp, .net) peuvent gérer les transactions ?
Sous .net et jsp je n’ai fait que des “Hello World”. As tu une explication ou un lien pas trop technique sur le sujet, assez synthétique ? Quand je dis pas trop technique c’est technique du point de vue de la base de données mais sans des notions trop extrêmes d’architecture client léger vu que je n’y connais pas grand chose en client léger.
Le peu que j’ai compris:
BDD<----transaction------>Apache/IIS------- comment ça se passe ? ------->Client léger[/quote]
Pour .NET et SqlServer, tu peux regarder du côté de MS DTC (distributed transaction bande de pervers).
Sinon de mémoire, pour un truc plus générique, tu peux regarder du côté du Session State, ou tout ce qui est mapping objet relationnel.
En fait en client léger quand le client ne donne plus signe de vie comment détecter la fin de la connexion et faire un rollback ?
Est-ce qu’en client léger il y a une isolation des transactions ? Si quelqu’un change le prix d’un produit, après validation de ma commande le prix reste le même qu’il était au début de la transaction ?
Autrement dit est-ce que le développement client léger est le même qu’en client serveur ou alors il y a a des choses spécifiques à faire (genre LOCK à la main)?
En écoutant parler des collègues j’avais l’impression que les transactions sont mal gerées en client léger.
Pas pire qu’il client lourd, du moment ou tu fais ca sur le reseau y a a gerer timeout et autres abandons de transactions, comment tu veux que ca apparaisse aux autres clients en milieu de transaction depend de ton niveau de lock et autre, mais des trucs communs client lourd ou leger. Enfin tout ca a rien a voir avec qui fait les requetes. Tu fais des transactions sur une requete du client, si tu veux repartir une transaction sur plusieurs requetes, tu gere ca sur le client et tu soumet le changement dans une seule transaction. Enfin je vois toujours pas le probleme B) T’as pas une exemple precis?