A partir de la minute 14:54, le texte est interprété avec une grande expérience en conception BDD, réflexe à acquérir pour les apprentis concepteurs. compteur de la 10ème commande gratuite choix de mémoriser paiements, état des paiements, moyens de paiements
Bonjour, merci pour votre message. Ce n'est pas obligatoire (pas explicitement demandé dans le sujet) mais vous pouvez effectivement mettre un lie relatif qui est tout à fait logique dans ce cas : les commandes sont alors numérotées par rapport aux clients.
@@E_mds oui, j'ai pensé à ça vu qu'ils sont identifier par rapport aux clients. Merci à vous pour ces vidéos Mme. et SVP j'ai cherché dans votre liste et j'ai pas trouvé le SQL ? est ce que vous avez un site ? ou un ouvrage à me conseiller pour comprendre le SQL ? Merci encore une fois
@@hamzaasfor3414 Sur ma chaîne, sur la page principale, vous trouverez une section "La programmation en SQL dans un SGBDR (cours, exercices)" qui contient des cours de programmation en SQL (triggers, curseurs, procédures stockées) et des exercices. En revanche, effectivement je n'ai pas fait de vidéos pour apprendre les bases du SQL (select...). Mais il y a plein de ressources sur Internet, des ressources gratuites, donc évitez d'acheter un livre.
Bonjour, merci beaucoup pour cette vidéo très instructive. Même si cela fait un moment que vous l'avez posté, il y a un détail qui m'intrigue : Pour la fidélisation, vous avez indiqué la gratuité sur la commande, pourtant de ce que je lis du besoin c'est juste la 10ème pizzas d'une série qui est gratuite et non la commande. En gros, cela veut dire que dans votre conception la 10 ème commande du client est gratuite et non la 10 ème pizza. Peut-être est-ce une erreur de ma part, d'après vous, Est-ce que mon raisonnement est juste ? Si oui, la gestion de la fidélisation me paraît beaucoup moins facile, le nombre de point peut être incrémenté par la quantité de pizza de chaque commande, par contre comment intégrer la gratuité d'une seule pizza de la commande ?
Je découvre votre message : je ne sais pas pourquoi, je ne recevais plus les notifications. Le fait de mettre "gratuite" dans pizza peut signifier que dans cette commande, le montant d'une pizza est décompté. Le sujet ne le précise pas, mais dans ce cas, cela pourrait être la moins cher.
10:13 ...Le prix d'une pizza dépend de la pizza choisie et de sa taille... Dans le cas (imaginaire) d'un prix sans ratio taille/variété, cette entité devenait indispensable pour connaître le prix de toutes les pizzas, n'est-ce-pas ?
11:52 'son adresse précise'. Comment stockez-vous l'adresse en cas d'exploitation pour du publipostage ? en cas de besoin de recherche précise par quartier ? Pour du publipostage, CiviliteNomPrenom, NumTypvoieNomvoie, CodPostNomville dans 3 champs ? Pour une recherche par quartier, entité adresse : écrire intégralement l'adresse dans un champ adresse ? ajouter un lien doublement relatif, avec les entités quartier et ville ? qui se transformeraient en 2 clef étrangères quartier, ville Dans combien de tables stocker une adresse sectionnée ? Faut-il un champ spécifique pour stocker le numéro de voie ?
Tout dépend la finesse de recherche que l'on souhaite. Si on a juste besoin de l'adresse complète en une fois (par exemple pour la transférer à une application gps), un seul champ suffit. Ensuite il est possible de décomposer plus ou moins, et effectivement de stocker les différentes couches de décomposition dans des tables différentes.
Merci ! Maintenant que je comprends le grand intérêt de stocker position GPS pour la précision, et libellé d'adresse complète pour la simplicité. La décomposition dans des tables différentes est tout de suite laborieuse !
![Blox Fruits Dragon Rework Update [Full Stream]](http://i.ytimg.com/vi/EqDAp8udhm0/mqdefault.jpg)
A partir de la minute 14:54, le texte est interprété avec une grande expérience en conception BDD, réflexe à acquérir pour les apprentis concepteurs.
compteur de la 10ème commande gratuite
choix de mémoriser paiements, état des paiements, moyens de paiements
Bonjour, Merci pour ces vidéos, SVP est-ce qu'on doit pas mettre un identifiant relatif entre client et commande ?
Bonjour, merci pour votre message. Ce n'est pas obligatoire (pas explicitement demandé dans le sujet) mais vous pouvez effectivement mettre un lie relatif qui est tout à fait logique dans ce cas : les commandes sont alors numérotées par rapport aux clients.
@@E_mds oui, j'ai pensé à ça vu qu'ils sont identifier par rapport aux clients. Merci à vous pour ces vidéos Mme. et SVP j'ai cherché dans votre liste et j'ai pas trouvé le SQL ? est ce que vous avez un site ? ou un ouvrage à me conseiller pour comprendre le SQL ?
Merci encore une fois
@@hamzaasfor3414 Sur ma chaîne, sur la page principale, vous trouverez une section "La programmation en SQL dans un SGBDR (cours, exercices)" qui contient des cours de programmation en SQL (triggers, curseurs, procédures stockées) et des exercices. En revanche, effectivement je n'ai pas fait de vidéos pour apprendre les bases du SQL (select...). Mais il y a plein de ressources sur Internet, des ressources gratuites, donc évitez d'acheter un livre.
@@E_mds D'accord, Merci beaucoup.
Bonjour, merci beaucoup pour cette vidéo très instructive. Même si cela fait un moment que vous l'avez posté, il y a un détail qui m'intrigue : Pour la fidélisation, vous avez indiqué la gratuité sur la commande, pourtant de ce que je lis du besoin c'est juste la 10ème pizzas d'une série qui est gratuite et non la commande. En gros, cela veut dire que dans votre conception la 10 ème commande du client est gratuite et non la 10 ème pizza. Peut-être est-ce une erreur de ma part, d'après vous, Est-ce que mon raisonnement est juste ?
Si oui, la gestion de la fidélisation me paraît beaucoup moins facile, le nombre de point peut être incrémenté par la quantité de pizza de chaque commande, par contre comment intégrer la gratuité d'une seule pizza de la commande ?
Je découvre votre message : je ne sais pas pourquoi, je ne recevais plus les notifications. Le fait de mettre "gratuite" dans pizza peut signifier que dans cette commande, le montant d'une pizza est décompté. Le sujet ne le précise pas, mais dans ce cas, cela pourrait être la moins cher.
10:13 ...Le prix d'une pizza dépend de la pizza choisie
et de sa taille...
Dans le cas (imaginaire) d'un prix
sans ratio taille/variété, cette entité
devenait indispensable pour connaître
le prix de toutes les pizzas, n'est-ce-pas ?
Il aurait fallu faire une association entre pizza et taille pour porter l'attribut prix.
11:52 'son adresse précise'.
Comment stockez-vous l'adresse
en cas d'exploitation pour du publipostage ?
en cas de besoin de recherche précise par quartier ?
Pour du publipostage,
CiviliteNomPrenom, NumTypvoieNomvoie, CodPostNomville dans 3 champs ?
Pour une recherche par quartier,
entité adresse : écrire intégralement l'adresse dans un champ adresse ?
ajouter un lien doublement relatif, avec les entités quartier et ville ?
qui se transformeraient en 2 clef étrangères quartier, ville
Dans combien de tables stocker une adresse sectionnée ?
Faut-il un champ spécifique pour stocker le numéro de voie ?
Tout dépend la finesse de recherche que l'on souhaite. Si on a juste besoin de l'adresse complète en une fois (par exemple pour la transférer à une application gps), un seul champ suffit. Ensuite il est possible de décomposer plus ou moins, et effectivement de stocker les différentes couches de décomposition dans des tables différentes.
Merci ! Maintenant que je comprends le grand intérêt de stocker position GPS pour la précision, et libellé d'adresse complète pour la simplicité. La décomposition dans des tables différentes est tout de suite laborieuse !