selectionner differentes base de donnees via php - une aide SVP!

"alcina" <alcina@kurbis.org> wrote in message
news:0001HW.C242F20D00092542F0284530@text.giganews.com...

bonjour à tous, j¹ai besoin d¹un coup de main pour démarrer et j¹espère
dans
vos conseils. :-)
J¹ai plusieurs base de données MySQL sur mon site web, une base de données
pour chaque Pays.
J¹ai un form de recherche, où je voudrais mettre un menu déroulant pour
sélectionner le Pays, et donc (selon moi) la base de données.
Mais l¹ami avec lequel je suis en train de créer le site pense que ne soit
pas possible...
le crois que oui bien que je ne sais pas encore comment :-) !
Quelqu¹un pourrait gentiment m¹aider à résoudre le dilemme? peut-être
aussi
en me donnant quelques liens utiles?
Merci d¹avance!
ciao, :-)
alcina

http://www.asar.com/cgi-bin/product.pl?58/hogwasher.html

Bonsoir,

Rien ne t'empêche en effet de choisir (dans ton code PHP) la base sur
laquelle tu souhaites travailler, tout comme rien ne t'empêche de choisir le
serveur sur lequel tu souhaites travailler.

Dans le fichier de configuration php.ini, on peut spécifier le serveur MySQL
sur lequel on souhaite travailler par défaut, mais rien n'empêche d'en
utiliser un autre. C'est peut-être la confusion de ton ami.

Quelques pistes:
Pour spécifier le serveur MySQL auquel on souhaite se connecter, on utiliser
la fonction mysql_connect ($server, $username, $password)
Pour spécifier la base du serveur sur laquelle on souhaite travailler, on
utilise la fonction mysql_select_db ($db_name)

Tu trouveras le détail des paramètres et des explications sur ces fonctions
ici:
http://fr.php.net/manual/fr/ref.mysql.php (la liste des
fonctions/constantes... relatives MySQL sur PHP)
http://fr.php.net/manual/fr/function.mysql-connect.php (l'aide sur la
fonction mysql_connect)
http://fr.php.net/manual/fr/function.mysql-select-db.php (l'aide sur la
fonction mysql_select_db)

En esperant t'avoir aidé ou guidé,
Antoine.

bonjour à tous, j¹ai besoin d¹un coup de main pour démarrer et j¹espère dans
vos conseils. :-)
J¹ai plusieurs base de données MySQL sur mon site web, une base de données
pour chaque Pays.

??? Ca me semble un poil tordu comme conception. Je ne suis pas sûr de
comprendre s'il s'agit d'internationalisation (même contenu dans
différentes langues), ou d'un même schéma utilisé pour stocker des
informations similaires concernant différents pays, mais dans les deux
cas (ie : même schéma de données quelque soit la langue/le pays), je ne
vois pas le besoin d'avoir plusieurs *bases* pour gérer ça - il suffit
d'avoir une table "pays" (ou 'langue'), et de lier les autres tables, ie:

pays(*code_pays*, nom_pays)
ville(*id_ville*, nom_ville, _code_pays_)

J¹ai un form de recherche, où je voudrais mettre un menu déroulant pour
sélectionner le Pays, et donc (selon moi) la base de données.
Mais l¹ami avec lequel je suis en train de créer le site pense que ne soit
pas possible...

De "mettre la base de données dans le formulaire", effectivement, ça me
parait délicat !-)

De lister les bases auxquels tu a accès, et de sélectionner la base à
utiliser en fonction du choix du pays, c'est of course techniquement
possible (enfin, selon les droits que tu a sur le serveur MySQL pour ce
qui concerne le fait de lister les bases, mais techniquement on peut
faire sans), mais en tout état de cause une erreur de conception digne
du DailyWTF. Si ton appli doit gérer des infos sur différents pays,
l'entité "pays" s'impose d'elle même comme partie du schéma.

Le 11 Apr 2007 18:28:58 GMT, alcina <alcina@kurbis.org> écrivait dans
fr.comp.lang.php:

