J'ai une table avec les colonnes Formulaire, Évaluateur, Date et Niveau
Un formulaire ne peut jamais avoir les mêmes évaluateurs, et un formulaire ne peut jamais avoir les mêmes niveaux.
J'ai essayé de créer une clé primaire (formulaire, évaluateur) et une clé primaire (formulaire, niveau) mais cela dit que le formulaire a plusieurs clés primaires
Si je mets une clé primaire (formulaire, évaluateur, niveau) les gens peuvent simplement insérer le même formulaire et le même évaluateur deux fois, mais avec un niveau différent et cela enfreint mes règles.
|Form|Appraiser|Level|
1 A 1
1 B 2
1 C 3
2 A 1
2 B 2
2 C 3
3 Réponses :
Nous pouvons essayer d'utiliser deux tables de jonction ici:
CREATE TABLE form_appraiser (
form_id INTEGER NOT NULL,
appraiser_id INTEGER NOT NULL,
PRIMARY KEY (form_id, appraiser_id)
);
CREATE TABLE form_level (
form_id INTEGER NOT NULL,
level_id INTEGER NOT NULL,
PRIMARY KEY (form_id, level_id)
);
Chacune de ces deux tables garantirait qu'un formulaire donné ne peut être associé qu'à un seul évaluateur ou niveau.
Ensuite, maintenez une troisième table forms contenant un enregistrement pour chaque formulaire unique. Si vous avez l'exigence supplémentaire qu'un formulaire donné ne peut avoir qu'un seul évaluateur ou niveau, ajoutez une contrainte unique sur le formulaire, sur l'une / les deux tables de jonction.
Vous pouvez essayer d'ajouter la contrainte unique comme identificateur de colonne.
comme
évaluateur VARCHAR (50) UNIQUE, forme VARCHAR (50) UNIQUE, niveau VARCHAR (50) UNIQUE,
Dans ce cas, aucune des valeurs ne se répète. Si vous voulez qu'une combinaison de valeurs ne se répète pas, vous pouvez utiliser UNIQUE (forme, niveau) Cela signifie que vous ne pouvez pas avoir une forme de répétition de même niveau.
Je pense que vous pourriez utiliser: -
INSERT OR IGNORE INTO mytable values (1,'Z',1) > Affected rows: 0 > Time: 0s
par exemple Utilisation de ce qui suit
INSERT OR IGNORE INTO mytable VALUES (1,'A',4) > Affected rows: 0 > Time: 0s
Les résultats sont: -
INSERT INTO mytable VALUES
(1,'A',1),(1,'B',2),(1,'C',3),
(2,'A',1),(2,'B',2),(2,'C',3)
> Affected rows: 6
> Time: 0.083s
mais
DROP TABLE IF EXISTS mytable;
CREATE TABLE IF NOT EXISTS mytable (form INTEGER, appraiser TEXT, level INTEGER, UNIQUE(form,appraiser), UNIQUE(form,level));
INSERT INTO mytable VALUES
(1,'A',1),(1,'B',2),(1,'C',3),
(2,'A',1),(2,'B',2),(2,'C',3)
;
INSERT OR IGNORE INTO mytable VALUES (1,'A',4);
INSERT OR IGNORE INTO mytable values (1,'Z',1);
et aussi
CREATE TABLE IF NOT EXISTS mytable (form INTEGER, appraiser TEXT, level INTEGER, UNIQUE(form,appraiser), UNIQUE(form,level));
On dirait que vous voulez des contraintes uniques plutôt que des clés primaires.
@jarlh oh ok merci d'avoir travaillé, y a-t-il un avantage à utiliser des clés primaires composées par rapport aux clés uniques composées?
@jarlh Mais si deux formes différentes pouvaient avoir le même évaluateur ou niveau, alors une contrainte unique en elle-même ne fonctionnerait pas.
@TimBiegeleisen salut désolé je pense que j'ai un peu de malentendu sur ma question, c'est en fait un évaluateur ne peut jamais avoir le même niveau sous une seule forme, donc ce que je voulais vraiment mettre était la clé primaire (formulaire, évaluateur) et la clé primaire (formulaire , évaluateur, niveau)
Veuillez ajouter quelques exemples de données.
@TimBiegeleisen a ajouté, j'ai omis la date. Donc, fondamentalement, un formulaire a des évaluateurs de différents niveaux, le niveau détermine s'ils sont le premier, le deuxième ou le troisième évaluateur