Commentaires

Envoyé par Dendrite

Oui bien sûr.
Pose ton problème ici.

Bonjour Dentrite, je voudrais une vue admin qui permets d'ajouter des utilisateurs et de leurs assignés des heures de début et de fin.
et une vue utilisateur qui permet voir et de modifier les heures en cas de dépassement.
Merci

Oui bien sûr.
Pose ton problème ici.

Bonjour Dentrite,
étant débutant en php, pourrais-tu m'aiguiller pour la construction des vues pour l'utilisateur.
en te remerciant.

Ravie que ça serve !

Extrêmement intéressant.
Merci

Bonjour Cicillo et merci de ton retour.
Je vais tenir compte de tes remarques sur quelques points "Préciser tout de suite que le script s'appelle contact.php" ou "Préciser où l'on colle le SQL"...
Pour le reste, ce tuto ne s'adresse pas spécialement aux grands débutants que tu sembles être en PHP-MYSQL, tu as raison, ce tuto essaie de s'adresser à un peu tout le monde. Sur mon blog, je me fais un peu plaisir et je ne reviens pas sempiternellement sur les bases supposées acquises. Beaucoup de gens ont déjà une bonne habitude de développement avec d'autres librairies PHP d'accès aux bases, et surtout l'extension "mysql_" et veulent passer facilement à PDO. J'avoue que c'est d'abord à eux que j'ai pensé. Ce n'est pas une initiation à SQL pour les novices. C'est surtout une initiation simplifiée à PDO.

Ceci dit, quand je modifierai mon chapitre base de données dans "PHP pour grands débutants pressés", je le simplifierai encore et encore en tenant compte de tes remarques. Et notamment, je séparerai l'initiation à SQL et l'initiation à PDO. Mais pas sur ce billet.
Bonne continuation !

Bonjour, dialogues entre connaisseurs... Moi je rame. Vous vous comprenez au quart de tour et le tuto semble écrit pour des initiés. Par exemple, il faut deviner qu'à un moment donné on parle de contacts.php à créer mais sans le nommer. Il faut s'imaginer qu'il y a une table à créer. Autre exemple, un peu avant les contacts (je crois), il y a un code où l'utilisateur (du tuto) doit le copier-coller après avoir créé la DB. Mais le coller où? Par la suite le bouts de codes m'apparaissent comme des électrons libres... Ils sont reliées par quoi, quelle logique, quel(s) cas? Il manque des exemples.

Je termine sur un point positif. Ce tuto permet de se poser beaucoup de questions bien formulées par ses divers entêtes de chapitres. C'est bien bien que d'aller à la pêche d'infos sans savoir exactement quoi chercher. Merci.

Salve Dendrite,

Il n’est pas évident de crapahuter dans la foultitude des blogs DVP, aussi serait-il préférable que vous entamiez une discussion dans le forum Schema en ce qui concerne la partie modélisation. Une question concernant la date de décès : comment faites-vous le distinguo entre « encore en vie » et « mort, mais à une date inconnue » ?

En tout cas, bon courage, keep up the good work

Merci messieurs... Je vais étudier tout ça !

edit :

