Ses derniers messages sur les forums
peut être parle tu des conditions dans les requêtes ou des procédure stockée ?
À mon avis il s'embrouille. Il confond PHP et MySQL, en pensant que c'est un ensemble cohérent et atomique.
MySQL n'a rien a voir avec PHP.
PHP n'a rien à voir avec MySQL.
MySQL n'est pas obligatoire, il est utilisé habituellement pour assurer la persistance des donnés, mais ce n'est pas une obligation.
Je te conseille de jeter PHPMyAdmin, parce que cet outil entretien la confusion des genres (oui, aussi parce que je trouve que c'est un outil qui ne fait pas les chose comme je les attends, et donc mal ).
Pour accéder à ta base MySQL, utilises un outil en ligne de commande, avec la documentation de MySQL (sur le site officiel). Pour écrire mes scripts SQL (oui MySQL est un langage de scripting au final), j'utilises un éditeur de texte (vim mais tu peux apprendre emacs, je ne suis pas sectaire), comme ça, pour tester mes commandes je n'ai qu'à lancer ceci dans la ligne de commande :
mysql -hlocalhost -utest -pxxx test < mon_nouveau_script.sql
Je le fais pour tout : création de table, ajout d'utilisateurs MySQL, révocation ou octroie de droits d'accès, etc C'est bien plus pratique qu'une interface Web limitée.
Mais finalement, le mieux à ce moment c'est d'installer un Linux, installer les paquets, configurer Apache, PHP, MySQL, pour comprendre leurs fonctionnements. C'est long, difficile, mais l'expertise qu'en ressort vaut toutes les formations du monde.
Quand tu auras compris que cet ensemble ([WL]AMP) est en fait une agglomération de technologies indépendante, tu auras fait un grand pas.
Développeur récurrent, procédural et relationnel. Caustique soupe-au-lait.
Il est aussi possible d'utiliser DOMDocument et XPathEvaluator. Cependant, si le champ est renseigné par du javascript, c'est mort.
Développeur récurrent, procédural et relationnel. Caustique soupe-au-lait.
(cyne) Pourquoi parles-tu de tableur ?
Un graphique c'est un dessin produit à partir de données tabulaires (un tableau quoi).
Si tu ne veux pas te coltiner les calculs pénibles ou les changements de référentiels, il existe des bibliothèques comme Artichow qui font l'essentiel du boulot.
Développeur récurrent, procédural et relationnel. Caustique soupe-au-lait.
Tu peux toujours passer poser tes questions si tu es de passage. Nous sommes toujours ravis d'aider (dans la limite du stock de patience).
Mais si tu as un vrai projet qui peut faire l'objet d'une commercialisation, tu devrais surtout te focaliser sur ça plutôt que le développement. Il n'y a rien de pire pour un buisness que de se baser sur un logiciel codé par un débutant : c'est casse-gueule.
Développeur récurrent, procédural et relationnel. Caustique soupe-au-lait.
Remplace localhost par 127.0.0.1 (ou localhost.) : c'est un bogue connu de PHP.
MySQL supporte évidement les requêtes préparées, même avec update. Le système de requêtes préparées est une surcouche des requête, indépendamment de la sémantique de la requête).
Il est inutile, et même éventuellement dangereux d'échapper les données soumises à bindParam : le mécanisme de requêtes préparées le gère.
Pour la constante inconnue, je pencherais pour un include qui n'est pas vraiment inclus. Émets une erreur après la définition des constantes. Ça devrait nous dire si le fichier qui contient les définitions des constantes est vraiment interprété, ou non.
(Et j'aime pas PDO, comme ça c'est dit)
Développeur récurrent, procédural et relationnel. Caustique soupe-au-lait.
En tout cas, il y avait un gros sous-entendu :D
Pour les majuscule, c'est parce que je préfère, et que XHTML requiert les tags et attributs en minuscule. Les simples quotes, c'est une histoire de goût.
Je me doute que ça fonctionnait, deux chiffres pour l'année de naissance suffisent aussi.
Développeur récurrent, procédural et relationnel. Caustique soupe-au-lait.
Paradigme n'est pas un gros mot ;)
Tu n'as pas besoin de trois tables si la liste des chiens identifie des individus et qu'un chien ne peut que réclamer une race. Dans ce cas, tu as seulement besoin d'une clé étrangère nullable comme attribut d'un chien.
Si ton développement est un développement réel, il va falloir plus travailler le design de ta base. Le genre de question qu'il faut alors se poser, c'est : qu'est-ce qu'un chien ? Qu'est-ce qu'une race. Qu'est-ce qui rend un chien unique (son nom, son tatouage) ?
Et à partir de ces réponses tu peux commencer à concevoir correctement ta base, en appliquant des recettes simples.
Développeur récurrent, procédural et relationnel. Caustique soupe-au-lait.
Aucun des deux
Pour aller à l'essentiel, la page d'accueil n'est pas forcément la précédente, pour tout un tas de raison que je suis las d'évoquer. Du coup, tu dois nommer explicitement la page :
<a href='acceuil.php'>Up</a>
Quand à la bidouille javascript, tu brûlera en enfer pour avoir écrit une « URL Javascript » (ça n'existe pas dans les normes, ce sont des fossiles de ce qui se faisaient au tout début, dans l'antique Netscape Navigator.
Développeur récurrent, procédural et relationnel. Caustique soupe-au-lait.
Il faut comprendre le paradigme de base des bases de données relationnelles : l'algèbre relationnel. Tu devrais trouver des ressources sur le sujet assez facilement.
Ici la mal-nommée table « resume » est une table de jointure entre la table « animal » et la table « race ». Ceci gère la relation n..m entre les races de chien et les chiens individuellement... pour peu que les chiens puissent appartenir à plusieurs races.
Je ne suis pas convaincu par ton analyse.
En attenant, ce dont tu as besoin est :
select nom, nom_race as race
from animal join resume on animal.id_animal = resume.id_animal
join races on resume.id_race = race.idrace
Personnellement, j'aurais plutôt écrit quelque chose dans ce genre :
drop table if exists dogs, races ;
create table races
( id integer auto_increment
, name char(100) not null
, primary key (id)
) engine = innodb ;
create table dogs
( id integer auto_increment
, name char(100) not null
, race_id integer default null
, primary key (id)
, foreign key (race_id) references races(id)
) engine = innodb ;
insert into races (name) values
('Pékinois'), ('Caniche'), ('Chiwawa'), ('Boxer') ;
insert into dogs (name, race_id) values
('Gros bâtard', null), ('Dorothée', (select id from races where name = 'Caniche')) ;
Je te laisse deviner les requêtes de sélections qui vont bien ;)
Développeur récurrent, procédural et relationnel. Caustique soupe-au-lait.
Tu t'attaques là à un problème plus complexe qu'il n'y paraît. Analyser des phrases en langage naturel et en déduire leur sens est difficile, et prompt aux erreurs. Surtout si l'orthographe des phrases saisies est hasardeuse.
Créer un formulaire spécialisé serait plus simple dans un premier temps. Ensuite, si tu as le budget, tu pourras faire de la R&D ;)
Bien sûr tu peux toujours faire une interprétation basique, qui satisfera tes besoins. Comme repérer des chaînes, calculer des appoximations, etc.
Développeur récurrent, procédural et relationnel. Caustique soupe-au-lait.
