Discussion :

[Dendrite]

Je m'explique :

Je fais une admin pour des lecteurs volontaires à destination des aveugles.

Le premier lecteur qui entre la publication toto18, entre le nombre d'articles disons 30 ici...

Ca lance automatiquement la création de cette table dans la db qui se nommera toto18, créera 30 enregistrements vides du genre article1 article2 etc... et deux champs.

Ensuite, on lui présente le formulaire dans lequel il fait son choix d'articles à réserver puis à transférer.

Cela remplira les champs avec en gros à R4 -(réservé par lecteur dont l'id est 4) et T4 (transféré par lecteur dont l'id est 4) etc. etc...

Capicco ?

Si un second lecteur ouvre ensuite la même publication Toto18, ça ouvre automatiquement ladite table puisqu'elle existe déjà, sans l'écraser tant qu'à faire... Ca lui présente sous forme de formulaire les champs encore vide, et zou, on continue...

Mon problème (entre de multiples autres) est le suivant : comment se prémunir des problèmes qui peuvent surgir quand deux lecteurs se connectent en même temps ? D'autant que la publi paraissant le mercredi soir, il y a des chances qu'on se précipite tous à la même heure pour réserver le boulot...

Merci de vos lumières !

PS : Si vous voyez un problème grave de méthodologie, n'hésitez pas non plus... C'est pas si simple mon truc et il y a peut-être de merveilleux raccourcis que je ne connais pas, en PHP ou bien en mysql ?

[sabotage]

Bonjour,

Créer de multiples tables contenant les memes catégories d'information complique déjà les operations de lecture / ecriture.
Je n'ai pas tout compris a ton systeme mais comment ferrais-tu par exemple pour retrouver une reference ? il te faudra parcourir toutes les tables pour voir si elle est présente dans celle d'un utilisateur.

Plutot que de créer des tables portant la reference de l'utilisateur, créé une seule table avec une colonne indiquant l'utilisateur.

[Dendrite]

Je m'explique, chaque semaine paraît un nouveau toto18 puis 19 puis 20... etc...

Chaque mois, paraît un nouveau riri13, riri14, riri15 etc...

Chaque parution, que dis-je, chaque numéro de parution, n'a jamais le même nombre d'articles, et il faut attendre que la parution soit en ligne pour le savoir.

Chaque table de ma db (en dehors de ma table lecteurs) n'a qu'une durée d'utilité très éphémère, c'est pour se répartir le boulot de lectures en cochant ce qu'on veut à deux niveaux : 1) je m'en charge 2) c'est fini, c'est transféré...

Voilà un peu pourquoi il me semble indispensable que chaque nouveau numéro crée une nouvelle table, et une fois la parution audio en ligne, je peux détruire la table, je m'en fiche... Elle ne sert qu'à remplir le formulaire pour se compléter harmonieusement à chaque parution sans s'envoyer des tonnes de mails et en cochant ce qu'on veut lire sans se consulter au gré de ses disponibilités...

Cela te semble-t-il plus logique maintenant ?

Mon problème qui reste entier : Comment éviter le choc de deux lecteurs qui modifient la db en même temps ?

[sabotage]

Non ca n'est pas plus logique, tes données pourraient tout de même etre dans la meme table. Mais tu fais comme tu le souhaites.

Pour ton probleme : tu peux ajouter une condition WHERE a ton update.
ie :
les deux utilisateurs ont la liste resultat de SELECT * FROM table WHERE dispo = 0;

le premier s'affecte des elements UPDATE ... WHERE dispo = 0
dans le meme temps le deuxieme s'affecte les memes elements, les mises à jour ne seront pas faites car les elements ne sont plus en dispo = 0. Tu peux ensuite comparer le nombre d'enregistrements traités au nombre de modifications demandés pour lui annoncer qu'un certain nombre d'actions n'ont pas pu être prise en compte.

[Dendrite]

Oh que non je fais pas comme je souhaite... J'essaie simplement désespérément de comprendre ta solution, d'autant qu'elle paraît plus simple...

Une seule table... Avec donc quoi dedans ? C'est ça que je comprends pas...
On fait un enregistrement par article c'est celà ? du genre TOTO18article16 etc, et autant de champs que de lecteurs ?

Mais alors, comment je distingue article réservé et article transféré dans ce cas ?

[ThomasR]

Bonjour,

je soutiens la solution de sabotage qui est beaucoup plus flexible et logique.

Créé les tables suivantes :

ARTICLES(id, id_publication)

PUBLICATIONS(id, id_auteur, nb_articles)

AUTEURS(id, nom, prenom)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
-- Récupérer les articles de l'auteur 18
SELECT ARTICLES .* FROM ARTICLES LEFT JOIN PUBLICATIONS ON ARTICLES.id_publication=PUBLICATIONS.id
LEFT JOIN AUTEURS ON PUBLICATIONS.id_auteur=AUTEURS.id
WHERE AUTEURS.id=18

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
-- Récuperer les publications d'un auteur 18
SELECT PUBLICATIONS.* FROM PUBLICATIONS LEFT JOIN AUTEURS ON PUBLICATIONS.id_auteur = AUTEURS.id WHERE AUTEURS.id=18

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
-- Articles d'une publication 5
SELECT ARTICLES.* FROM ARTICLES LEFT JOIN PUBLICATIONS ON PUBLICATIONS.id = ARTICLES.id_publication
WHERE id_publication = 5

Pour l'insertion d'articles il te suffit de créer autant de champs que le nécessite nb_articles ou alors de n'en créer que ce qu'il faut, et proposer l'ajout d'un article si le nombre d'articles existant pour cette publication est inférieur à nb_articles.