Je me suis régalée avec vos lectures subversives ! Encore merci...
Je laisse reposer tout ça (et accessoirement, je vais un peu gagner ma croûte), et je refais tout !
1) Je modélise en prenant mon temps (fil famille Bach mais un chouia plus simple, car je ne me soucie pas de légitime vs naturel). Je partirai plutôt sur une table personne, une table enfant_bio (lapsus révélateur, j'avais d'abord mis enfant_naturel car quoi de plus naturel que le bio lol), une table enfant_adopte (non, je n'ai pas dit enfant_industriel)... Et bravo fsmrel pour cette phrase mythique pour moi :
Jean-Sébastien Bach a bien été enfant avant de devenir papa à son tour. Ça sent l'héritage (au sens merisien du terme !)
@cinephil : que signifie psp dans ta conception ? ayé, j'ai trouvé personne_succede_personne... je réfléchis, mais succéder ne me convient guère. herite_de me paraît plus approprié, et c'est pas David et Laura qui vont me contredire.
Mais j'aime l'idée de ton nommage merisien : personne, p_hb_p et p_ha_p (personne herite biologiquement de personne et personne herite adoptivement)...
Mais pour le cas qui nous occupe, je vais laisser le nommage simple
personne(id,nom,prenom,naissance, deces)
enfant_bio(id,enfant_id, parent_id) (papa + maman = 2 lignes)
enfant_adopte(id, enfant_id, parent_id, debut) //j'imagine qu'il n'y a pas de fin pour un enfant adopté, on ne peut pas le renier mais il n'y a pas que la France... ? Bref, j'hésite encore...

Question subsidiaire :
C'est pas bien de mettre dans la table personne nom_naissance + nom_usage ?
Faut mettre nom dans personne, et faire une table pour nom_usage de ce genre :
nom_usage(id, personne_id, nom, debut, fin) ?

Question sub-subsidiaire :
deces est nullable... mais à terme sauf surprise, on sera tous morts un jour (c'est nous qui sommes nullables en quelque sorte lol triste)... donc c'est pas aberrant de mettre deces à nullable dans le cas qui nous occupe, vu notre passage furtif de quelques décennies au mieux ?

Question sub-sub-subsidiaire :
Si je souhaitais consigner le lien éventuel des personnes, je pourrais faire ça ?
n_lien (id, libelle, debut, fin) //nomenclature des PACS + mariage1 (avant) + mariage2 (pour tous)... mais il n'y a pas que la France...
lien (id, pers1_id, pers2_id, n_lien_id, debut, fin)

Nous sommes d'accord que j'ajoute les triggers qui vont bien quand j'ai tout fini...
Première ébauche

table enfant_bio

1) les 2 parents ne sont pas la mm personne => unicite sur enfant_id + parent_id

2) le parent est né un certain nombre d'années avant l'enfant (arf, combien...)
si je me fie à la biologie, les plus jeunes parents au monde répertoriés avaient genre 11 ans... Mais on est hors-sujet pas vrai ? SQL n'est pas là pour prédire la biologie... Alors je vais me contenter de ça : trigger => vérifier que parent_age n'est pas <= à enfant_age... c'est la seule contrainte absolue...

3) l'enfant n'est pas deja son propre parent ou soi => trigger sur enfant_id n'est pas dans sa propre ascendance (ça va être chaud ça, sans récursivité !!!)

table enfant_adoptif

1) idem

2) quelque chose interdit à quelqu'un de 30 ans d'adopter quelqu'un de 60 ??? Je n'en suis pas certaine... Et quand bien même, les lois peuvent changer, et il n'y a pas que la France.

3) le parent adoptif n'est pas déjà le parent biologique ?

2) Mysql 8... n'est pas monté en kit sur Phpmyadmin... vivement ! car ma requête récursive ne demande plus qu'à être testée...

3) par souci de clarté, je ferai un autre billet de blog, "Roland Marci : l'Empire contre-attaque !"... Oh, non, mieux encore "Plus SQL la vie !"

A bientôt, ne partez pas trop loin, je vais avoir bientôt besoin de vous...

Comme l’a précisé CinePhil, le principe de base de la filiation passe par la modélisation d’une entité-type E et d’une association A dont les pattes sont branchées sur E. Au niveau tabulaire, E et A font l’objet de tables.

Par exemple, dans la discussion avec Darkaurora, les pièces (table PIECE) sont composées de pièces qui sont composées de pièces, ad libitum (table COMPOSITION).


Les structures arborescentes ne sont pas limitées aux hiérarchise simples, mais peuvent composer des graphes, des « forêts ».

On peut développer le sujet à volonté, en prenant l’exemple de la famille Bach, laquelle est sujette à des situations parfois compliquées...

Comme le précise encore CinePhil, il y a un certain nombre de contraintes à mettre en place ; ajoutons par exemple qu’il faut interdire qu’un enfant soit son propre parent ou plus généralement un de ses ascendant (sinon c’est parti pour les boucles infinies...)

Voir aussi « La demande en mariage », avec Jacqueline Maillan et Francis Blanche).

Bonjour Dendrite.

Je n'ai pas lu en détail ton billet, notamment sur la partie PHP, mais je souhaite souligner 2 choses...

1) Les requêtes récursives sont apparemment possibles dans MySQL 8.
Mais n'étant pas habitué à l'utilisation des CTE, je ne m'aventure pas plus loin pour donner la solution ; je laisse ça aux spécialistes de PostgreSQL, SQL Server, Oracle ou DB2.

2) En toute rigueur, tu ne devrais pas avoir qu'une table.

Règle de gestion :
Une personne peut avoir de zéro à deux parents et une personne peut être parente de plusieurs personnes.

MCD :
Personne -0,2----succéder
|-------------0,n---------|

Tables :
te_personne_prs (prs_id, prs_nom, prs_prenom, prs_date_naissance, prs_date_deces...)
tj_prs_succeder_prs_psp (psp_id_enfant, psp_id_parent)

