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?
Re: Re: Re: Foreign keys -- Daniel K. Schneider 18 mars 2010 à 10:41 (CET)
Si ! justement la théorie doit être int dans ce cas, car la théorie est TOUTE la ligne de la première table. Il ne faut surtout pas choisir un varchar, cas UNE théorie de la table 1 peut apparaitre plusieurs fois dans la table 2. Ensuite, vous devriez être capable de change son nom défini ici.
theory_name varchar(40) NOT NULL DEFAULT
Donc la deuxième table renvoie juste à la première table. C'est cela le principe du relationnel. Une ligne dans une 2ème table contient une colonne qui renvoi sur une ligne de la première table. autrement dit: un ormative_events utilise la théorie numéro 36 (et qui est définit dans la table 1)
.... a moi que je n'ai pas compris ce que vous voulez dire par théorie
Sinon, on peut prendre d'autres id que des int (comme les varchar), mais faut les déclarer "primary key".
Re: Re: Re: Re: Foreign keys -- Sugarch0 18 mars 2010 à 12:51 (CET)
- Ce que je ne comprends pas c'est comment les personnes qui enregistrent qqchose dans une table savent la primary key? Si on prend l'exemple des étudiants et des exercices (dans le tutoriel wiki), l'étudiante Sophie par exemple ne sait pas qu'elle a une primary key=3, donc elle rend juste ses exercices et ne met pas student_id=3...et donc ensuite comment le système peut-il mettre les 2 tables en relation? Qui introduit student_id=3?
=Re: Re: Re: Re: Re: Foreign keys -- Daniel K. Schneider 18 mars 2010 à 14:17 (CET)=
Facile :) un utilisateur n'est pas censé voir la structure de la base de données. Autrement dit, il faut créer une application (par exemple avec PHP ou encore avec un outil comme Maestro) et qui affiche dans une menu "pulldown" le NOM de la théorie, donc certainement pas le numéro.
