Comment mettre un annuaire ( base de donnees ) en ligne ?
3 réponses
Patrick RAYNAL
Je voudrais à partir d'un tableau excel ( nom, adresse e-mail, code
adhérent ) que toute personne puisse interroger la base à partir d'une
requête simple ( demander un nom ou demander à qui correspond tel
numéro ) afin qu'il soit donné en réponse la fiche complète de
l'individu.
Qui peut m'aider ?
--
Patrick RAYNAL - mailto:fa3@fr.st
Pages persos: http://www.fa3.fr.st - http://www.raynal.fr.st
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Bruno Desthuilliers
Patrick RAYNAL wrote:
Je voudrais à partir d'un tableau excel ( nom, adresse e-mail, code adhérent ) que toute personne puisse interroger la base à partir d'une requête simple ( demander un nom ou demander à qui correspond tel numéro ) afin qu'il soit donné en réponse la fiche complète de l'individu. Qui peut m'aider ?
Trois solutions : 1/ la plus simple - Tu trie le tableau Excel sur la colonne qui sera la plus utilisée pour les recherches (nom ou code) - tu exporte ça vers un fichier texte, les champs séparés par des (au choix), et si possible les champs texte entre guillemets - tu écris un script pour les recherches dans ce fichier, une page web pour lancer la recherche (formulaire etc), et un script pour afficher le résultat de la recherche dans une autre page...
Problèmes : - si le fichier est gros, les recherches ne seront pas très performantes, surtout sur le code (si c'est trié par nom) ou sur le nom (si c'est trié par code) - il faut réexporter le fichier Excel à chaque modification (avec exactement le même format, sinon ça ne va pas marcher)
2/ la plus con Même chose, mais tu exporte deux fichiers, l'un trié par nom, l'autre par code... Tu y gagnera un peu sur la vitesse de la recherche, mais ça te fait un script plus compliqué
3/ la meilleure Tu oublie Excel, tu mets tout ça dans une table MySQL, avec les index qui vont bien, et en plus du script de recherche (qui devient très simple, il suffit de construire une requête SQL simple), tu mets aussi une page (formulaire etc) et un script de saisie/modification.
Avantage : c'est standard, extensible (si la base doit accueillir d'autres infos), pas besoin d'exporter les fichiers depuis Excel, tu peux même faire tes mises à jour depuis n'importe quel machine connectée au Web (à condition d'avoir le mot de passe pour accéder à la page de saisie/modification, bien sûr).
NB : En plus, tu peux intégrer ta base Excel existante, donc pas besoin de resaisie, et tu peux écrire un script qui génère un fichier texte importable dans Excel...
Tu trouvera des infos sur comment faire ça dans n'importe quel bouquin un tant soit peu sérieux sur PHP/MySQL... Et dans de nombreux tutoriels sur le web.
HTH Bruno
-- bruno_desthuilliers bdesth[dot]nospam[arrobase]removeme[dot]free[dot]fre => very long address, isn't it ?-) --
Patrick RAYNAL wrote:
Je voudrais à partir d'un tableau excel ( nom, adresse e-mail, code
adhérent ) que toute personne puisse interroger la base à partir d'une
requête simple ( demander un nom ou demander à qui correspond tel
numéro ) afin qu'il soit donné en réponse la fiche complète de
l'individu.
Qui peut m'aider ?
Trois solutions :
1/ la plus simple
- Tu trie le tableau Excel sur la colonne qui sera la plus utilisée pour
les recherches (nom ou code)
- tu exporte ça vers un fichier texte, les champs séparés par des (au
choix), et si possible les champs texte entre guillemets
- tu écris un script pour les recherches dans ce fichier, une page web
pour lancer la recherche (formulaire etc), et un script pour afficher le
résultat de la recherche dans une autre page...
Problèmes :
- si le fichier est gros, les recherches ne seront pas très
performantes, surtout sur le code (si c'est trié par nom) ou sur le nom
(si c'est trié par code)
- il faut réexporter le fichier Excel à chaque modification (avec
exactement le même format, sinon ça ne va pas marcher)
2/ la plus con
Même chose, mais tu exporte deux fichiers, l'un trié par nom, l'autre
par code... Tu y gagnera un peu sur la vitesse de la recherche, mais ça
te fait un script plus compliqué
3/ la meilleure
Tu oublie Excel, tu mets tout ça dans une table MySQL, avec les index
qui vont bien, et en plus du script de recherche (qui devient très
simple, il suffit de construire une requête SQL simple), tu mets aussi
une page (formulaire etc) et un script de saisie/modification.
Avantage : c'est standard, extensible (si la base doit accueillir
d'autres infos), pas besoin d'exporter les fichiers depuis Excel, tu
peux même faire tes mises à jour depuis n'importe quel machine connectée
au Web (à condition d'avoir le mot de passe pour accéder à la page de
saisie/modification, bien sûr).
NB : En plus, tu peux intégrer ta base Excel existante, donc pas besoin
de resaisie, et tu peux écrire un script qui génère un fichier texte
importable dans Excel...
Tu trouvera des infos sur comment faire ça dans n'importe quel bouquin
un tant soit peu sérieux sur PHP/MySQL... Et dans de nombreux tutoriels
sur le web.
HTH
Bruno
--
bruno_desthuilliers
bdesth[dot]nospam[arrobase]removeme[dot]free[dot]fre
=> very long address, isn't it ?-)
--
Je voudrais à partir d'un tableau excel ( nom, adresse e-mail, code adhérent ) que toute personne puisse interroger la base à partir d'une requête simple ( demander un nom ou demander à qui correspond tel numéro ) afin qu'il soit donné en réponse la fiche complète de l'individu. Qui peut m'aider ?
Trois solutions : 1/ la plus simple - Tu trie le tableau Excel sur la colonne qui sera la plus utilisée pour les recherches (nom ou code) - tu exporte ça vers un fichier texte, les champs séparés par des (au choix), et si possible les champs texte entre guillemets - tu écris un script pour les recherches dans ce fichier, une page web pour lancer la recherche (formulaire etc), et un script pour afficher le résultat de la recherche dans une autre page...
Problèmes : - si le fichier est gros, les recherches ne seront pas très performantes, surtout sur le code (si c'est trié par nom) ou sur le nom (si c'est trié par code) - il faut réexporter le fichier Excel à chaque modification (avec exactement le même format, sinon ça ne va pas marcher)
2/ la plus con Même chose, mais tu exporte deux fichiers, l'un trié par nom, l'autre par code... Tu y gagnera un peu sur la vitesse de la recherche, mais ça te fait un script plus compliqué
3/ la meilleure Tu oublie Excel, tu mets tout ça dans une table MySQL, avec les index qui vont bien, et en plus du script de recherche (qui devient très simple, il suffit de construire une requête SQL simple), tu mets aussi une page (formulaire etc) et un script de saisie/modification.
Avantage : c'est standard, extensible (si la base doit accueillir d'autres infos), pas besoin d'exporter les fichiers depuis Excel, tu peux même faire tes mises à jour depuis n'importe quel machine connectée au Web (à condition d'avoir le mot de passe pour accéder à la page de saisie/modification, bien sûr).
NB : En plus, tu peux intégrer ta base Excel existante, donc pas besoin de resaisie, et tu peux écrire un script qui génère un fichier texte importable dans Excel...
Tu trouvera des infos sur comment faire ça dans n'importe quel bouquin un tant soit peu sérieux sur PHP/MySQL... Et dans de nombreux tutoriels sur le web.
HTH Bruno
-- bruno_desthuilliers bdesth[dot]nospam[arrobase]removeme[dot]free[dot]fre => very long address, isn't it ?-) --
Ramunt
Heu comparé à la solution n° trois, .... je ne sais pas pourquoi celle là serait plus lourde ??? (voir PHP et LDAP ....)
Par contre en réponse à Patrick Raynal seuls les solutions 3 et 4 sont réellement viables pour un annuaire à la fois dynamique (évolutif) et on va dire supérieur à 100 contacts. Tout dépend en fait de la réactivité et de la taille de ton annuaire .... On va dire 1 annuaire avec moins de 100 noms et 10 modif par mois : solution 1 ou 2 Plus d'1 annuaire ou plus de 100 noms ou plus de 10 modifs par mois : solution 3 ou 4 Moi je choisirai sans hésitation la solution 4.
Un peu plus sur les annuaires :
Les aléas des solutions : *Problèmes liés à la mises à jours des données : - Excell et très limité pour la gestion de données, l'interface sera limité, et tu ne pourra pas simplifier tes mises à jour, tant qu'à rester chez microsoft passe à Access : l'intérêt d'une base de donnée - L'évolution de ces logiciels, t'obligera à faire évoluer l'interface de saisie (si tu en fais une) - etc ... *Problèmes liés à la mises à jour de tes structures de données - Tes scripts seront à faire évoluer avec toute évolution de la structure de tes données ... ca arrivera plus vite que tu ne le penses. - etc ... *Problèmes inhérent au concept d'annuaire - Un annuaire de par son indépendance aux autres systèmes est assurément faux, l'objectif étant d'avoir un pourcentage d'erreur le plus faible possible d'où le besoin de réactivité. - Les données d'un annuaire sont la clef de voûte des réseaux, or tu veux mettre ton annuaire sur une réseau non ?
Je m'explique : Qu'il t'arrive de vouloir gérer tes rendez-vous avec ces gens là, de leur téléphoner, de leur envoyer un email, enfin toute application réseau qui peut avoir besoin d'information individuelle doit pouvoir accéder à ces données ... Ce n'est pas un idéal et encore moins un rêve
Bon je ne vais pas pouvoir rester plus longtemps,
Des voies à explorer : e-directory, open-LDAP, active directory, PHP et LDAP .... ect ....
"Bruno Desthuilliers" a écrit dans le message de news:
Ramunt wrote:
Et la quatrième : LDAP ?
Heu... Vu les besoins de l'OP, je ne suis pas sûr que ce soit la réponse
la plus adaptée... Ce n'est pas parce qu'il y a le mot 'annuaire' qu'il
faut tout de suite sortir l'artillerie lourde !-)
Bruno
Heu comparé à la solution n° trois, .... je ne sais pas pourquoi celle
là serait plus lourde ??? (voir PHP et LDAP ....)
Par contre en réponse à Patrick Raynal seuls les solutions 3 et 4 sont
réellement viables pour un annuaire à la fois dynamique (évolutif) et on
va dire supérieur à 100 contacts.
Tout dépend en fait de la réactivité et de la taille de ton annuaire
....
On va dire 1 annuaire avec moins de 100 noms et 10 modif par mois :
solution 1 ou 2
Plus d'1 annuaire ou plus de 100 noms ou plus de 10 modifs par mois
: solution 3 ou 4
Moi je choisirai sans hésitation la solution 4.
Un peu plus sur les annuaires :
Les aléas des solutions :
*Problèmes liés à la mises à jours des données :
- Excell et très limité pour la gestion de données,
l'interface sera limité, et tu ne pourra pas simplifier tes mises à
jour, tant qu'à rester chez microsoft passe à Access : l'intérêt d'une
base de donnée
- L'évolution de ces logiciels, t'obligera à faire évoluer
l'interface de saisie (si tu en fais une)
- etc ...
*Problèmes liés à la mises à jour de tes structures de données
- Tes scripts seront à faire évoluer avec toute évolution de
la structure de tes données ... ca arrivera plus vite que tu ne le
penses.
- etc ...
*Problèmes inhérent au concept d'annuaire
- Un annuaire de par son indépendance aux autres systèmes est
assurément faux, l'objectif étant d'avoir un pourcentage d'erreur le
plus faible possible d'où le besoin de réactivité.
- Les données d'un annuaire sont la clef de voûte des réseaux,
or tu veux mettre ton annuaire sur une réseau non ?
Je m'explique : Qu'il t'arrive de vouloir gérer tes rendez-vous avec ces
gens là, de leur téléphoner, de leur envoyer un email, enfin toute
application réseau qui peut avoir besoin d'information individuelle doit
pouvoir accéder à ces données ... Ce n'est pas un idéal et encore moins
un rêve
Bon je ne vais pas pouvoir rester plus longtemps,
Des voies à explorer : e-directory, open-LDAP, active directory, PHP et
LDAP .... ect ....
"Bruno Desthuilliers" <bdesth.nospam@perso.free.fr> a écrit dans le
message de news: 3F0D4F83.8070205@removeme.free.fr...
Ramunt wrote:
Et la quatrième : LDAP ?
Heu... Vu les besoins de l'OP, je ne suis pas sûr que ce soit la
réponse
la plus adaptée... Ce n'est pas parce qu'il y a le mot 'annuaire'
qu'il
Heu comparé à la solution n° trois, .... je ne sais pas pourquoi celle là serait plus lourde ??? (voir PHP et LDAP ....)
Par contre en réponse à Patrick Raynal seuls les solutions 3 et 4 sont réellement viables pour un annuaire à la fois dynamique (évolutif) et on va dire supérieur à 100 contacts. Tout dépend en fait de la réactivité et de la taille de ton annuaire .... On va dire 1 annuaire avec moins de 100 noms et 10 modif par mois : solution 1 ou 2 Plus d'1 annuaire ou plus de 100 noms ou plus de 10 modifs par mois : solution 3 ou 4 Moi je choisirai sans hésitation la solution 4.
Un peu plus sur les annuaires :
Les aléas des solutions : *Problèmes liés à la mises à jours des données : - Excell et très limité pour la gestion de données, l'interface sera limité, et tu ne pourra pas simplifier tes mises à jour, tant qu'à rester chez microsoft passe à Access : l'intérêt d'une base de donnée - L'évolution de ces logiciels, t'obligera à faire évoluer l'interface de saisie (si tu en fais une) - etc ... *Problèmes liés à la mises à jour de tes structures de données - Tes scripts seront à faire évoluer avec toute évolution de la structure de tes données ... ca arrivera plus vite que tu ne le penses. - etc ... *Problèmes inhérent au concept d'annuaire - Un annuaire de par son indépendance aux autres systèmes est assurément faux, l'objectif étant d'avoir un pourcentage d'erreur le plus faible possible d'où le besoin de réactivité. - Les données d'un annuaire sont la clef de voûte des réseaux, or tu veux mettre ton annuaire sur une réseau non ?
Je m'explique : Qu'il t'arrive de vouloir gérer tes rendez-vous avec ces gens là, de leur téléphoner, de leur envoyer un email, enfin toute application réseau qui peut avoir besoin d'information individuelle doit pouvoir accéder à ces données ... Ce n'est pas un idéal et encore moins un rêve
Bon je ne vais pas pouvoir rester plus longtemps,
Des voies à explorer : e-directory, open-LDAP, active directory, PHP et LDAP .... ect ....
"Bruno Desthuilliers" a écrit dans le message de news:
Ramunt wrote:
Et la quatrième : LDAP ?
Heu... Vu les besoins de l'OP, je ne suis pas sûr que ce soit la réponse
la plus adaptée... Ce n'est pas parce qu'il y a le mot 'annuaire' qu'il
faut tout de suite sortir l'artillerie lourde !-)
Bruno
Bertrand Mollinier Toublet
Bruno Desthuilliers wrote:
Ramunt wrote:
Et la quatrième : LDAP ?
Heu... Vu les besoins de l'OP, je ne suis pas sûr que ce soit la réponse la plus adaptée... Ce n'est pas parce qu'il y a le mot 'annuaire' qu'il faut tout de suite sortir l'artillerie lourde !-)
Ca me parait un peu gonfle de traiter LDAP d'artillerie lourde en
comparaison a MySQL... Dans des conditions de deploiement simples (un seul serveur, par exemple...), LDAP n'est jamais qu'un serveur de base de donnees specialise annuaire.
La vraie artillerie lourde, c'est X500 ;-)
-- Bertrand Mollinier Toublet "Reality exists" - Richard Heathfield, 1 July 2003
Bruno Desthuilliers wrote:
Ramunt wrote:
Et la quatrième : LDAP ?
Heu... Vu les besoins de l'OP, je ne suis pas sûr que ce soit la réponse
la plus adaptée... Ce n'est pas parce qu'il y a le mot 'annuaire' qu'il
faut tout de suite sortir l'artillerie lourde !-)
Ca me parait un peu gonfle de traiter LDAP d'artillerie lourde en
comparaison a MySQL... Dans des conditions de deploiement simples (un
seul serveur, par exemple...), LDAP n'est jamais qu'un serveur de base
de donnees specialise annuaire.
La vraie artillerie lourde, c'est X500 ;-)
--
Bertrand Mollinier Toublet
"Reality exists" - Richard Heathfield, 1 July 2003
Heu... Vu les besoins de l'OP, je ne suis pas sûr que ce soit la réponse la plus adaptée... Ce n'est pas parce qu'il y a le mot 'annuaire' qu'il faut tout de suite sortir l'artillerie lourde !-)
Ca me parait un peu gonfle de traiter LDAP d'artillerie lourde en
comparaison a MySQL... Dans des conditions de deploiement simples (un seul serveur, par exemple...), LDAP n'est jamais qu'un serveur de base de donnees specialise annuaire.
La vraie artillerie lourde, c'est X500 ;-)
-- Bertrand Mollinier Toublet "Reality exists" - Richard Heathfield, 1 July 2003