bonjour à tous, j¹ai besoin d¹un coup de main pour démarrer et j¹espère dans
vos conseils. :-)
J¹ai plusieurs base de données MySQL sur mon site web, une base de données
pour chaque Pays.
J¹ai un form de recherche, où je voudrais mettre un menu déroulant pour
sélectionner le Pays, et donc (selon moi) la base de données.
Mais l¹ami avec lequel je suis en train de créer le site pense que ne soit
pas possible...

Il faut d'abord faire attention aux termes.

Une "base", en mySQL, c'est un ensemble de tables identifié par un
nom de serveur (le 1er argument de mysql_connect). Certains
hébergeurs limitent à 1, 2, 3, etc. "bases". Il se peut donc que
l'hébergeur en question ait cette limitation. Mon ancien l'avait
mais pas mon actuel.

Une "table" est une entité avec un certain nombre de lignes et de
colonnes (ou d'enregistrements ayant chacun une série précise
de champs).

Personnellement, je trouve que c'est une mauvaise idée d'avoir un
nom de serveur par pays. Même une base par pays est une mauvaise
idée si chaque pays a les mêmes paramêtres. Par contre, si chaque
pays a des champs qui lui sont propres (les noms d'endroits dans
les langues locales par exemple), c'est mieux d'avoir une table
par pays, encore que cela complique le code pour rien. Cela dépend
de l'ensemble du projet, bien sûr, puisqu'on peut faire une table
de traduction qui choisirait les champs propres à un pays.


Denis

P.S. Ce fil devrait se trouver sous news:fr.comp.applications.sgbd

On Thu, 12 Apr 2007 00:05:41 +0200, Bruno Desthuilliers wrote
(in article <461d3df9$0$24672$426a74cc@news.free.fr>):

bonjour à tous, j¹ai besoin d¹un coup de main pour démarrer et j¹espère
dans
vos conseils. :-)
J¹ai plusieurs base de données MySQL sur mon site web, une base de données
pour chaque Pays.

??? Ca me semble un poil tordu comme conception. Je ne suis pas sûr de
comprendre s'il s'agit d'internationalisation (même contenu dans
différentes langues), ou d'un même schéma utilisé pour stocker des
informations similaires concernant différents pays, mais dans les deux
cas (ie : même schéma de données quelque soit la langue/le pays), je ne
vois pas le besoin d'avoir plusieurs *bases* pour gérer ça - il suffit
d'avoir une table "pays" (ou 'langue'), et de lier les autres tables, ie:

pays(*code_pays*, nom_pays)
ville(*id_ville*, nom_ville, _code_pays_)

....des données différentes pour chaque Pays (hôtels cinema etc.)...

On avait choisi la formule ³plusieurs databases², un peu parce que les codes
qu¹on a trouvé n¹ont pas une norme internationale commune, mais propre à
chaque Pays, et un peu aussi pour avoir des bases de données plus petites.

J¹ai un form de recherche, où je voudrais mettre un menu déroulant pour
sélectionner le Pays, et donc (selon moi) la base de données.
Mais l¹ami avec lequel je suis en train de créer le site pense que ne soit
pas possible...

De "mettre la base de données dans le formulaire", effectivement, ça me
parait délicat !-)

:-) mais nooon!!! "sélectionner le Pays ET DONC SÉLECTIONNER la base de
données²
pas de la mettre toute dans le formulaire! :-)

De lister les bases auxquels tu a accès, et de sélectionner la base à
utiliser en fonction du choix du pays, c'est of course techniquement
possible (enfin, selon les droits que tu a sur le serveur MySQL pour ce
Pas de problèmes aux niveaux server & nombre de base...

qui concerne le fait de lister les bases, mais techniquement on peut
faire sans)
hem.... ???? une petite explication STP?

,> mais en tout état de cause une erreur de conception digne

du DailyWTF. Si ton appli doit gérer des infos sur différents pays,
l'entité "pays" s'impose d'elle même comme partie du schéma.

on est des amateurs... et en plus... débutants! sorry :-(
mais au moins on aura notre petite place sur le journal!
;-)

nous sommes en train de réfléchir sur ce que tu m¹as dit, merci Bruno,
Alcina



http://www.asar.com/cgi-bin/product.pl?58/hogwasher.html

