Reprise du message précédent :
apparament ca serait plutot pour oracle  
 
CREATE TABLE ORDERS
(Order_ID integer primary key,
Order_Date date,
Customer_SID integer references CUSTOMER(SID),
Amount double);

la meme chose pour mysql
 
MySQL:
CREATE TABLE ORDERS
(Order_ID integer,
Order_Date date,
Customer_SID integer,
Amount double,
Primary Key (Order_ID),
Foreign Key (Customer_SID) references CUSTOMER(SID));  
 
 
 
mais hier quand j'ai essayé de faire ca j'avais des erreurs

ca parrait correct ca ??

apparament ca ne fonctionne pas

quelle est l'erreur?

probleme de syntaxe

je vais retenter de cette maniere :
 

 
on verra si ca fonctionne
 
pas envie de rendre un projet oracle alors qu'on me demande du mysql

Je te demande quelle est l'erreur exacte, pas une approximation. C'est censé te donner une indication de ce qui ne va pas...

euh desolé je l'ai plus sous les yeux la j'ai cours de TCL/TK (quelle horreure)
 
mais la console te dit juste de checker le manuel et que c'est une erreure de syntaxe a la ligne 1

perso, mise à part la PK (et encore) je ne déclare jamais les contraintes dans le code de création de la table.
 
je trouve la syntaxe pourrie et illisible.
 
ça marche pas un truc du genre ?
PS : syntaxe SQL Server, ça demande donc certainement quelques adaptations, déjà au niveau du nom des types qui ne sont pas les mêmes
 

CREATE TABLE a
(
   id numeric NOT NULL,
   lib varchar(50) NOT NULL
)
go
 
CREATE TABLE b
(
   id numeric NOT NULL,
   lib varchar(50) NOT NULL,
   id_a numeric NOT NULL
)
go
 
ALTER TABLE a ADD constraint pk_a PRIMARY KEY (id)
go
 
ALTER TABLE b ADD constraint pk_b PRIMARY KEY (id)
go
 
ALTER TABLE b ADD constraint fk_ab FOREIGN KEY (id_a) REFERENCES a (id)
go

PS : On voit dans mon exemple surtout ce qui est intéressant lorsqu'on créer les contraintes "à la main" en dehors de la déclaration de la table... Ici, on peut (doit) leur donner un nom, ce qui est très pratique pour la suite. Par exemple, tu as un "arbre" avec un a.pere_id reference a.id
Lors de l'ajout de l'élément root, (a.id = 1 / a.pere_id = 1) tu ne va pas pouvoir remplir l'élément de clé étrangère puisque l'enregistrement n'existe pas encore. Il est donc intéressant de désactiver manuellement la FK, ce qui est impossible si tu ne lui donne pas de nom.
 

CREATE TABLE a
(
  id numeric NOT NULL,
  pere_id numeric NOT NULL,
  val varchar(50)
)
go
 
ALTER TABLE a ADD constraint pk_a PRIMARY KEY (id)
go
 
ALTER TABLE a ADD constraint fk_aa FOREIGN KEY (pere_id) REFERENCES a(id)
go

 
Tentative d'insertion de lignes :

INSERT INTO a (id, pere_id, val) VALUES (1, 1, 'root');

 
Euh... Sous SQL Server 2005 ils ont modifié le fonctionnement du truc, ça passe sans désactiver la FK !
 
M'enfin bon, logiquement, ça doit faire ça :

 
Ce qui se corrige donc comme ceci :

-- Je désactive la contrainte
ALTER TABLE a nocheck constraint fk_aa
go
 
-- J'insère un truc qui est totalement impossible (je n'ai pas d'élément avec id = 12) mais ça passe puisque la contrainte est désactivée
INSERT INTO a (id, pere_id, val) VALUES (3, 12, 'element 3');
 
-- Je réactive la contrainte : pas d'erreur, car la ré"activation n'engendre pas de test sur les valeurs existantes
-- On peut donc de balader des données incohérentes, il faut faire attention. Si on veut l'éviter, il faut supprimer la contrainte et la recréer
-- car la création d'une contrainte engendre la vérification des données existantes
ALTER TABLE a CHECK constraint fk_aa
go

merci je vais analyser ca plus tard
 
mais je sais deja que l'histoire de contrainte je ne l'ai jamais vue

l'histoire de "alter table"  
 
