STIC Discussion:STIC II - exercice 11 (Nestor-Pixel)
NULL ou NOT NULL
Je me posais la question alors... :
Si un champ est type "NULL" et qu'il ne contient pas de données.. Lors d'un SELECT, la valeur renvoyé est "NULL", un marqueur spécial. Si le champ est de type "NOT NULL" et que le champ ne contient pas de données. Un SELECT va renvoyé "" (rien). C'est une source de débat et pas mal d'info pertinente peuvent être trouvé ici : wikipedia.
Pour faire simple, NULL = un marqueur spécial != une valeur . C'est une non-valeur.... --Davidc 22 février 2008 à 12:11 (CET)
Design database
Un chouette lien (un peu technique), mais bon : http://en.wikipedia.org/wiki/Database_design
Ça marche pô... ??
Petite liste des erreurs classiques :
- J'ai mis un DEFAULT à un champ qui est AUTO INCREMENTé ...
- pas bien, une valeur auto-incrémenté a pour DEFAULT sa valeur maximale +1, le redéclarer, c'est comme donner trop de caféine à MySQL...
- J'ai déclaré un champ NOT NULL et je ne lui ai pas donné de DEFAULT '' ou 'something' ...
- pas bien, si un champ ne peut renvoyer la valeur null, il doit nécessairement renvoyer quelque chose, même rien ==> DEFAULT '' . Sinon, c'est comme lui demander de signer un chèque en blanc, ça l'inquiète un peu...
- Le nom de mon champ est écrit avec un accent (aigu|grave|x)
- Buzz avec MySQL avec l'encodage des caractères, évitez comme la peste les mots accentués en langage de code (sauf s'il s'agit de phrase apparaissant à l'écran du client)
..ajoutez vos découvertes :P ..
Drop dropons dropez
Bonjour, je vais poser une question bête : ça veut dire quoi "DROP TABLE IF EXISTS student; DROP TABLE IF EXISTS exercice;" (voir exo) ? "Drop" ça signifie "supprimer", non ? pourquoi supprimer ?
merci pour vos lumières et merci bcp à ceusses qui ont complété mon exo 10
Sylviane 4 mars
(d'après moi) ça veut dire qu'avant de créer une nouvelle table, on supprime celles qui ont le même nom (ici student et exercice). Si on le fait pas, on risque de se retrouver avec les données de l'ancienne table dans la nouvelle, et là catastrophe parce qu'on aura des vieilles valeurs dans notre table... et on comprendra pas pourquoi :(
--Bertrand Schneider 4 mars 2008 à 16:36 (CET)
- C'est à peu près ça.. Tu as tout bon avec la grande loi du démon SQL: il ne peut posséder 2 tables du même nom (dans le même schéma (BdD)). Mais au lieu de faire un rajout de colonnes et des mix de soirées genre crevette épicées au paprika, servi avec une sauce à la ciboulette. Tu vas juste recevoir une erreur et ta commande (CREATE TABLE) ne sera pas traitée si ta table existe déjà. C'est pour ça qu'on vire la table avant de la recréer. ==> Parce que quand tu as une erreur dans la déclaration de la 4ème table dans ton script, MySQL aura quand même créé correctement les 3 premières mais aura arrêté le traitement à partir de la 4ème. Donc pour relancer ton script et éviter les erreurs....
- Attention au DROP TABLE, signifie aussi la perte des données qu'il contient. Vous pouvez faire un export des données qu'elle contient et rajouter à la fin de votre script les commandes INSERT ... générées. Il n'y a pas de risque de confusion car les données ne sont pas classées par ordre linéaire, mais selon le nom des champs (id, champ1, champ2, .etc..)--Davidc 10 mars 2008 à 06:54 (CET)
Zèle -- Claire Peltier 24 février 2010 à 08:48 (CET)
Bonjour,
J'ai importé les tables de ma base de données sur ma machine en local et je l'ai également fait sur PhPMyAdmin de Tecfa. Je ne sais pas s'il fallait aller jusque là ? Dois-je laisser ma base de données à cet endroit (j'ai fait un lien depuis mon rapport sur ma page travaux) ou dois-je l'enlever ?
Merci pour votre réponse.
Claire
Re: Zèle -- Daniel K. Schneider 24 février 2010 à 16:42 (CET)
vous pouvez les laisser, bon exercice, mais effectivement je veux juste un lien sur le fichier SQL que vous posez dans le répertoire ex11.Vous pouvez laisser ou enlever le lien, enlever c'est probablement mieux, car personne d'autre est censé avec accès à phpmyadmin...
Vos tables chez nous ne prennent aucune place donc pas de pb pour les laisser eux :)
Foreign keys -- Sugarch0 17 mars 2010 à 19:32 (CET)
Mon plan: créer deux BDD avec en commun le nom d'une théorie d'apprentissage comme foreign key.
la table 1 décrit qques théories d'apprentissage qui peuvent être utiles dans la création d'exercices/évaluations formatives:
DROP TABLE IF EXISTS learning_theories; CREATE TABLE IF NOT EXISTS learning_theories ( id int(10) NOT NULL AUTO_INCREMENT, author varchar(40) NOT NULL DEFAULT , approximate_year year(4) NOT NULL DEFAULT '0', theory_name varchar(40) NOT NULL DEFAULT , theory_description VarChar(1000) NOT NULL DEFAULT , PRIMARY KEY (id) ) ENGINE=InnoDB DEFAULT CHARSET=utf8;
C'est bon, la table a été créée et remplie.
Maintenant je voudrais créer une seconde table qui décrit des "learning events" (évènements formatifs?...) avec une foreign key comme suit:
DROP TABLE IF EXISTS formative_events; CREATE TABLE IF NOT EXISTS formative_events ( id int(10) NOT NULL AUTO_INCREMENT, eventname char(40) NOT NULL DEFAULT , theory varchar(40) DEFAULT NULL, learnerside varchar(150) DEFAULT NULL, teacherside varchar(150) DEFAULT NULL, example varchar(500) DEFAULT NULL, PRIMARY KEY (id), KEY theory (theory), FOREIGN KEY (theory) REFERENCES table_theories(theory_name) ) ENGINE=InnoDB DEFAULT CHARSET=utf8;
L'idée est que les théories d'apprentissage sont une référence commune à plusieurs domaines dans la formation et qu'on pourrait faire plusieurs tables avec des sujets différents et dont le dénominateur commun serait le nom de la théorie. Est-ce possible d'avoir une key qui est du type varchar?
Problème: MySQL refuse de créer cette seconde table: Il dit "#1005 can't create table exercice11.formative_events (errno 150)" et je ne trouve pas de réponse après avoir essayé toutes sortes de trucs. Où est l'erreur?
Re: Foreign keys -- Daniel K. Schneider 17 mars 2010 à 21:47 (CET)
Voili, il y avait plusieurs erreurs:
- quand vous indiquez DEFAULT, FAUT indiquer une valeur par défaut sinon cela n'a pas de sens
- VarChar est limité, donc faut utiliser "TEXT" pour un champs aussi large que 1000
- Y a pas de valeur par défaut pour TEXT
- Le foreign key doit se référer à un ID d'une autre table (c'est le principe meme de la relation: on indique un enregistrement unique
Solution:
DROP TABLE IF EXISTS learning_theories;
CREATE TABLE IF NOT EXISTS learning_theories (
id int(10) NOT NULL AUTO_INCREMENT,
author varchar(40) NOT NULL DEFAULT "" ,
approximate_year year(4) NOT NULL DEFAULT '0',
theory_name varchar(40) NOT NULL DEFAULT "",
theory_description text NOT NULL,
PRIMARY KEY (id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
DROP TABLE IF EXISTS formative_events;
CREATE TABLE IF NOT EXISTS formative_events (
id int(10) NOT NULL AUTO_INCREMENT,
eventname varchar(40) NOT NULL DEFAULT "",
theory int (10) NOT NULL,
learnerside varchar(150) NOT NULL DEFAULT "",
teacherside varchar(150) NOT NULL DEFAULT "",
exemple text NOT NULL,
PRIMARY KEY (id),
KEY theory (theory),
FOREIGN KEY (theory) REFERENCES learning_theories(id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
Re: Re: Foreign keys -- Sugarch0 18 mars 2010 à 10:08 (CET)
- Merci pour votre réponse! Il reste une chose: le champ "theory" dans la table learning_events ne peut pas être int puisque c'est le nom d'une approche pédagogique. Comment "coder" ces théories pour créer la relation? Dans le tutoriel wiwki.en, il est dit que "en général" les keys sont des champs int, mais est-ce obligatoire?