Je crée une base de données
je dois ajouter une zone Pourcentage
Pour moi elle fait 5 dont 2 c'est à dire 123,45
comment la definir en base ? " INT 5 "
Seconde question j'ai une zone à choix multipes
on peut choisir chien chat canard
l'un ou l'autre ou les trois ou deux
Comment me conseillez vous de mettre cela dans la base ?
Trois zone differentes ?
Pour la 2eme, c'est un peu plus compliquer, ça dépend également de ton utilisation futur (recherche sur ces champs et donc besoins de perfs ou pas) et de la quantité de donnée que tu as à traité...
en gros 2 solutions (pour moi):
- soit tes champs sont fixe et tu crée 3 champs dans ta base (en booléen ENUM('oui', 'non')). Si cette solutions est possible c'est sans doute la meilleur...
- Soit tu les stocks sous forme de chaine de caractère séparer par un caractère spécial (virgule ou point-virgule par exemple), mais cela nécessite un retraitement derrière. C'est plus souple, mais plus lent et plus compliquer...
Ceci est bien sur une solution perso, qui peut être sujet à débat, mais j'espère quelle t'aidera...
Tu détail tes valeurs, comme pour DECIMAL tu met "'oui', 'non'" DEFAULT 'non'
ou ce que tu veut en faite... MySQL (aux dernière nouvelle) ne gère pas les booléens mais les liste d'argument ENUM (tu peut donc en mettre plus que 2...
bien sur a la place de 'oui' et 'non' tu peut mettre ce que tu veut ('true', 'false', '0', '1', etc.) mais je croit que tu est obliger de mettre une chaine de caractères... (perso j'utilise toujours 'oui', 'non' dans ces cas là... je n'ai pas chercher plus loin )
Pour la deuxième question, non, la réponse de Miridan n'est pas bonne du tout. ENUM devrait à tout prix être évité, et on ne stocke pas plusieurs valeurs dans une même colonne.
La bonne méthode est une autre table qui contient l'id de la ligne et la valeur désirée (clé primaire composée). Tu n'as qu'à faire des jointures pour récupérer ce que tu souhaites.
- Lorsque tu veux modifier l'enum, tu es obligé de modifier la structure de la table. C'est franchement pas terrible.
- Tu es très limité dans la manipulation des données, on en arrive à des absurdités: http://www.siteduzero.com/forum-83-434 [...] html#r4064603
- Ce type de colonne n'existe que sur MySQL (en tout cas pas sur SQL Server par exemple).
C'est une bonne pratique (ils aiment bien ça les développeurs, les "bonnes pratiques") de l'éviter.
Créez une table avec les valeurs.
Cintre Sournois : effectivement, il me semble que les ENUM ne sont pas dans la norme SQL 2003.
Je ne suis cependant pas tout à fait convaincu par ton argumentation. Il me semble qu'il faut bien distinguer deux choses :
- les données de l'application, qui sont destinées à évoluer
- la définition des types de données, qui change peu au cours de la vie d'une application
Clairement, les ENUM sont un très mauvais choix dans le premier cas, et il faut évidemment utiliser une table. C'est ce que tu as montré dans le lien que tu donnes : une liste d'équipes de foot est une donnée de l'application destinée à évoluer. De même dans ce topic, pour les animaux, une table est adaptée.
Par contre, imagine que SQL ne propose pas le type "booléen". Est-ce que je peux définir un ENUM('true', 'false') ou je dois définir une table contenant deux lignes pour cela ? Il me semble que dans ce cas, un ENUM est parfaitement justifié : la définition des booléens ne fait pas partie du domaine de connaissance de la base, et n'est pas destinée à évoluer.
Il y a des cas où la distinction est moins nette. Dans le cas du booléen par exemple, on pourrait répondre (avec un brin de mauvaise fois) : « et si je veux passer à une logique trivaluée, 'vrai', 'faux', 'inconnu' ? ». La différence entre ce changement et l'ajout d'un animal ou d'une équipe de foot, c'est qu'elle demande une modification de l'ensemble de la logique de l'application : tous les opérateurs booléens sont à revoirs, tous les tests doivent maintenant gérer le cas 'inconnu', etc. Pour ces types, dont une modification entraîne forcément une modification de la partie logique/traitement de l'application, je pense qu'une ENUM est encore adaptée.
L'avantage des tables par rapport aux ENUM c'est qu'on profite des fonctionnalités habituelles des bases de donnée : recherche, jointure, etc.
L'avantage des ENUM c'est que comme ils sont considérés comme des types de données à part entière, on peut analyser les requêtes pour détecter par exemple de potentielles erreurs de typage : si j'écris SELECT foo FROM bar WHERE foobar = 'pasvrai', je reçois une erreur disant que 'pasvrai' n'est pas une valeur correcte de mon ENUM booléen.
Il me semble que dans ton cas (représentation par une table), même si le champ "foobar" est une clé étrangère qui pointe vers les valeurs de la table-enum, il n'y a pas d'erreur si je mets quelque chose n'appartenant pas à cette table.
Bref, j'ai l'impression que ça dépend des utilisations, mais qu'ENUM est parfois une bonne chose.
Quand je créée une base de données, je cherche le type de colonne qui convient pour chaque information.
Un booléen pour du true/false (1/0), de l'entier, du réel, des chaines de caractères, des années....
ENUM n'apporte rien. Ça ne sert un rien, si ce n'est se "simplifier" a priori la vie d'après certains.
Citation : bluestorm
Il me semble que dans ton cas (représentation par une table), même si le champ "foobar" est une clé étrangère qui pointe vers les valeurs de la table-enum, il n'y a pas d'erreur si je mets quelque chose n'appartenant pas à cette table.
Je pense que ce problème est en effet à prendre en compte et doit être laisser à l'appréciation du développeur !
Cintre Sournois, ta remarque est justifiée... Par rapport à la norme SQL et sans doute pour SQL Server...
En tant que développeur PHP / MySQL, j'ai tendance à ne penser que MySQL...
Chaque SGBD à ses particularité et ses avantages, et ça serait vraiment dommage de ne pas profité des avantages de chacun... Mais enfin, le sujet de la question n'était absolument pas les norme SQL et la compatibilité entre SGBD...
De ce fait, contrairement à la norme SQL, MySQL ne propose pas le type BOOLEEN, type de donnée qui me parait incontournable. Le Type ENUM prend avantageusement sa place... Et même si il n'est pas standard, il me semble que plusieurs SGBD le reconnaisses...
Par ailleurs le type ENUM est bien plus performant en terme de recherche que n'importe quel autre type (y compris un type INT). Il impose une structure fixe à la base de données et donc une plus grande sécurité de façon simple (sans avoir à mettre en place les clés étrangères et les différentes gestions qui peuvent s'y rapporter).
Par ailleurs, mon "conseil" portait sur une gestion booléenne sur des champs FIXES, les animaux ne sont que des exemples et je doute qu'ils soient réellement utiliser. Dans CE cas, je pense que l'ENUM (ou un type booléen sur un SGBD qui les acceptent) est le meilleur des choix...
S'il s'agissait réellement d'une liste de choix variable et modifiable au cour du temps, en effet, il vaudrait mieux le gérer en 3 tables avec clés étrangères, mais ICI, je ne croit pas que ça soit justifier, que ça alourdira la BDD, le développement et réduira inutilement les perfs...
De toute façon le plus important c'est que Hugo est pu faire ce qu'il voulait !
"ça alourdira la BDD, le développement et réduira inutilement les perfs"
Tout ça c'est des légendes....
Merci de définir ce que signifie "alourdire" une BDD, et "le développement".
En quoi ne pas utiliser ENUM "réduit" les "perfs" ?
PS : Je trouve ça déplorable que là où certain prennent du temps pour aider des débutant d'autres perdent du temps à critiquer les conseils des autres !!!
Citation : Cintre Sournois
Merci de définir ce que signifie "alourdire" une BDD, et "le développement".
En quoi ne pas utiliser ENUM "réduit" les "perfs" ?
Les ENUM, à ma connaissance de non expert des SGBD mais de développeur, sont stocker en dur sous forme binaire ! les "nom" des énuméré ne sont que des alias lors de la définition de la base :
- donc une valeur d'enum = 1 bit !
Si tu veut respecter les normes SQL tu stocke tes ID au minimum en smallint
- donc 1 ID = 16 bits
dans le cas d'un simple booléen :
- La méthode enum prend 2 bit 'true' et 'false'
- La méthode double table prend : 2xID = 32 bit + l'intitulé (9 caractères ~= 9*8 = 72 bits) plus la clé étrangère (3e ID) 16bit... Pour un total de 120 bits ! (Le calcul n'est sans aucun doute pas exacte mais l'idée et le résultat sont là, et vérifiable ! Et encore, je suis sûr que je suis bien en dessous de la réalité !)
Soit 60 fois plus de place utilisée avec la 2e méthode et autant (voir plus) de temps d'exécution !
Voilà pourquoi il vaut mieux utiliser (quand s'est possible) un type ENUM (ou un type booléen si dispo) plutôt que des tables différentes !
Alors bien sûr pour la place on parle de quelques octets et pour le temps de quelques dixième de millisecondes... Sur une table de quelques centaines d'enregistrement ou/et en local la différence est sans doute minime et imperceptible, mais sur plusieurs dizaines de milliers de ligne et sur Internet, croit moi que la différence tu la verra !!!
Voilà pour le "alourdir la BDD"... A noté que sur une BDD MySQL on parle en Ko et Mo... Contrairement à SQL Serveur et Oracle ou l'on parle en Go et To... De même qu'on utilise pas (forcement) de serveur dédiés avec MySQL contrairement à SQL Server et Oracle...
PS: Bien entendu on parle là de données fixes, booléennes ou très limités et connues dès l'étude du projet. Pour des données variables ou avec un grand nombre de choix on préfèrera la solutions des clés étrangère, fondement des SGBD... (même si "l'optimiseur" de table de MySQL conseille généralement de créer des ENUM avec des centaines de valeurs plutôt que un types caractères, par exemples)
Pour "le développement" :
Je parle là de la vérification, de la validation et de la récupération des données coté langage de programmation (PHP)... Car il est évident que, en production, quelque soit la base de donnée choisit et le système (enum ou non) on n'affiche JAMAIS des données brut de la BDD et on n'insère encore moins des données dans une BDD sans contrôle ! Or un contrôle sur une liste de champs fixe est sans aucun doute bien plus simple et rapide à faire qu'un contrôle sur une liste de champ "variable" récupérer de différentes table !
D'autres questions ?
PS : Maintenant si les argument de bluestorm et les miens de te conviennent pas, tu peut toujours aller en discuter sur les forum professionnels des SGBD ou tu trouvera sans doute des personnes plus calé dans le fonctionnement interne de ces derniers...
Cintre sournois > Comme je l'ai dit, dans certains cas ENUM permet plus de vérifications statiques et donc une programmation plus sûre. Contrairement à une table où "tout est possible", un ENUM indique clairement les possibilités au compilateur/intepréteur des requêtes/procédures/etc., qui peut vérifier que les types ENUM ne sont pas utilisés n'importe comment.
En échange, on sacrifie une certaine flexibilité, mais comme je l'ai déjà dit dans certains cas on n'en a pas besoin : types booléens, logique trivaluée, représentation de données, de protocoles, etc.
Miridan > un champ ENUM à plus de deux possibilités (c'est le cas du type booléen puisqu'il contient aussi NULL) prend forcément plus d'un bit de stockage. En pratique je doute que les BDDs gère des tailles de stockage en dessous de l'octet; d'après la documentation MySQL, un ENUM prend au minimum un octet d'espace.
Pour chaque ligne où le choix ENUM/clé se pose, tu utiliseras donc un octet avec un ENUM, contre 2 avec une clé étrangère comme le suggère Cintre Sournois; les autres coûts sont constants une fois le nombre de valeurs de l'ENUM fixé. La différence en mémoire n'est donc pas aussi grande que ce que tu dis : seulement un octet de plus (pour des lignes qui à priori en contiennent déjà un certain nombre).
Pour les performances, le coût est sans doute plus élevé, mais il faudrait faire des tests. De toute façon ça dépend des usages, mais souvent ce ne sera pas là que se joueront les performances de l'application (plutôt sur les grosses jointures etc.).
PS : Je trouve ça déplorable que là où certain prennent du temps pour aider des débutant d'autres perdent du temps à critiquer les conseils des autres !!!
Rien n'interdit de critiquer ce que disent les autres, si ça peut faire avancer les connaissances de la communauté.
Personnellement j'aime bien m'appuyer sur les faits, plutôt que les a priori.
Citation : Miridan
....
La réalité est tout autre.
Si tu t'intéresses à la documentation, tu verras qu'une valeur d'ENUM est stockée sur 1 (voir 2) bytes (à ne pas confondre avec les bits en français...), tout comme le type TINYINT (qui d'ailleurs sert à implémenter le type BOOLEAN de MySQL)
Citation : Miridan
(même si "l'optimiseur" de table de MySQL conseille généralement de créer des ENUM avec des centaines de valeurs plutôt que un types caractères, par exemples)
Où as-tu vu cela ?
Citation : Miridan
Pour "le développement" :
...
Car il est évident que, en production, quelque soit la base de donnée choisit et le système (enum ou non) on n'affiche JAMAIS des données brut de la BDD et on n'insère encore moins des données dans une BDD sans contrôle ! Or un contrôle sur une liste de champs fixe est sans aucun doute bien plus simple et rapide à faire qu'un contrôle sur une liste de champ "variable" récupérer de différentes table !
De quel genre de "contrôle" parles-tu, je ne voit pas ?
Citation : bluestorm
Cintre sournois > Comme je l'ai dit, dans certains cas ENUM permet plus de vérifications statiques et donc une programmation plus sûre. Contrairement à une table où "tout est possible", un ENUM indique clairement les possibilités au compilateur/intepréteur des requêtes/procédures/etc., qui peut vérifier que les types ENUM ne sont pas utilisés n'importe comment.
Je ne voit pas la différence avec une utilisation classique, FK + table de référence.
Moi en tout cas, je maitrise ce que l'on insère dans mes tables.
Citation : bluestorm
Pour les performances, le coût est sans doute plus élevé, mais il faudrait faire des tests.
La différence c'est que si j'écris du code (procédure stockée, requête paramétrée stockée, trigger) qui dit à un endroit "si la valeur du booléen est 'tru', tu renvoies 1, sinon tu renvoies 0", alors ma version me donnera une erreur au moment où le SGBD lira le code de ma procédure, alors qu'avec ta table il ne dira rien, et renverra toujours 0. Dans mon cas, une bête erreur de codage ('tru' au lieu de 'true') a été signalée et corrigée au moment du développement, dans ton cas elle se transforme en un comportement erroné qui ne lance pas d'erreur, et qu'on ne peut donc pas détecter avant qu'un autre code/résultat utilisant ce résultat renvoie des résultats aberrants lui aussi, ce qui garantit des erreurs plus graves et plus difficiles à corriger.
Rien n'interdit de critiquer ce que disent les autres, si ça peut faire avancer les connaissances de la communauté.
Personnellement j'aime bien m'appuyer sur les faits, plutôt que les a priori.
Au moins un point où nous somme d'accord Si ce n'est que je ne pense pas que ce soit l'endroit idéal...
Je te remercie cependant de tes lumières, j'avais zapper quelques nouveautés de MySQL 5 dont le type BOOLEEN... Je me coucherais donc moins bête ce soir
Comme j'aime bien également les choses concrètes et que mes dires précédent était essentiellement basés sur des choses que j'avais pu lire sur le web il y as un certain temps et sur mon expériences mais sans jamais vraiment l'avoir mesurer j'ai donc fait un petit tests simples :
2 Solutions : Solutions 1 avec 1 table et des ENUM
CREATE TABLE IF NOT EXISTS `mydb`.`enum_table` (
`id` SMALLINT UNSIGNED NOT NULL AUTO_INCREMENT ,
`nom` VARCHAR(50) NOT NULL ,
`chien` ENUM('oui', 'non') NOT NULL ,
`chat` ENUM('oui', 'non') NOT NULL ,
`canard` ENUM('oui', 'non') NOT NULL ,
PRIMARY KEY (`id`) ,
INDEX `chien` (`chien` ASC) ,
INDEX `chat` (`chat` ASC) ,
INDEX `canard` (`canard` ASC) )
ENGINE = InnoDB;
Solutions 2 avec 3 tables et des clés étrangères
CREATE TABLE IF NOT EXISTS `mydb`.`id_table` (
`id` SMALLINT UNSIGNED NOT NULL AUTO_INCREMENT ,
`nom` VARCHAR(50) NOT NULL ,
PRIMARY KEY (`id`) )
ENGINE = InnoDB;
-- -----------------------------------------------------
-- Table `mydb`.`liste_table`
-- -----------------------------------------------------
CREATE TABLE IF NOT EXISTS `mydb`.`liste_table` (
`id` SMALLINT UNSIGNED NOT NULL AUTO_INCREMENT ,
`nom` VARCHAR(50) NOT NULL ,
PRIMARY KEY (`id`) )
ENGINE = InnoDB;
-- -----------------------------------------------------
-- Table `mydb`.`join_table`
-- -----------------------------------------------------
CREATE TABLE IF NOT EXISTS `mydb`.`join_table` (
`id_nom` SMALLINT UNSIGNED NOT NULL ,
`id_type` SMALLINT UNSIGNED NOT NULL ,
PRIMARY KEY (`id_nom`, `id_type`) ,
INDEX `fk_id` (`id_nom` ASC) ,
INDEX `fk_type` (`id_type` ASC) ,
CONSTRAINT `fk_id`
FOREIGN KEY (`id_nom` )
REFERENCES `mydb`.`id_table` (`id` )
ON DELETE CASCADE
ON UPDATE CASCADE,
CONSTRAINT `fk_type`
FOREIGN KEY (`id_type` )
REFERENCES `mydb`.`liste_table` (`id` )
ON DELETE CASCADE
ON UPDATE CASCADE)
ENGINE = InnoDB;
Mes tests on portés sur :
- le temps d'insertion de 10 000 lignes
- Le poid final en base
- le temps de sélection des 10 000 lignes mais avec des contraintes
Insertion méthode 1 (avec PHP)
for($i=0; $i<10000; $i++) {
mysql_query('INSERT INTO enum_table SET nom = '.$i.', chien = "oui", canard = "oui"') or die(mysql_error());
}
Insertion méthode 2 (avec PHP)
for($i=0; $i<10000; $i++) {
mysql_query('INSERT INTO id_table SET nom = '.$i) or die(mysql_error());
$id = mysql_insert_id();
mysql_query('INSERT INTO join_table SET id_nom = '.$id.', id_type = 1') or die(mysql_error());
mysql_query('INSERT INTO join_table SET id_nom = '.$id.', id_type = 3') or die(mysql_error());
}
Verdict n°1 :
Simplicité => +1 pour ENUM => 1 requête contre 3
Temps (afficher depuis le script PHP par différences de microtime()) :
- Solution n°1 (ENUM) : 109 secondes (oui je trouve aussi que mon ordi est très lents )
- Solution n°2 : 351 secondes
Encore +1 pour ENUM avec 3 fois moins de temps...
Poids :
Solution n°1 : 672 ko
Solution n°2 : 304 + 944 + 16 = 1264 ko
(sachant que pour la solution n°1 le poids ne bougeras pas selon les données ENUM saisies contrairement à la table des jointures qui dépend des valeurs... ici j'ai 2 valeur sur 3 renseignées pour chaque ligne... nous pourrions donc supposer que le poids de la 2e table variera entre 1Ko (taille d'une table MySQL vide) et 1 415 ko (taille de la base avec les 3 valeurs renseignées... pour un totla en solution n° 2 de 1 735 ko
Verdict n°2 :
encore +1 pour ENUM... Même s'il est vrai que je me suis tromper et que ça n'est pas aussi flagrant que je le pensais, ENUM s'en sort avec un poids moitié moins élevé que la solution clés étrangères
Et enfin le plus intéressant... la sélection...
Requêtes (encore une fois peut-être y-a-t'il plus optimiser ?) :
Solution n°1 :
SELECT *
FROM `enum_table`
WHERE `chien` = 'oui'
AND `chat` = 'oui'
AND `canard` = 'non'
Solution n°2 :
SELECT *
FROM `id_table`
WHERE `id` IN (
SELECT id_nom
FROM join_table
WHERE id_type =1
)
AND `id` IN (
SELECT id_nom
FROM join_table
WHERE id_type =2
)
AND `id` NOT IN (
SELECT id_nom
FROM join_table
WHERE id_type =3
)
Verdict n°3 :
Là encore +1 pour ENUM pour la simplicité 1 requête simple contre 1 avec 3 sous-requêtes
Question temps :
Solutions n°1 : 0.0004s ou 0.4 ms
Solution n°2 : 0.0573s ou 57.3 ms
Je croit que ça fait encore +1 pour ENUM avec un temps approximativement 100 fois inférieure
Verdict final :
5 / 0 pour ENUM
(Et là je suis en local, sur mon PC perso, etc. la différence devrait être encore plus flagrante en ligne... mais là j'ai la flemme de tester)
Question SECU, le coté debuggage est simplifier comme l'explique bluestorm, mais jeparle bien d'avantage des contrôle de formulaire... De tester ce que l'utilisateur à saisi afin de ne pas mettre n'importe quoi dans la BDD... Et là si tu ne voit pas de quoi je parle, je vais vraiment me demander si tu as déjà fait une appli web et si tu sait de quoi tu parle EN REEL, (et pas seulement par des théorie scolaires)... Mais bon je suis sûr que tu as les notions de sécurité nécessaires et que tu contrôle tout tes champs
Sur ce, je ne sait pas pour vous mais moi je vais continuer à utiliser les ENUM quand celà est possible
Écoute, c'est certainement très intéressant mais je n'ai même pas besoin de descendre à ce niveau.
Les "solution 1" et "solution 2" ne sont tout simplement pas équivalentes.
La "solution 1" est tout simplement une erreur de conception.
Je ne sait pas si tu as déjà pratiqué la conception et notamment la réalisation de MCD, mais ça me semble évident.
Je ne comprend pas vraiment le sens de cette table d'ailleurs.
Disons que c'est une table des personnes, qui nous renseigne sur les animaux quelle aime ou pas (oui/non), tel personne n'aime que les chiens et les canards, etc...
Je reformule quand même, puisque id_table, join_table, etc.. ça ne me va pas.
SELECT *
FROM `id_table`
WHERE `id` IN (
SELECT id_nom
FROM join_table
WHERE id_type =1
)
AND `id` IN (
SELECT id_nom
FROM join_table
WHERE id_type =2
)
AND `id` NOT IN (
SELECT id_nom
FROM join_table
WHERE id_type =3
)
pourrait être écrite comme ceci (il y a plusieurs solutions):
select per_id, per_nom
from personne
natural join tj_aime
where tpa_id IN (5, 6)
group by per_id
having count(*) = 2
Pour en venir à l'erreur de conception, quelques requêtes simple, pour voir si a l'instar de Kyle Katarn (cf. mon premier message dans ce topic) toi aussi tu fais n'importe quoi.
Combien de type d'animaux sont aimés (au total) ?:
SELECT Count(*) AS nbAnimaux
FROM tj_aime
Quels sont les types d'animaux qui ne sont aimés par personne ?:
SELECT tpa_id, tpa_nom
FROM typeAnimal
WHERE NOT EXISTS (
SELECT *
FROM tj_aime
WHERE tj_aime.tpa_id = typeAnimal.tpa_id);
Afficher la liste des types d'animaux et le nombre de fois qu'ils sont aimés (0 y compris):
SELECT tpa_nom, Count(tj_aime.tpa_id) AS nb
FROM tj_aime
right join typeAnimal
on tj_aime.tpa_id = typeAnimal.tpa_id
GROUP BY tpa_nom;
Je pourrais continuer, mais je préfère m'arréter là.
Comment écrire ces requêtes, répondre à ces questions (extrêmement simples), avec cette table de la "solution 1" ???
Dans une base de données correctement conçue, tout problème, toute question peut être répondue en une seule requête (Quand le SGBDR le permet, CTE récursive, fonction fenetrage, etc..).
Tu est de mauvaise fois, c'est incroyable !
Je te parle de simplicité et de performances et toi tu me répond sur les bonnes pratique de conception...
Encore une fois les animaux ne sont qu'un exemple (sans doute très mauvais certes) !
Et ICI, on demandait un conseil pour DÉBUTANT pour faire un "PETIT FORMULAIRE SIMPLE" avec 4 champs FIXES !!!
Alors, oui, en effet, les exemples que j'ai donner ne respectent aucune norme, aucune logique de programmation, etc. car la question n'était pas là ! On ne nous a pas demandé comment concevoir de façon idéal le prochain framework ou une appli haute sécurité et multi-utilisateur...
Bientôt tu va me dire qu'il vaut également mieux faire des requêtes préparer voire stocker, utiliser une abstraction de base de données et utiliser des classes pour optimiser le code voir même pourquoi pas MVC...
Il y a des bonnes pratiques, certes ! Il y a des conventions de nommage, de programmations, etc.
Mais la meilleur des bonnes pratiques à mon sens, s'est sans aucun doute de savoir QUAND UTILISER les normes et conventions !!!
PS / HS : Cependant il est vrai qu'un bon cour de modélisation / MCD / Conception / UML , etc. Bien complet manque cruellement sur le site du zéro il me semble !!! Tout comme la gestion de projet, etc.
Par ailleurs, ces méthodes, bien que très pratique voire indispensable sur des gros projets, sont souvent expliquer de manière très théorique, sur des cas d'école, et sont souvent très compliquer à mettre en œuvre dans la "vrai vie", en particulier de façons efficace et sans perte de temps !
Tu est de mauvaise fois, c'est incroyable !
Je te parle de simplicité et de performances et toi tu me répond sur les bonnes pratique de conception...
Il n'y a aucune mauvaise fois, c'est un fait, je constate.
Les deux "solutions" que tu proposent ne sont pas équivalentes, pourquoi comparer des "performances" alors que c'est déjà faux en amont ?
Citation : Miridan
Alors, oui, en effet, les exemples que j'ai donner ne respectent aucune norme, aucune logique de programmation, etc. car la question n'était pas là !
Le débat porte sur l'utilité de ENUM.
Depuis le début je dit que c'est inutile, encore une fois c'est prouvé lorsque l'on sait concevoir sa BDD correctement.
Citation : Miridan
Mais la meilleur des bonnes pratiques à mon sens, s'est sans aucun doute de savoir QUAND UTILISER les normes et conventions !!!
Alors il faudra m'expliquer "quand".
Si tu maîtrises la conception, les "bonnes pratiques", si tu les comprends, pourquoi faire de la "merde" volontairement ?
Personnellement, j'essaie de faire ce qu'il se fait de mieux en permanence, preuve à l'appuie.
Pour information, tu serais concepteur, un client te demandes de réaliser sa BDD, tu lui rend ça. Si jamais il y a un problème, tu es responsable car tu n'as pas suivi les règles de l'art.
Voir: L'audit des Bases de Données Relationnelles, partie 3.
Autant faire les choses bien, même si au final, l'utilisation n'est pas très importante.
Bon je parle du haut de mes 3 années d'expérience en développement sur des projets de tailles différentes et des technos différentes : ce qui n'est pas énorme j'en conviens. (c'est pas de la fausse modestie : je suis loin d'avoir fait le tour de mon métier d'informaticien, si tant est que cela soit possible et que cela ait un sens de dire cela )
"Ma" règle est simple :
Mieux vaut une conception et une implémentation des données dans les règles de l'art dés le début. Corolaire :
Quand on crée/modélise sa base de données, il ne faut penser qu'aux données et au métier. Il est encore trop tôt pour penser au code (PHP, Java etc.)
Les données, en informatique de gestion/web et compagnie (je ne pratique pas l'informatique industrielle, donc sur ce sujet là je ferme ma gueule), c'est la base de tout.
Pourquoi privilégier une architecture qui pourra éventuellement vous éviter de coder 500 lignes de code supplémentaire au détriment d'une architecture qui vous fera gagner un temps précieux lorsque la base devra évoluer, ou simplement quand il s'agira d'optimiser ?
Pourquoi ne pas respecter scrupuleusement dés le début les formes normales ? Certes, pour éventuellement "casser le modèle" plus tard pour des raisons d'optimisations.
Si y'a pas d'accents dans mes messages c'est parce que je suis sur un clavier norvegien :)
Bon alors résumons avant de partir en cacahuète :
- J'ai proposer 2 solutions (rapides, simples mais pas "forcement" propres) avec code à l'appui qui ont aider l'auteur
- Fayden a dit qu'il ne fallait pas utiliser mes solutions mais utiliser 2 table avec des jointures. (pourquoi pas, mais on attend toujours des exemple de code avec cette solutions !)
- Bluestorm a demandé pourquoi on ne doit pas utiliser ENUM
...
- Cintre Sournois nous à clairement répondu parce que ce n'est pas propres, c'est une erreur de conception...
- J'ai répondu, il faut PARFOIS les utilisés pour des questions de performances (preuves à l'appui)
Et je rajouterais juste, comme l'a dit mrjay42 :
Citation : mrjay42
Quand on crée/modélise sa base de données, il ne faut penser qu'aux données et au métier. Il est encore trop tôt pour penser au code (PHP, Java etc.)
La question de l'ENUM ou pas, est bel et bien une question technique, de langage de programmation, de SGBD, et de PERFORMANCE ! Mais en aucun cas une question de conception !!! (comme l'a dit Cintre sournois, ENUM n'est disponible que (?) sur MySQL) D'autre part, même si s'est très présomptueux de ma part et que je me sens très mal placer pour dire ça, révisez vos cour de conception ! La solutions que vous proposez correspond à une relation "1-n" entre des tables (auquel cas, oui elle est tout à fait justifier) ! Mais en aucun cas, de mes souvenir en conception, on ne crée des tables distinctes pour une relation "3-3" (donc avec des variables et valeurs fixe) comme dans l'exemple fourni ici !
Et je voudrais juste rajouter pour la question de l'utilité d'ENUM, que si des gents, certainement bien plus compétent en la matière que nous tous, ce sont amusés à inventer un type ENUM, c'est bel et bien parce qu'il doit avoir une utilité !
Maintenant la question qui se pose :
Citation : mrjay42
Pourquoi privilégier une architecture qui pourra éventuellement vous éviter de coder 500 lignes de code supplémentaire ... Certes, pour éventuellement "casser le modèle" plus tard pour des raisons d'optimisations
Citation : Cintre Sournois
Si tu maîtrises la conception, les "bonnes pratiques", si tu les comprends, pourquoi faire de la "merde" volontairement ?
Je répondrais 3 choses :
1) En informatique, il y a toujours de très nombreuses solutions à un même problème ! Il n'y a aucune "merde" du moment que ça fonctionne et que ça puisse être facilement repris !
2) Pour des raisons pédagogiques ! Lorsqu'on apprend à programmer, on commence toujours par un simple "Hello World" en mode procédurale ! On ne commence jamais par une conception détaillée avec développement à base de framework, MVC, POO, etc.
3) - Parce que, MALHEUREUSEMENT, dans le monde réel, et là, sans vouloir plagier mrjay42, je parle du haut de mes 8 années d'expérience en développement, essentiellement Web PHP MySQL (donc petit à moyen projet, 2 ou 3 gros entre deux), on n'a pas toujours le choix ! Ne croyez pas que suis contre la conception, bien au contraire, je me bat tout les jours pour !
- Parce que lorsque vous devez, en une demi-journée (budget client oblige), faire la conception de la totalité d'un application, conception logiciel, BDD, partie public et partie administration... Vous n'avez pas le temps d'écrire 500 ligne de plus... Et c'est bien malheureux, mais c'est comme ça !
- Parce que lorsque vous n'avez personne en face de vous pour vous dire comme le logiciel doit fonctionner, ce qu'il doit faire, quelles données y mettre, et que malgré ça vous êtes obliger de commencer à développer quelque chose pour "montrer au client" afin qu'il puisse se décider...
- Parce que, souvent, le client veut un site, mais il ne sait pas pourquoi ni comment (sans parler bien sûr des détail techniques).
- Et enfin parce que ce que le client et le patron veulent en générales c'est une application esthétique et qui fonctionne ! Comment elle fonctionne et si le code est propre, ils en ont souvent rien à faire !
-Et pour aller plus loin, si vous tentez de leurs expliqués que même si le coût initial est plus élever à cause de la conception, le prix seras largement rentabiliser par le gain de temps futur pour les corrections, les évolutions ou optimisations, beaucoup vous répondrons qu'ils en ont rien à faire ! Le prix futur (évolutions et autres) rentrera dans l'amortissement du projet. Ce qu'ils veulent c'est un coût initial le plus bas !
Pour anecdote, j'ai quitter ma précédente entreprise (licenciement arrangé que je ne regrette pas du tout, au contraire), en grande partie à cause de différents avec mon patron, parce que sur la 30ene de projet que j'ai effectuer chez eux, je n'ai eu pour tout cahier des charges que quelques notes griffonnées au crayon à papier, et parce que je voulais faire des projets propres (xHTML valide, compatible IE6, etc. Normal quoi...) mais je mettais trop de temps (quelques heures de plus) à faire ça, plutôt que de faire une mise en page "a l'arrache" en tableau directement avec Dreamweaver (comme le faisait un autre développeur). Donc lorsque je lui ai suggérer de faire des cahiers des charges "complet" (enfin au moins avoir par écrit ce que le site doit présenter et les fonctionnalité qu'il doit présenter) et de modéliser les BDD avant le développement...
Depuis, j'ai réussi à faire comprendre à mon nouveau patron qu'il faut faire des sites propres (xHTML valide, etc.), mais pour la conception... je peut toujours me brosser !
Mais je ne désespère pas pour autant, moi aussi je rêve d'un monde meilleur où tout les SGBD serait compatible entre eux, ou tout les navigateurs serait parfaitement compatible, et où tout le monde aurais la science infuse et où la seule préoccupation des chefs d'entreprise et des clients serait la qualité et non la rentabilité... Mais en attendant je tache de m'adapter au mieux à ce monde cruel...
Par ailleurs pour la question de "ENUM n'ai pas standard"... Si vous vous arrivez à faire des BDD portables (complexes et optimisées bien sûr) pour lesquels TOUTES vos requêtes et type données sont compatible sans modifications, alors vous êtes vraiment très fort !!! Il faut absolument que vous m'expliquiez comment ! Parce que pour avoir travailler 2 ans avec des DBA Oracle, ayant plus de 20 ans d'expériences en stockage de données informatique, ingénieur et/ou chefs de projet dans une SSII de 1800 personnes, aucun de ces DBA n'en était capable et chaque migration de leurs bases de données était un travail de longue haleine ! Et ce même après des conceptions très précises faites par des personnes spécialisées et expérimentée en conception et durant plusieurs mois...
PS : juste une petite remarque par rapport à celle de Cintre sournois sur les "lois" et sont audit des BDDR, je voudrais juste souligner la phrase suivante :
Citation
... si le donneur d'ordre a bien renseigné son maître d'oeuvre sur les métriques attendues
concrètement je n'ai jamais vu un "donneur d'ordre" (le client) renseigner son "maître d'œuvre" (le développeur / la société) sur les "métriques attendues" (les données et leurs tailles) ! C'est TOUJOURS au concepteur/développeur d'aller tirer les vers du nez au client et à lui faire des propositions ! Sans aller chercher plus loin, cette "loi" n'est donc "jamais" applicable !
Miridan, je crois que je vais dire les choses comme ça :
Tu me rappelles moi il y a quelques années.
Je n'avais pas encore travaillé sur des gros projets.
J'avais une vision très technique des choses, ce n'est pas un tort.
Tu dis que tu as 8 années d'XP en dev PHP/MySQL et je ne te prends pas de haut dans ce que je vais dire, le but c'est de faire avancer le débat.
Les gens avec qui tu travailles, ne connaissent pas le boulot d'informaticien, c'est clair.
Si ça ne te plait pas, et bien change de boulot !
Désormais je travaille sur des gros projets en SSII (webmail gérant 14 millions de boites, projet d'envergure nationale pour l'état etc)...
Dans ces projets là, la phase de dév n'est pas la plus longue.
Les phases longues sont :
Spécifications fonctionnelles
Spécifications techniques
Test/validation
Intégration
Mise en prod
Citation
En informatique, il y a toujours de très nombreuses solutions à un même problème ! Il n'y a aucune "merde" du moment que ça fonctionne et que ça puisse être facilement repris !
Voila, c'est l'exemple parfait.
L'exemple parfait de ce qu'un bon informaticien ne doit jamais penser.
Le "ça marche donc c'est bon"...C'est ça qui est de la merde
C'est ça qui fait des applications non-évolutives
C'est ça qui fait des applications non-sécurisées
C'est ça qui fait des applications que personne ne veut reprendre et que personne ne sait reprendre
Dans le monde réel comme tu dis, c'est vrai qu'on voit de tout.
Il n'y a pas si longtemps, j'ai bossé pour un labo de recherche sur un projet plutot petit/moyen en pseudo PHP objet.
Même si ce n'était pas prévu, même si au niveau date ça ne collait pas : j'ai plus ou moins imposer que je recode certaines partie de l'application.
Car dans la logique du projet c'était cohérent de faire quelque chose de propre, dans le but essentiellement que mon travail soit repris par quelqu'un d'autre par la suite.
J'ai expliqué clairement les choses :
"Ok, là je "perds" 1 mois à recoder tout ça.
Néanmoins, actuellement quand vous me demander de coder [ça] cela me prends 2 semaines
Après mon recodage, ça prendra 1 semaine avec les tests inclus dans ce délai
Vous en pensez quoi ?"
Pour moi il est là, le sens du métier d'ingénieur informaticien : on doit être capable de proposer des solutions et d'être fermes. Et, au fait...Faut pas avoir peur du chômage, du boulot pour des informaticiens, à moins d'habiter en Lozère, y'en a partout et c'est plutot bien payé...Faut savoir mettre la pression.
Dans le cadre de ce même projet, j'ai proposé de faire un schéma de la base de données ET un diagramme de classe pour que la personne qui viendra après moi ait des documents de référence auxquels se rattacher...et c'est passé, parce que j'ai expliqué que ce que je voulais faire n'était ni un délire d'informaticien ni un opportunisme technologique ( => "ouais les gars on va utiliser le dernier framework javascript à la mode!!! Pourquoi ? Bah parce que c'est nouveau")
Si y'a pas d'accents dans mes messages c'est parce que je suis sur un clavier norvegien :)
Je commencerais par dire une chose: L'expérience ne fait pas la compétence.
J'ai bossé avec un mec de presque 50 ans, le genre de mec qui travaillait déjà alors que j'était encore au biberon. Il est développeur Web (PHP/MySQL et co) et ben objectivement il est moins bon que moi en PHP (pourtant je ne suis pas terrible), et ses connaissances en SQL étaient proche du néant... Ça se vérifie largement chez les développeurs web notamment.
Concernant, le "il y a plusieurs façons de faire".
J'ai envie de dire faux. "Fermes-là, tu ne sais pas de quoi je parle." comme dirais Dieudonné
Surtout au niveau de la conception, il y a bien souvent une seule solution. Un seul MCD qui correspond exactement aux règles de gestion et respecte la méthode. Encore faut-il avoir les connaissance nécessaire pour s'en apercevoir je pense.
Citation : Miridan
PS : juste une petite remarque par rapport à celle de Cintre sournois sur les "lois" et sont audit des BDDR, je voudrais juste souligner la phrase suivante :
Citation
... si le donneur d'ordre a bien renseigné son maître d'oeuvre sur les métriques attendues
Sans aller chercher plus loin, cette "loi" n'est donc "jamais" applicable !
C'est dommage, tu aurais dû lire un peu plus, tu serais arrivé sur la partie jurisprudence et règles de l'art.
Citation :
....
Ce que l'on appelle les "règles de l'art", sont pour chaque discipline l'ensemble des éléments techniques sur lesquels les professionnels s'accordent afin de satisfaire le client. Par exemple pour un maçon qui devrait ériger un mur, on serait en droit de demander réparation du préjudice s'il n'était pas d'aplomb ou bien que son faîtage ne soit pas droit, sans qu'il soit besoin de produire le moindre contrat écrit.
etc...
...
Pour le reste, je ne peux rien faire pour toi, si ta boite ne te plaît pas, change, sinon change de boulot.
Bref, relis, essaye de comprendre, ça me semble clair.
Je vois pas pourquoi tu as besoin d'un code de ma part, sachant que si tu as vraiment 8 ans de programmation derrière toi, tu sais très bien quoi faire. Sinon, "Il n'y a aucune "merde" du moment que ça fonctionne", ça te fait perdre un peu de crédibilité...
Bon, allez, voilà la structure des tables si ça peut te faire plaisir :
CREATE TABLE Personnes (
idPersonne serial NOT NULL,
nomPersonne varchar(25) NOT NULL,
CONSTRAINT pk_idpersonne_personnes PRIMARY KEY (idPersonne)
);
CREATE TABLE Animaux (
idAnimal serial NOT NULL,
nomAnimal varchar(25) UNIQUE NOT NULL,
CONSTRAINT pk_idanimal_animaux PRIMARY KEY (idAnimal)
);
CREATE TABLE Personnes_Animaux (
idPersonne integer NOT NULL,
idAnimal integer NOT NULL,
CONSTRAINT pk_idpersonne_idanimal_personnes_animaux PRIMARY KEY (idPersonne, idAnimal),
FOREIGN KEY (idPersonne) REFERENCES Personnes (idPersonne),
FOREIGN KEY (idAnimal) REFERENCES Animaux (idAnimal)
);
On veut rajouter un animal avec cette méthode ? Facile, on rajoute une ligne dans la table Animaux. On veut rajouter un animal avec ta méthode ? On modifie la structure de la table. Les deux solutions que tu as proposées dans le premier post sont donc évidemment mauvaises. Une colonne ne contient qu'une valeur et ENUM, surtout lorsque les valeurs peuvent varier, doit être évité. Ce n'est pas uniquement une question de performances, c'est prendre de bonnes habitudes, c'est concevoir correctement son schéma, c'est même faire du code qui peut être réutilisé (ENUM n'est connu que par MySQL).
Le seul moment où on pourrait peut-être utiliser ENUM, c'est si les valeurs sont fixes et ne peuvent jamais changer. Et il est rare qu'on peut affirmer sans l'ombre d'un doute qu'on ne changera jamais rien. Et encore, aussi bien utiliser une autre table quand même si on souhaite faire un code ne serait-ce qu'un peu portable.
Désolé, mais là je vais arrêter le débat, car j'en ai mare de parler dans le vide et qu'on cite mes phrases sans aller jusqu'au bout de celles-ci...
@ Fayden, si j'ai demandé un code, ce n'est pas pour moi (si tu regarde un peu plus haut j'ai pondu a peut près le même pour mes "tests de performance")... Mais bien pour l'auteur qui à poser cette question ! (Le but initial étant d'aider un débutant mais pas de débattre inutilement).
Par ailleurs mon code à moi marche ! Contrairement au tient, qui bêtement ne pourras pas fonctionner tel quel puisque tu as mis des types différents sur tes ID (a moins que SERIAL soit un ALIAS de INTEGER ? Ce qui n'est pas le cas sur MySQL !) ! Tes clés étrangères vont donc rejeter ta requête (en tout cas sur MySQL), erreur qui s'avère très vite très pénible à détecter lorsqu'on est débutant en SQL et avec les clés étrangère !!!
Et c'est justement pour éviter ce genre d'erreur et de complexité "pour un débutant" que j'avais proposé une solution plus simple ! (Merci donc pour ta participation, tu vient de "tombé dans le piège" et renforcer ce que je disait !!!) Et je ne parle même pas de la complexité des requêtes SELECT pour obtenir les infos que l'on veut...
Maintenant, j'entends bien vos arguments ! Essayez donc d'en faire autant sans quoi je ne peut rien non plus pour vous...
PS : Des bonnes SSII, il n'y en a pas partout ! Seulement dans les grande ville ! Et on ne fait pas toujours ce qu'on veut et on ne peut pas toujours ce permettre d'être au chômage, ne serais-ce qu'un mois ! (Mais la on rentre dans des questions de vie privées...)
PS 2 : BRAVO, vous avez en tout cas réussi à me dégouter totalement de ce forum et d'aider les débutant... J'avais envi de participer un peu plus, mais maintenant, les petits jeunes devrons se débrouillez sans mon aide... (j'entends déjà dire "mieux vaut ne rien dire que de dire n'importe quoi", alors soit, je ne dirais plus rien ! Je laisserais les "PRO" répondre )... Sur ce bon courage à tous et à jamais sur le forum SQL...
Par ailleurs mon code à moi marche ! Contrairement au tient, qui bêtement ne pourras pas fonctionner tel quel puisque tu as mis des types différents sur tes ID (a moins que SERIAL soit un ALIAS de INTEGER ? Ce qui n'est pas le cas sur MySQL !) ! Tes clés étrangères vont donc rejeter ta requête (en tout cas sur MySQL), erreur qui s'avère très vite très pénible à détecter lorsqu'on est débutant en SQL et avec les clés étrangère !!!
Et c'est justement pour éviter ce genre d'erreur et de complexité "pour un débutant" que j'avais proposé une solution plus simple ! (Merci donc pour ta participation, tu vient de "tombé dans le piège" et renforcer ce que je disait !!!) Et je ne parle même pas de la complexité des requêtes SELECT pour obtenir les infos que l'on veut...
Ce que tu viens de dire est relativement bête. Tout le monde n'utilise pas MySQL. SERIAL est l'équivalent de integer auto_increment sous MySQL.
De plus, tu ne te rends pas compte que ta méthode ne fonctionne uniquement que sous MySQL parce qu'ENUM ne fait pas parti de la norme. Donc dire que ce que je fais ne tourne pas sous MySQL, c'est un peu ironique.
Citation : Miridan
PS 2 : BRAVO, vous avez en tout cas réussi à me dégouter totalement de ce forum et d'aider les débutant... J'avais envi de participer un peu plus, mais maintenant, les petits jeunes devrons se débrouillez sans mon aide... (j'entends déjà dire "mieux vaut ne rien dire que de dire n'importe quoi", alors soit, je ne dirais plus rien ! Je laisserais les "PRO" répondre )... Sur ce bon courage à tous et à jamais sur le forum SQL...
Quand une méthode n'est pas la plus efficace, oui, on va te le dire. Il ne faut pas t'en offusquer, au contraire, ça aurait été un bon moment pour apprendre. On n'aide pas uniquement ceux qui ouvrent un sujet.
Miridan, on a été un peu sec c'est pas faux.
Mais on n'est pas allé jusqu'aux insultes...On a débatu sur le fond du problème...
Et pour info, il m'est arrivé plus d'une fois d'être "corrigé" ou repris sur ce forum...et les gens qui m'ont appris des choses n'étaient pas forcément plus doués que moi en informatique : ils avaient juste déjà abordé tel ou tel point précis et m'ont fait partagé leur avis...
Si y'a pas d'accents dans mes messages c'est parce que je suis sur un clavier norvegien :)
Question debutant
× Après avoir cliqué sur "Répondre" vous serez invité à vous connecter pour que votre message soit publié.
× Attention, ce sujet est très ancien. Le déterrer n'est pas forcément approprié. Nous te conseillons de créer un nouveau sujet pour poser ta question.
Si y'a pas d'accents dans mes messages c'est parce que je suis sur un clavier norvegien :)
Si y'a pas d'accents dans mes messages c'est parce que je suis sur un clavier norvegien :)
Si y'a pas d'accents dans mes messages c'est parce que je suis sur un clavier norvegien :)