ça te permet d'ajouter les PK, les index, toussa en dehors du script basique de création de la table

ok, mais comme il faut lui envoyer toutes les commandes si c'est possible de créer la table entiere d'un seul coup c'est cool
 
 
bon j'ai toujours pas reverrifié la comande de base comme on a vu en "cours"

bah de toute façon tu mets tout dans le même script. Tu vas pas lui envoyer un fichier par table

non forcement

ceci dit j'ai jamais fait de merise non plus

ça se voit pas du tout

 
grillé, mais on ne s'en serait pas douté

bon tout fonctionne comme ceci :
 
 
 

j'ai reussi a remplir la premiere table, ca va aller come sur des roulettes (ou pas)

tables crées, relations otpimisées, tables remplies

voila mon shema relationnel :
 

et voila la premiere requete :
 

 
 
pour montrer que j'avance

souligné : pk
gras : fk
 
plus facile pour s'y retrouver

premiere requete compliquée :
 
affichez les clients et les dates de commandes, et classez par ordre croissant du numero de commande :
 
 
ca va deja me faire piocher dans 3 tables : client, ordonnance et commande
 

 
ouais pas bete

 
 
resolue !!

je m'arrete la :

listez les clients qui n'ont jamais commandé d'examen radiologique

(partie : jointures internes)

il nous conseille de faire une jointure interne pour trouver toutes les commandes contenant un examen radiologique et ensuite faire une jointure externe avec la table client

edit : il faut utiliser not exists ?

si tu passes par une externe, tu n'en as pas besoin.
par contre, la syntaxe est effectivement pas super claire (et pas logique au premier abords) alors qu'avec un exists et une sous-requête, c'est infiniment plus clair (mais aussi légèrement plus lent selon les SGBD)

ok je vais essayer ca demain, la j'ai plus la force pour bosser

en même temps c'est dredi quoi

bon j'y ai pas passé bcp de temps aujourd'hui
 
mais si qq'un a deja une idée de la forme approximative de cette requete c'est toujours bon a prendre

moi je dirais :  
tous les clients - tous les clients qui ont commandé un exam.
 
 
mais comme ca, au premier abord, a 1h du mat un samedi

ok j'avais bien compris ca

mais niveau syntaxe ca pourrait ressmelber a quoi?

jsais pas si on utilise ca pr les BDD mais me faudrait un espece d'algorithme

qu'est ce que tu connais comme operateur d'appartenance? (a part le not exists que tu a deja cité)

 
 
exists , not exists, in , not in  
 
voila c'est tout je crois

ben deja avec le 'not in' tu dois pouvoir faire quelque chose non?
 
"tous les clients" not in "tous les clients qui ont demandé un exam"
 
 
 
edit : sinon y'a aussi 'minus' qui devrait pouvoir te sortir le bon résultat.
mais je sais pas si ca marche sur tous les SGBD.

ok je verrai ca , demain 8h30 environ je m'y remet

ca y est?tu t'y es mis ?

dictateur

bon, faut p'tet que j'aille au boulot moi...

oublie les exists et autres.
 
le prof a parlé de jointure externe, et c'est faisable avec une jointure externe.
 
=> tous ceux qui n'ont pas fait d'examen
 
Ca se traduit de 3 manières différentes :
- Tous les patients SAUF (not exists / not in) ceux qui ont passé un exament (nécessite une sous-requête)
- Tous les patients MOINS ceux qui ont passé un exeman (DIFFERENCE) (supporté sur PostGreSQL, et pas grand chose d'autre)
- Le CONTRAIRE de ceux qui ont passé un exament (OUTER JOIN) (supporté par tous les SGBD dans toutes leurs versions - ou presque -)
 
Pour trouver la syntaxe avec le "contraire", commence par faire ta requête normalement avec des INNER JOIN tout ce qu'il y a de plus classique, affin de trouver ceux qui ont passé un exament.
Ensuite, modifie ton INNER JOIN en LEFT/RIGHT OUTER JOIN, et compare les résultats : dans les champs de "examen", pour les clients qui n'en ont jamais passé, tu as la valeur "null".
=> T'as plus qu'à rajouter un test sur un de ces champs déclaré en "NOT NULL" dans la table histoire de ne pas te faire avoir par des données incomplètes, afin d'isoler tout ceux qui n'ont jamais passé d'exament.