Notas :
a) Si on ne veut enregistrer que les parents biologiques, il faut de plus mettre en oeuvre une contrainte imposant maxi 2 parents, donc 2 lignes maxi dans tj_prs_succeder_prs_psp pour chaque psp_id_enfant.
b) Il faut aussi mettre en contrainte que les deux parents ne soient pas la même personne.
c) Une contrainte sur l'âge du parent par rapport à l'enfant est également souhaitable.
d) Si on veut enregistrer les parents adoptifs, il vaut mieux envisager une autre table similaire à tj_prs_succeder_prs_psp avec les dates de début et de fin d'adoption et mettre en oeuvre les contraintes nécessaires au non chevauchement des périodes.

Puisque tu m'as aidé dans cette problématique, je te remercie de m'avoir éclairé sur la récursivité et aussi de nous faire part de ton expérience sur ses applications.
Je ne savais pas non plus qu'il était possible de faire une auto-jointure sur une table.

Bonjour rawsrc. Ok, merci du conseil. Je corrige pour ce billet.

Salut Dendrite,

juste un conseil, perd l'habitue de fermer tes fichiers.php avec le ?> final.

Quand un fichier ne contient que du PHP, tu l'ouvres juste avec <?php et c'est tout.

Au moins t'es sûr de ne pas avoir à chercher ou pourraient apparaître des espaces intempestifs et autres joyeusetés du même acabit.

Merci de m'avoir cité dans les remerciements !

J'ai tout lu. Néanmoins, je n'ai pas accroché sur le chapitre "introduction". Drôle de façon de présenter PDO. Pour moi c'est un gestionnaire de base de données, qui permet de faire abstraction du SGBD et je n'ai pas du tout retrouvé ça dans ton introduction.

A part ça, très intéressant. Personnellement, comme toi, toutes mes requêtes sont préparées, même si ça sert à rien (une seule méthode pour tout faire) ; par contre, je n'utilise que des marqueurs nommés pour plus de clarté.

Ah oui, je réponds aussi à ceci. Willy dit à juste titre que les ';' ne sont pas obligatoires. On parle bien sûr des ';' du SQL.
Pour la bonne raison que PDO ne gère qu'une instruction SQL à la fois.
Si vous souhaitiez créer une table puis la remplir via une requête PDO, vous ne pourriez pas mettre ces 2 instructions dans votre requête. Vous seriez obligé de passer par 2 instructions PDO différentes.

Code SQL :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
CREATE TABLE IF NOT EXISTS `contact` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `nom` varchar(100) NOT NULL,
  `prenom` varchar(100) NOT NULL,
  `mail` varchar(200) NOT NULL,
  PRIMARY KEY (`id`),
  KEY `nom` (`nom`)
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8;
 
INSERT INTO `contact` (`id`, `nom`, `prenom`, `mail`) VALUES
(1, 'ACCOYER', 'Alain', 'alain.accoyer@gmail.com'),
(2, 'BRABOIS', 'Bernard', 'bbrabois@yahoo.fr'),
(3, 'CHAZAL', 'Claire', 'chaz@wanadoo.fr'),
(4, 'DENDRITE', 'Daisy', 'dendy@gmail.com'),
(5, 'CHAZAL', 'Etienne', 'chazet@gmail.com'),
(6, 'CHAZAL', 'Chantal', 'chacha@monfai.fr'),
(7, 'CHAZAL', 'Kevin', 'kevcha@noos.fr'),
(8, 'ZANZIBAR', 'Zoé', 'zanzo@orange.ocm'),
(9, 'CASERATI', 'Michel', 'michoucase@voila.fr'),
(10, 'FRIPON', 'Françoise', 'francoise.fripon@gmail.com');

Le problème des débutants, c'est qu'ils ne préparent JAMAIS les requêtes quand il le faut. Alors je fais simple. Je leur montre comment TOUJOURS préparer leurs requêtes. Ca manque totalement de nuances ? M'en fous. C'est PDO une soupe et au lit. Pour les nuances, on laisse ici, en commentaire... Donc pour ceux que ça intéresse, Willy a raison.
Pour le chapitre 5, sans filtre, et celui-là seulement, pas de risque d'injection SQL ! on peut donc se passer de requête préparée, et gagner une ligne.
en remplaçant

Code PHP :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
$stmt = $db->prepare($sql);
$stmt ->execute();

par

Code PHP :

Sélectionner tout - Visualiser dans une fenêtre à part

$stmt = $db->query($sql);

Sans filtre, il n y a vraiment aucun gain à préparer la requête, query aurait suffit, et les ; ne sont pas obligatoires.

Ok willy. Merci, c'est corrigé.

Il est marqué

Ci-dessous les exemples qui démontrent la façon de modifier proprement le jeu de caractères lors de l'exécution en utilisant chacune des APIs.

Comme un conseil, non ?