On Thu, 12 Apr 2007 01:40:54 +0200, Denis Beauregard wrote
(in article <nhoq13h3r9bht3q83riljpkar70t1j8a4g@4ax.com>):

Le 11 Apr 2007 18:28:58 GMT, alcina <alcina@kurbis.org> écrivait dans
fr.comp.lang.php:

bonjour à tous, j¹ai besoin d¹un coup de main pour démarrer et j¹espère
dans
vos conseils. :-)
J¹ai plusieurs base de données MySQL sur mon site web, une base de données
pour chaque Pays.
J¹ai un form de recherche, où je voudrais mettre un menu déroulant pour
sélectionner le Pays, et donc (selon moi) la base de données.
Mais l¹ami avec lequel je suis en train de créer le site pense que ne soit
pas possible...

Il faut d'abord faire attention aux termes.

Une "base", en mySQL, c'est un ensemble de tables identifié par un
nom de serveur (le 1er argument de mysql_connect). Certains
hébergeurs limitent à 1, 2, 3, etc. "bases". Il se peut donc que
l'hébergeur en question ait cette limitation. Mon ancien l'avait
mais pas mon actuel.

Une "table" est une entité avec un certain nombre de lignes et de
colonnes (ou d'enregistrements ayant chacun une série précise
de champs).

hello Denis, merci déjà pour ta réponse! :)
Pas de problèmes aux niveaux serveur & nombre de bases...
Nous avons trouvé les codes des villes et villages mais les codes sont
différents pour chaque Pays; en plus nous voudrions stocker différentes
données pour chaque commune, hôtels cinéma etc. Nous avons donc plusieurs
tables, oui.

Personnellement, je trouve que c'est une mauvaise idée d'avoir un
nom de serveur par pays. Même une base par pays est une mauvaise
idée si chaque pays a les mêmes paramêtres. Par contre, si chaque
pays a des champs qui lui sont propres (les noms d'endroits dans
les langues locales par exemple), c'est mieux d'avoir une table
par pays, encore que cela complique le code pour rien. Cela dépend
de l'ensemble du projet, bien sûr, puisqu'on peut faire une table
de traduction qui choisirait les champs propres à un pays.

On a donc besoin peut-être pas d¹une base de données pour chaque Pays, Bruno
m¹a dit qu¹est une erreur monumentale, sigh, mais des tables différentes et
propres à chaque pays au moins... nous avons aussi un petit peu peur de nous
³perdre² dans une très grande base de données...

Denis

P.S. Ce fil devrait se trouver sous news:fr.comp.applications.sgbd

merci encore, je vais peut-etre encore profiter de votre gentillesse!
ciao,
alcina



http://www.asar.com/cgi-bin/product.pl?58/hogwasher.html

On Thu, 12 Apr 2007 01:40:54 +0200, Denis Beauregard wrote
(snip)

Personnellement, je trouve que c'est une mauvaise idée d'avoir un
nom de serveur par pays. Même une base par pays est une mauvaise
idée si chaque pays a les mêmes paramêtres. Par contre, si chaque
pays a des champs qui lui sont propres (les noms d'endroits dans
les langues locales par exemple), c'est mieux d'avoir une table
par pays, encore que cela complique le code pour rien. Cela dépend
de l'ensemble du projet, bien sûr, puisqu'on peut faire une table
de traduction qui choisirait les champs propres à un pays.

On a donc besoin peut-être pas d¹une base de données pour chaque Pays, Bruno
m¹a dit qu¹est une erreur monumentale, sigh, mais des tables différentes et
propres à chaque pays au moins...

Une autre approche (AMHA plus propre - au moins dans la théorie) est de
conserver des tables communes, et d'avoir en plus des tables contenant
des méta-données décrivant comment utiliser ces tables selon les pays.
C'est une approche certes un peu complexe, mais en ce qui me concerne je
commencerais par essayer de modéliser les choses dans cette optique,
quitte à décider au final que c'est ingérable - au moins, je saurais
pourquoi.

nous avons aussi un petit peu peur de nous
³perdre² dans une très grande base de données...

Pour mon premier boulot comme programmeur, j'ai hérité de la reprise
d'une appli avec environ 350 tables. Même pas peur !-)

