mysql - accès ou non à une fiche détaillée depuis une liste

Version imprimable

27/02/2012, 10h23
Skpflz

mysql - accès ou non à une fiche détaillée depuis une liste

Bonjour,

je suis débutant en la matière et j'aurais besoin que l'on me guide, car j'ai peu :weird:, mais vraiment très peu :weird: de temps à disposition. Voilà le projet sur lequel je travaille:

1. Sur la homepage, j'ai un menu qui permet d'accéder à (sur une autre page):

2. Différentes listes générées chacune par une requête SQL. Chaque liste est constituée de clients (nom, adresse, etc.) - données en provenance d'une table.

3. A partir des inscriptions figurant sur ces listes, et au moyen d'un lien texte ou d'une image cliquable, on accède à:

4. Une fiche détaillée présentant un ou deux clients (associés) de la liste précédente (soit depuis l'inscription d'un client, soit depuis l'inscription de deux clients). Les données proviennent de la table utilisée précédemment et d'une autre table (textes et images).

5. La fiche détaillée est visible ou non (principe abonnement gratuit / abonnement payant).

Ma question porte sur le lien client/fiche détaillée (principe abonnement gratuit / abonnement payant). Comment procéder? au niveau de MySQL, de la requête SQL, du php? Je préférerais éviter le principe page principale/page détail avec affichage d'un message "cette fiche est vide" :(

Merci d'avance pour le coup de main!

Skpflz

Mac
MAMP
Dreamweaver
MySQL
InnoDB

PS1: mille excuses si le sujet a déjà été abordé dans le forum
PS2: si vous avez des url de tutos complémentaires, je suis preneur!
27/02/2012, 10h51
RunCodePhp

Salut

Citation:

Ma question porte sur le lien client/fiche détaillée (principe abonnement gratuit / abonnement payant). Comment procéder? au niveau de MySQL, de la requête SQL, du php? Je préférerais éviter le principe page principale/page détail avec affichage d'un message "cette fiche est vide"

Pas sûr d'avoir compris la question.
Mais comme ça, si on veut éviter qu'un lien mène vers une fiche vide, il ne faut pas proposer/créer le lien en question.
Ce qui sous-entend de faire une requête qui va récupérer uniquement des données "éditables" en détail, et n'afficher que celles là.

Où est le problème ?
Qu'est-ce qui conditionne qu'une fiche détaillée est visible ou non ?
27/02/2012, 11h09
Skpflz

mysql - accès ou non à une fiche détaillée depuis une liste

Merci pour le message et désolé si ma question est mal posée!

Mais comme ça, si on veut éviter qu'un lien mène vers une fiche vide, il ne faut pas proposer/créer le lien en question.
Ce qui sous-entend de faire une requête qui va récupérer uniquement des données "éditable" en détail, et n'afficher que ceux là.

Alors justement, c'est exactement là que je ne sais pas comment faire: le lien (où et comment) - j'imagine qu'il faut créer une colonne (NULL) dans la table, mais quel type de colonne? et comment rendre le lien actif?

Qu'est-ce qui conditionne qu'une fiche détaillée est visible ou non ?

C'est le principe abonnement gratuit/abonnement payant qui conditionne la visibilité ou non de la fiche détaillée. En d'autres termes, selon son type d'abonnement, le client a une fiche détaillée ou non. Quand la fiche existe (ou est accessible), elle visible par tous les visiteurs du site.
27/02/2012, 15h14
RunCodePhp

Citation:

Alors justement, c'est exactement là que je ne sais pas comment faire ...
...
C'est le principe abonnement gratuit/abonnement payant qui conditionne la visibilité ou non de la fiche détaillée. En d'autres termes, selon son type d'abonnement, le client a une fiche détaillée ou non. Quand la fiche existe (ou est accessible), elle visible par tous les visiteurs du site.

Si cet aspect abonné gratuit/payant n'est pas représenté au niveau de la Bdd, alors il faut la créer.

Citation:

- j'imagine qu'il faut créer une colonne (NULL) dans la table, mais quel type de colonne? et comment rendre le lien actif?

Faudrait déjà voir ce que représente une fiche de ton coté (coté applicatif).
Si c'est des données déjà présentent dans la Bdd, ou alors dans des fichiers.
Si c'est dans la Bdd, c'est pas dit que ça soit mieux de créer un champ (ou colonne) avec NULL comme valeur.

Admettons qu'il y ait une table "clients_fiches", avec des fiches liées aux clients.
Donc ici il devrait avoir 2 champs du genre : clients_id - fiches_id.

On peu par exemple créer une table "clients_abonnes" qui stockera uniquement les clients abonnés.
Uniquement des couples d'identifiants : clients_id - fiches_id.
Après ça, c'est à toi de donner un sens à la présence ou non de cette données dans cette table.
On peu partir dans le sens où :
- Si on crée (insert) la fiche dans cette table -> c'est un abonnement payant.

Ce qui veut dire que toutes les fiches clients non présentes dans cette table "clients_abonnes" pourront être affichées par tous les visiteurs, de même qu'on pourra créer leur liens pour après voir le détail de ces fiches.
(donc à l'inverse : si une fiche est présente, on fera en sorte de ne pas créer de lien, de ne pas permettre l'édition par tous visiteurs).

Concrètement, il faudra créer une requête SQL qui sélectionnera uniquement les fiches non présentes dans la table pour créer les liens.

Est-ce qu'un client peu avoir plusieurs fiches ? (genre une fiche abonnée gratuit et une autre abonnée payant)

Tout ça c'est une suggestion, exemple.
Faut voir.

PS : Ce forum permet de faire des "citations", c'est fait pour réagir sur une ou plusieurs partie.
C'est étudié pour, si on peu dire (au lieu de différencier avec des couleurs de texte).
28/02/2012, 09h38
Skpflz

mysql - accès ou non à une fiche détaillée depuis une liste

Merci pour la réponse! Je vais regarder tout ça de plus près et je reviens. Désolé pour la mise en couleurs, c'est la 2e fois que je poste ici et je n'avais pas fait attention :?

à+

Dominique
15/03/2012, 19h36
Skpflz

mysql - accès ou non à une fiche détaillée depuis une liste

Bonsoir,

Je suis retourné potasser parce que je me suis rendu compte que j'avais pas le niveau suffisant pour comprendre. Raison pour laquelle je ne me suis plus manifesté.

En relisant ta réponse, je me dis que je me suis mal expliqué, je vais essayer d'être plus précis. On va arrêter de parler d'abonnement payant ou gratuit parce que ça brouille tout. Le principe est celui-là:

On a une liste de noms avec des accès ou non à des fiches détaillées

http://www.sso.ch/index.cfm?uuid=264...d=&o_lang_id=8

Le premier lien dans la liste, Frei Marcel, est en couleur et souligné en pointillé. Quand on clique, la fiche de Frei Marcel s'ouvre.

Dans mon projet -comme on nous répète partout qu'il faut absolument éviter d'avoir des répétitions- j'ai, pour le moment:

une table clients
une table indication
une table orientation
une table langues

Des jointures relient la table clients aux trois autres tables au moyen de requêtes SQL établies en fonction de divers critères (lieu, indication, orientation).
Chacune de ces requêtes affiche une liste de noms, avec adresse, langues parlées et autres informations.

Tous les clients sont inscrits et figurent dans une ou plusieurs listes (ça dépend des critères des requêtes).

Les fiches:

Certains clients posséderont une fiche. Fiche à laquelle on accédera depuis la ou les listes (cf exemple de Frei Marcel).

Un lien dans l'inscription (dans la ou les listes), permettra d'afficher ladite fiche (le contenu changera selon le client). Le lien pourrait être : le nom souligné ou une indication "voir la fiche" ou une image cliquable.

Deux clients (des associés) pourront posséder en commun la même fiche, mais un client ne pourra pas posséder plus d'une fiche (concurrence déloyale).

Pour les fiches, j'avais pensé à une page/fiche remplie avec des données extraites d'une table fiches, avec des jointures sur les tables précédentes (pour le nom, l'adresse, etc.). Si il n'y avait que quelques dizaines de fiches, ça serait jouable sous forme de fichiers (pages), mais si il y en a plus ça va être galère à gérer par la suite.

Voilà! merci encore et bonne soirée!

Dominique
16/03/2012, 10h41
Skpflz

Oups, il faut cliquer sur "recherche" à côté de la spécialisation "orthodontie" dans

http://www.sso.ch/index.cfm?uuid=264...d=&o_lang_id=8

pour voir l'exemple concret
16/03/2012, 13h06
RunCodePhp

Citation:

En relisant ta réponse, je me dis que je me suis mal expliqué, je vais essayer d'être plus précis. On va arrêter de parler d'abonnement payant ou gratuit parce que ça brouille tout.

Le problème c'est que le lien donne rien de plus comme indications.
Je vois juste une liste de dentistes classés par pays.

Pour ma part, le mieux est de décrire les choses comme elles le sont dans la réalités, sans inventer, sinon on risque de s'éloigner du problème.

Citation:

Certains clients posséderont une fiche. Fiche à laquelle on accédera depuis la ou les listes (cf exemple de Frei Marcel).

Pourquoi "possèderont" ?
Certains clients peuvent ne pas avoir de fiches ? Si c'est le cas, est-ce que la (ou les) condition te semble importante pour modéliser la Bdd ?

S'il est possible qu'un client n'est pas de fiche, rien oblige de donner une signification sur l'existence ou non d'une fiche client.
Mais ceci étant "un fait" (quelque part une réalité), on peu lui donner une signification, un sens.

Citation:

Deux clients (des associés) pourront posséder en commun la même fiche, mais un client ne pourra pas posséder plus d'une fiche (concurrence déloyale).

Donc on aurait une relation 0-1 entre 1 client et les fiches.

De mon coté les choses restent inchangées par rapport à ce qu'il a été dit plus haut.
Il faudrait une table "fiches" qui enregistrerait toutes les fiches.
Puis une table (genre) "clients_fiches" qui associera les fiches aux clients.
(même chose qu'auparavant).

Ou alors, ceci :
Une table "fiches" (pour toutes les fiches)
Puis rajouter un champ (genre) "fiche_id" dans la table "clients" avec une valeur NULL par défaut (pour le cas d'un client sans fiche).

En quoi un modèle comme ci-dessus n'irait pas ?

Au passage, tu n'as jamais été précis sur se qui qualifie une fiche, se que contient une fiche ou quelles données seraient liées à une fiche.
Rien ne dit qu'il faille vraiment une table "fiches", les données peuvent être piochées dans d'autres tables pour générer la fiche.
Mais comme c'est pas très clair ???
16/03/2012, 16h45
Skpflz

Hello!

Citation:

Envoyé par RunCodePhp

Le problème c'est que le lien donne rien de plus comme indications.
Je vois juste une liste de dentistes classés par pays.

8O Chez moi, le lien indiqué est fonctionnel, voilà les copies d'écran de la séquence des trois pages:

1. la page de départ, choix "spécialisation - orthodontiste - recherche":
http://upload.noisette.ch/uploads/Image%201.png

2. la page de résultat affichant la liste des orthodontistes inscrits, dont l'inscription de Frei Marcel, lien en turquoise et souligné:
http://upload.noisette.ch/uploads/Image%202.png

3. la page affichant la fiche détaillée pour Frei Marcel:
http://upload.noisette.ch/uploads/Image%203.png

Citation:

Envoyé par RunCodePhp

Pour ma part, le mieux est de décrire les choses comme elles le sont dans la réalités, sans inventer, sinon on risque de s'éloigner du problème.

C'est bien ce que j'essaie de faire, avec pas mal de difficultés apparemment :(

Citation:

Envoyé par RunCodePhp

Pourquoi "possèderont" ?
Certains clients peuvent ne pas avoir de fiches ?

Le fait d'avoir une fiche ou pas dépend de l'abonnement choisi par le client. L'abonnement gratuit donne droit à l'inscription de base. L'abonnement payant donne droit à l'inscription de base + une fiche détaillée accessible depuis un lien figurant dans ladite inscription de base.

Citation:

Envoyé par RunCodePhp

Il faudrait une table "fiches" qui enregistrerait toutes les fiches.
Puis une table (genre) "clients_fiches" qui associera les fiches aux clients.
(même chose qu'auparavant).

Ou alors, ceci :
Une table "fiches" (pour toutes les fiches)
Puis rajouter un champ (genre) "fiche_id" dans la table "clients" avec une valeur NULL par défaut (pour le cas d'un client sans fiche).
En quoi un modèle comme ci-dessus n'irait pas ?

Si j'ai bien compris, il faudrait soit trois tables:

1. table "clients"
2. tables "fiches"
3. table "clients_fiches"

soit deux tables:

1. table "client" avec fiche_id valeur NULL par défaut
2. table "fiches"

Laquelle de ces deux formules me conseilles-tu pour ce que je veux faire?

Et ensuite, comment procéder pour insérer/activer le lien qui amène à la fiche détaillée?

Citation:

Envoyé par RunCodePhp

Au passage, tu n'as jamais été précis sur se qui qualifie une fiche, se que contient une fiche ou quelles données seraient liées à une fiche.
Rien ne dit qu'il faille vraiment une table "fiches", les données peuvent être piochées dans d'autres tables pour générer la fiche.
Mais comme c'est pas très clair ???

Le contenu des inscriptions et des fiches est le suivant:

L'inscription de base (gratuite) contient:
Le nom: dans la table "clients"
L'adresse: dans la table "clients"
L'indication: dans la table "indication"
L'orientation: dans la table "orientation"
Les langues: dans la table "langues"

Une fiche contient:
Le nom: dans la table "clients"
L'adresse: dans la table "clients"
L'indication: dans la table "indication"
Texte 1: dans une table "fiches"
Texte 2: dans une table "fiches"
Texte 3: dans une table "fiches"
Illustration 1: dans une table "fiches"
Illustration 2: dans une table "fiches"

Voilà, j'espère que mes réponses apportent les éclaircissements indispensables!

Bonne soirée!

Dominique
16/03/2012, 21h59
ericd69
salut,

coté sql voilà une façon de rendre tes tables "atomiques" (c'est à dire le plus compact possible) notamment:
- si dans une colonne tu as des textes qui apparaissent de manière répétitive (par exemple Monsieur, Madame pour la civilité) alors tu dois faire une table à part les contenant
- si tu as des colonnes qui représentent un nombre variable de valeurs (éventuellement répétitives au fil des lignes ou des colonnes concernées) associées à chaque ligne alors tu dois crée une table pour crées valeurs et une table de liaison qui associe l'identifiant de la ligne de la table de référence à l'identifiant de la valeur (et on peut aussi y mettre un identifiant qui dit à quoi correspond la valeur, c'est à dire l'entête des colonne d'origine)... A titre d'exemple pense à une liste de propriétés associées à un objet comme ballon -> rond, rouge, 10cm et brique -> rectangulaire, grise, 5cm, 10cm, 5cm...
si ça peut t'aider pour améliorer ton modèle de données...
17/03/2012, 09h41
RunCodePhp

Citation:

Le fait d'avoir une fiche ou pas dépend de l'abonnement choisi par le client. L'abonnement gratuit donne droit à l'inscription de base. L'abonnement payant donne droit à l'inscription de base + une fiche détaillée accessible depuis un lien figurant dans ladite inscription de base.

Pourquoi alors avoir dit que cette notion d'abonnement gratuit/payant brouillerait tout ?
Pour ma part cette notion est essentielle (capitale), c'est ce qui conditionne tout.

Par rapport à tes explications, la souscription d'un abonnement payant = fiche.
Si c'est un abonnement gratuit -> Pas de fiche.
Donc jusqu'à lors on a 2 cas possible, et uniquement 2.

Cependant, on peu représenter cela de plusieurs manières, c'est cela qui peu être embêtant.
En somme, soit on est prudent (si on peu dire), soit il n'y a pas lieu d'être prudent car les chose sont très clairs.
Il n'y a que toi qui peux trancher sur ce point (car c'est ton métier, ou alors il faut demander à la personne la plus qualifiée).
Je m'expliques.

Si on estime qu'à l'avenir (proche ou lointain) il peu avoir un 3ème (ou un 4ème, 5ème, etc ...) type d'abonnement, alors il faudrait une table "type_abonnement" où on stockerait les différents types.
table "types_abonnements" :
champs : id_type_abonnement | type
valeurs : 1 | gratuit - 2 | payant - (et les autres si c'est le cas)

Ensuite, comme apparemment un client ne peu avoir qu'1 seul type d'abonnement, on peu créer/ajouter un champ "id_type_abonnement" dans la table "clients".

Ceci dit, on peu éviter d'avoir cette table "type_abonnements" et créer/ajouter un champ "type_abonnement" de type ENUM, valeurs : 1, 2 ou textuel "gratuit, payant".

Tout ceci c'est par prudence au cas où il y aurait plus de 2 types d'abonnement.

Maintenant, admettons que les choses soient clair, net est précis : Il y que 2 type d'abonnements et il n'y aura jamais plus de 2.
Et bien là, il n'est pas utile d'avoir une table "type_abonnements" et un champ "id_type_abonnement" dans la table "clients".
C'est que j'évoquais au tout début :
On va avoir une table "clients_fiche" (ou "clients_abonnements"), et le seul fait d'enregistrer un client dans cette table fera que ce sera un abonnement "payant".
Par déduction : Un client non présent/enregistré dans cette fera que ça sera un abonnement gratuit.

En conclusion : La présence ou non présence détermine en tout logique le type d'abonnement.

Je dirais même que : Si ici on venait a créer un champ "id_type_abonnement" (valeur 1 ou 2) dans la table "clients", cette donnée sera un doublon, une donnée redondante.
Du coup : On peu avoir une information contradictoire, c'est à dire avoir 1 comme valeur du "id_type_abonnement" (c'est à dire gratuit), mais avoir 1 enregistrement (une ligne) dans la table "clients_fiche" pour le même client (c'est à dire payant). C'est 2 données/infos sont contradictoires, incohérentes.

Il me parais important de comprendre cet aspect là.

Ca n'empêche pas de le faire, mais ça suppose que le code applicatif (Php) soit fiable pour éviter ce genre d'incohérence.

Je te donnes les choses comme elles me viennent, à toi de voir si c'est bien cela ou pas.

A mon sens, avant de modéliser tout ce qui concernera les fiches, il faudrait que tu fasses un choix par rapport à cet aspect d'abonnement gratuit/payant, ou alors donner tes impressions la dessus.
Pour moi c'est ce qui conditionne tout, et je ne peux pas faire ce choix à ta place.