base de donnée sur un site web, avec une interface de saisie et d'affichage

[invite76481f9c]

Bonjour;

Dans mon travail je suis chargé de la gestion du site web de la société.
Ce site web est construit autours du CMS Drupal et utilise des bases de données phpmysql.
je souhaiterais construire une base de donnée en php mysql qui va contenir une liste d'experts dans certains domaines avec leurs coordonnées. ceci ne devrait pas être compliqué jusqu'au stade de liaison entre les tables.
Ensuite, j'aimerais préparer une interface graphique sur le site web de la société, qui permettrais de saisir une requête, et d'afficher les résultats à partir de cette base de données.
Est ce que l'un de vous aurait des idées à me donner ou pourrait m'aider?

Merci bcp d'avance.
-----

[invite8214f726]

Tu as plusieurs questions à te poser avant de foncer tête baissée sur ce projet.

Premièrement tu évoques la base de données (en mysql, php n'a rien à voir). Essaie de définir tes différentes tables et champs qui vont la constituer.

L'interface graphique qui te permettra de mettre à jour ta base de donénes devrait en découler naturellement (ce sera un formulaire avec un input par champ à modifier manuellement, et le reste sera calculé, et enfin tu enverras tout via php cette fois).

Mais tu évoques le fait que le site tourne sous drupal.

Du coup il faut que tu voies ce que tu comptes faire pour ton site et en combien de temps.

Quels sont les intérêts principaux d'un CMS type Drupal ?

Le développement est modulaire, ainsi tu peux créer facielement des modules qui seront itnégrés ou non.
Plusieurs formats de base de donénes sont respectés, et avec tout le langage qui l'accompagne, etc...

En gros les questions que tu vas devoir te poser sont :

Est ce que mon module sera utilisé uniquement par ma société ou d'autres personnes ?
Est ce que ma société pourrait être amenée plus tard à changer de plateforme (et en particulier de SGBR) ?
Combien de temps ai je pour développer ?

Pour faire simple : si tu veux développer vite un module tout bête développé en PHP suffira, si le code doit être portable il faut bien sur exploiter tout le framework fournit par Drupal, ce qui sera plus long, mais plus sécurisé, fiable et portable.

[invite8666d089]

Je peux t'aider de A-Z pour la construction de ta table et de son interface (formulaire), à condition qu'on ne parle plus de CMS.
Je n'ai rien contre, après avoir passé un bon mois à étudier Joomla pour m'en faire une idée ; c'est très bien fait, mais je n'aime pas le concept.

En fait, tu as besoin d'une seule table. Rien de plus simple pour un débutant en PHP.

[invite76481f9c]

Je peux t'aider de A-Z pour la construction de ta table et de son interface (formulaire), à condition qu'on ne parle plus de CMS.
Je n'ai rien contre, après avoir passé un bon mois à étudier Joomla pour m'en faire une idée ; c'est très bien fait, mais je n'aime pas le concept.

En fait, tu as besoin d'une seule table. Rien de plus simple pour un débutant en PHP.

Bonjour;
je te remercie beaucoup pour ta réponse qui là, me rend bien heureux!.

Bon, tu veux qu'on crée l'interface, mais qu'on ne parle plus de CMS. est ce que par ceci tu veux dire qu'on ne va pas rester lié au reste du site qui est bâtit avec un CMS ? si c'est le cas je n'ai rien contre. de Toutes façons il m'était arrivé d'avoir à créer certaines pages en html pour les sécuriser avec un mot de passe ou pour pas qu'elles soient visible à partir du site web, sans oublier que je te serais bien remerciant et gratifiant pour ton aide.

En fait voilà, le site web en question est là .
je doute fort qu'on puisse utiliser une seule table.
un modèle en access (.mdb) est déjà disponible en ligne
en fait, il s'agit d'une base de données qui va, selon l'espèce ou le sujet en question, donner un tableau , affichant l'un après l'autre, les experts Méditerranéens ainsi que les organismes agissants dans le sujet en question avec leur coordonnées. à ce ci viendrait s'ajouter un champ permettant à l'utilisateur LAMBDA d'effectuer une recherche pour trouver les résultats voulus.
je pense donc, qu'une seule table ne peut pas suffir pour cette DB.
Par ailleurs, et comme ça a été mentionné par Doh-a

Est ce que ma société pourrait être amenée plus tard à changer de plateforme (et en particulier de SGBR) ?

, plus tard, en cas de besoin, nous pourrions changer de SGBD, du moment que ça ne touche pas à notre site web.
Mon but étant de Préparer un premier travail avec les moyens du bord, et puis ... évaluer les limites rencontrées et évoluer à partir de là.

Merci beaucoup.

[A voir en vidéo sur Futura]

[invite8666d089]

Percussion ! nous avons écrit en même temps. Je ne change rien.

Je reprends plus en détail.

Tu dis qu'il s'agit d'une création. A priori tu n'as pas à te casser la tête à créer une table pour l'identité des experts et leurs coordonnées et une autre table pour les domaines de compétence. Une seule suffit.

Par expérience, j'ai une nette préférence pour un système relationnel à deux tables (les experts avec leurs coordonnées d'un côté et les domaines de compétence de l'autre) ; dans le cahier des charges il faut que le truc dise aujourd'hui "maman" ; dans cinq ans il y aura toujours un penseur pour penser que ce serait bien s'il disait aussi "papa" (vécu !).

Maintenant, si la base de données MySQL existe déjà et si les données à joindre sont dans des tables différentes, le problèmes est complètement différent, mais c'est encore plus simple.

Le fait que l'architecture d'ensemble soit celle d'un CMS ne change rien à ton problème qui peut être facilement traité en PHP, que les tables existent déjà ou soient à créer.

[invite76481f9c]

jusque là, j'ai pu transférer les diffèrentes tables et données déjà existantes sous mysql. la photo jointe, montre les dix tables utilisées.
A partir de maintenant, je vais voir s'il y'a un moyen rapide pour répliquer les liaisons qui existaient sous accees entre les différentes tables dans la base mysql.
des idées ?

[invite1445654e]

mysql dispose du mécanisme aussi des clefs étrangères ...
et dont tu peux modifier en utiliser mysql workbench
surtout la partie modelisation

[invite76481f9c]

mysql dispose du mécanisme aussi des clefs étrangères ...
et dont tu peux modifier en utiliser mysql workbench
surtout la partie modelisation

Merci beaucoup
je télécharge workbench, et je vais voir ce que ça donne.

je vous suis très reconnaissant pour l'aide et le soutient que je trouve au près de vous.

[invite1445654e]

c'est avec cela que j'administre , je cree mes tables , et tu peux faire des reverse engineering (la partie model) et ensuite synchroniser avec la base

[invite76481f9c]

... et tu peux faire des reverse engineering (la partie model) et ensuite synchroniser avec la base

est ce que c'est grâce au reverse engineering qu'on édite les relation entre les différentes tables ?

[invite8666d089]

Bien vu le schéma relationnel.
Entre nous, il était plus simple de mettre directement un champ Species dans la table EXPERTS, ce qui permettait de se passer de la table d'index RELEXPSPE. Bon c'est fait, c'est fait.

Dis-moi si j'ai bien compris : le point d'entrée de ton formulaire est un champ de la table Species et il faut extraire de la table EXPERTS (via la table des index RELEXPSPE) la liste des experts compétents avec leurs coordonnées ?

[invite1445654e]

est ce que c'est grâce au reverse engineering qu'on édite les relation entre les différentes tables ?

voila
et quand tu as finis de "dessiner" tes tables il suffit que tu selectionnes dans le menu database synchronize model
voici ce que cela donne avec un exemple de table

[invite76481f9c]

heuuu, je ne saurais pas répondre à ta question. En fait, c'est une base de données qui a été crée il y a 6 ans, par un consultant. je comptais me baser dessus pour ensuite incrémenter de nouvelles entrées.
Par ailleurs, cette db conserne les oiseaux. il va me falloir en créer d'autres pour les autres animaux.
je pense que cette db a été faite selon ce shéma:

Liste d'espèces

Liste d'experts

Liste d'aires

Liste de spécialités

en se basant sur cette architechture, l'utilisateur peut chercher la liste des spécialistes d'une espèce, la liste de spécialistes par aire, par spécialité, ...
donc il n'y aura plus de limitation.

Ensuite, il sera possible d'utiliser la meme base de données pour toutes les espèces voulues, tous les experts, et ce sont les filtres et les relations qui joueront leur role pour sortir le résultat.

[invite76481f9c]

ventilome, pour une raison que j'ignore, j'arrive pas à télécharger ta pièce jointe, elle est meme pas cliqueable.

[invite8666d089]

Normal, la pièce jointe est en attente de validation. Stand-bye !

[invite76481f9c]

voila
et quand tu as finis de "dessiner" tes tables ...

sur la photo des relations entre les diffèrentes tables sous access que j'avais joint, je vois qu'il y'a des relations 1o oo:1 et oo:n

sous workbench, j'ai deux types de relation 1:1, deux types de 1:n, un type n:m et un dernier que je comprend pas trop.
là j'ai mes différentes tables ouvertes sur un plan en mode engineering, mais je m'y perd un peu pour les relation sous workbech

[invite1445654e]

en attente d'approbation ...

[invite1445654e]

bon je vois que tu as besoin sous mysql que des tables
subjects
geographics
langue
experts
species
famille

bon les relations n:m tu relies avec ce type de relation : subjects-experts
geo-experts
langue-experts
experts-species
il va generer de lui meme les tables qui se trouvent entre les deux

pour les deux premiers type de relation (pointillé)
il va donc ajouter une clef etrangere sur l'une des deux tables
pour les deux suivantes
il va donc ajouter une clef etrangere sur l'une des deux tables et cette clef sera aussi clef primaire ...
il te reste qu'a prendre une relation 1:n (en pointillé) pour lier famille a species

[invite76481f9c]

Bien vu le schéma relationnel.
Entre nous, il était plus simple de mettre directement un champ Species dans la table EXPERTS, ce qui permettait de se passer de la table d'index RELEXPSPE. Bon c'est fait, c'est fait.

Dis-moi si j'ai bien compris : le point d'entrée de ton formulaire est un champ de la table Species et il faut extraire de la table EXPERTS (via la table des index RELEXPSPE) la liste des experts compétents avec leurs coordonnées ?

un expert peut être expert pour plusieurs espèces, comme il peut œuvrer sur plusieurs aires, ceci ne serait pas bien géré si on utilisait une seule table. pour ça, il faut spécifier pour chaque expert toutes les informations le concernant, ça va faire beaucoup de saisie supplémentaire. n'est ce pas ?

[invite76481f9c]

d'accord, mais est ce que quelqu'un pourrait m'expliquer ce que c'est que les relations 1: oo, oo:n sous access et n:m sous workbech ?

[invite1445654e]

c'est du merise ou du modele entite association
ceux sont les cardinalités entre les deux tables
1: oo cela veut dire 1:n
exemple pour un element de la table A il existe n occurence de la table B
si j'applique la relation n:m sur subjects-experts
pour un subject je peux avoir n experts
pour un expert je peux avoir m subjetcs
c pour cela qu'il genere donc une table entre les deux tables qui est en fait une sorte de table contenant les couples des identifiants de subject et d'expert

[invite76481f9c]

A l'aide! loool
Bon, j'ai utilisé bullzip MS access to mysql pour exporter les tables et les données d'une base de donnée bien plus grande que celle dispo sur le site web (200 Mo). une fois sur la base de données résultante: movedb, je me suis rendu compte que la table expert n'y est pas. Je l'ai donc importé d'une autre base de données crée à partir du fichier du site web.

le truc, là je suis sous workbech à essayer de faire les liens, mais je me suis rendu compte que la table Experts ne contient pas de clé primaire, j'espère que workbech me permet de remédier à celà

[invite1445654e]

roooo la clef experts pas de clef primaire
bah si tu as bien expref non dans ta table
quand tu clique sur la table sous le workbench en bas tu peux modifier la structure de la table
clique sur columns
tu as ton detail de tes colonnes
pref ta colonne ref et coche pk et nn et voila une belle clef primaire

[invite76481f9c]

VOilà, les liaisons sont fin prêtes, mais ensuite... est ce que c'est enregistrable ?. est ce que c'est MySQL qui gère les liaisons ? n'est ce pas la page (interface graphique) qui va être crée qui va chercher chaque information là où il le faut ?

Si je veux enregistrer ça , comment j m'y prends ? je vois qu'il exporte uniquement sous format workbech mysql.

[invite1445654e]

simple dans le menu Database et tu clique sur synchronize Model
ci joint les photos d'ecrans pour ma part j'ai ajouté un colonne

Par contre inverse la relation qui part de famille

[invite76481f9c]

j'ai une erreur:
ERROR: Error 1253: COLLATION 'latin1_swedish_ci' is not valid for CHARACTER SET 'utf8'

CREATE TABLE IF NOT EXISTS `movedb`.`species_has_experts` (

`species_SPEREF` VARCHAR(50) NOT NULL ,

`experts_EXPREF` INT(11) NOT NULL ,

PRIMARY KEY (`species_SPEREF`, `experts_EXPREF`) ,

INDEX `fk_species_has_experts_expert s1` (`experts_EXPREF` ASC) ,

INDEX `fk_species_has_experts_specie s1` (`species_SPEREF` ASC) ,

CONSTRAINT `fk_species_has_experts_specie s1`

FOREIGN KEY (`species_SPEREF` )

REFERENCES `movedb`.`species` (`SPEREF` )

ON DELETE NO ACTION

ON UPDATE NO ACTION,

CONSTRAINT `fk_species_has_experts_expert s1`

FOREIGN KEY (`experts_EXPREF` )

REFERENCES `movedb`.`experts` (`EXPREF` )

ON DELETE NO ACTION

ON UPDATE NO ACTION)

ENGINE = MyISAM

DEFAULT CHARACTER SET = utf8

COLLATE = latin1_swedish_ci

SQL script execution finished: statements: 5 succeeded, 1 failed

[invite76481f9c]

j'ai effacé la liaison n:m entre les tables "experts" et "species" et je l'ai refait, mais j'ai toujours le meme problème

[invite76481f9c]

je vois qu'il y'a à la première ligne du message d'erreur un désaccrod entre l'utf8 et le latin1_swedish_ci. si je changeais ce dernier, ça ne devrait pas résoudre le problème ?

[invite76481f9c]

je perdrais peut etre la possiblité de mettre certains caractères dans les nom et prénom des personnes

[invite1445654e]

c'est une base suedoise ?
a cote de columns tu as l'onglet table moi j'ai latin1-default collation
change pour voir
cote clef primaire
il est toujours bon par table d'avoir un clef primaire technique style un entier qui s'autoincremente
et une clef unique (métier)

Essaie de mettre en UTF8