On Thu, 12 Apr 2007 00:05:41 +0200, Bruno Desthuilliers wrote
(in article <461d3df9$0$24672$426a74cc@news.free.fr>):

bonjour à tous, j¹ai besoin d¹un coup de main pour démarrer et j¹espère
dans
vos conseils. :-)
J¹ai plusieurs base de données MySQL sur mon site web, une base de données
pour chaque Pays.

??? Ca me semble un poil tordu comme conception. Je ne suis pas sûr de
comprendre s'il s'agit d'internationalisation (même contenu dans
différentes langues), ou d'un même schéma utilisé pour stocker des
informations similaires concernant différents pays, mais dans les deux
cas (ie : même schéma de données quelque soit la langue/le pays), je ne
vois pas le besoin d'avoir plusieurs *bases* pour gérer ça - il suffit
d'avoir une table "pays" (ou 'langue'), et de lier les autres tables, ie:

pays(*code_pays*, nom_pays)
ville(*id_ville*, nom_ville, _code_pays_)

....des données différentes pour chaque Pays (hôtels cinema etc.)...
On avait choisi la formule ³plusieurs databases², un peu parce que les codes
qu¹on a trouvé n¹ont pas une norme internationale commune, mais propre à
chaque Pays,

Tu veux dire que pour une même entitée (hôtel, cinéma, etc), le schéma
varie selon les pays ? Bon, c'est quelque chose qui peut techiquement se
gérer dans une seule base, mais d'un point de vue pratique et compte
tenu des déficiences^Mlimitations de MySQL (en tous cas des versions <
5.x), ça peut effectivement justifier l'approche choisie.

et un peu aussi pour avoir des bases de données plus petites.

Là aussi, c'est discutable (entendre par là: ça peut se justifier dans
la pratique).

J¹ai un form de recherche, où je voudrais mettre un menu déroulant pour
sélectionner le Pays, et donc (selon moi) la base de données.
Mais l¹ami avec lequel je suis en train de créer le site pense que ne soit
pas possible...

De "mettre la base de données dans le formulaire", effectivement, ça me
parait délicat !-)

:-) mais nooon!!! "sélectionner le Pays ET DONC SÉLECTIONNER la base de
données²
pas de la mettre toute dans le formulaire! :-)

Désolé, pas pu résisté !-) C'est comme quand on me demande si "il y a
internet sur ta machine" !-)))

De lister les bases auxquels tu a accès, et de sélectionner la base à
utiliser en fonction du choix du pays, c'est of course techniquement
possible (enfin, selon les droits que tu a sur le serveur MySQL pour ce

Pas de problèmes aux niveaux server & nombre de base...

qui concerne le fait de lister les bases, mais techniquement on peut
faire sans)

hem.... ???? une petite explication STP?

Coder en dur les couples pays->base dans le script PHP.

,> mais en tout état de cause une erreur de conception digne

du DailyWTF. Si ton appli doit gérer des infos sur différents pays,
l'entité "pays" s'impose d'elle même comme partie du schéma.

on est des amateurs... et en plus... débutants! sorry :-(

Et moi un puriste, désolé aussi. Anyway, une bonne solution pratique
vaut mieux qu'une bonne solution théorique - en d'autres termes, une
vilaine verrue bien gérée vaut parfois mieux qu'une belle usine à gaz
ingérable.

Mais dans le domaine des modèles de données relationels, il est
généralement préférable de commencer par faire un MCD aussi propre que
possible. *Si* ce modèle s'avère ingérable - soit dans l'absolu, soit en
tenant compte des contraintes d'implémentation (limitations du SGBR par
exemple) et/ou d'exploitation (temps de réponse etc) -, *alors* on peut
justifier des solutions plus "pragmatiques".

En d'autres termes, le problème n'est pas tant de ne pas respecter la
règle que de savoir pourquoi on choisit de ne pas la respecter - ce qui
implique (entre autres) de connaitre la règle.

mais au moins on aura notre petite place sur le journal!
;-)

Pour l'utilisateur final, l'essentiel est que ça rende le service attendu.

nous sommes en train de réfléchir sur ce que tu m¹as dit, merci Bruno,

Merci à vous de l'avoir pris comme il convient.