Discussion :

[laurentSc]

Bonjour,

je sais pas si ce que je souhaite faire est faisable et si oui, comment.

Le MCD imaginé est le suivant :

La partie qui nous intéresse est visible.

J'ai une table qui a 2 clés étrangères vers une autre :

Code sql :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
CREATE TABLE ticket(
   id_ticket INT AUTO_INCREMENT,
   num_ticket BIGINT NOT NULL,
   assigned_group VARCHAR(30),
   submitted_date DATE,
   last_resolved_date DATE,
   summary VARCHAR(200),
   priority VARCHAR(6),
   status VARCHAR(13),
   type_incident VARCHAR(10),
   source VARCHAR(12),
   first_country VARCHAR(30),
   id_submitter INT NOT NULL,
   id_customer INT NOT NULL,
   id_application INT NOT NULL,
   PRIMARY KEY(id_ticket),
   UNIQUE(num_ticket),
   FOREIGN KEY(id_submitter) REFERENCES user_table(id_user),
   FOREIGN KEY(id_customer) REFERENCES user_table(id_user),
   FOREIGN KEY(id_application) REFERENCES application(id_application)
);

et

Code sql :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
CREATE TABLE user_table(
   id_user INT AUTO_INCREMENT,
   sesa INT NOT NULL,
   firstname VARCHAR(255),
   lastname VARCHAR(255),
   email VARCHAR(255),
   company VARCHAR(50),
   buunitname VARCHAR(50),
   organization VARCHAR(50),
   id_user_manager INT,
   id_location INT NOT NULL,
   PRIMARY KEY(id_user),
   UNIQUE(sesa),
   FOREIGN KEY(id_user_manager) REFERENCES user_table(id_user),
   FOREIGN KEY(id_location) REFERENCES location(id_location)
);

La table ticketa 2 clés étrangères vers la table user_table, donc elle a 2 colonnes qui pointent vers user_table : id_submitteret id_customer.
Si j'avais une seule colonne à renseigner, ça serait simple. Par exemple

Code sql :

Sélectionner tout - Visualiser dans une fenêtre à part

INSERT INTO ticket (num_ticket,id_submitter)  SELECT 12345, id_user FROM user_table WHERE id_user=456789

mais comme il faut insérer dans 2 colonnes, peut-on le faire et comment ?

[laurentSc]

J'ai une réponse de Escartefigue, reçue par mail, mais qui a disparu depuis. Fausse manip ? Il disait ceci :

Bonsoir Laurent

Il n'est pas normal de référencer deux fois la même colonne de la même table, ce qui est anormal, c'est ceci :

FOREIGN KEY(id_submitter) REFERENCES user_table(id_user),
FOREIGN KEY(id_customer) REFERENCES user_table(id_user),
quelque chose ne vas pas dans le modèle de données.

D'ailleurs, ça ne correspond pas au modèle publié dans l'autre fil de discussion qui est ici :
https://www.developpez.net/forums/d2...-d-entite-mcd/

Si ce modèle est différent de celui publié dans l'autre discussion, c'est justement un essai, mais dont je n'étais pas sûr. Vu votre commentaire, j'avais raison de douter, donc mon MCD est mauvais. Les règles de gestion, que je ne sais visiblement pas traduire en MCD sont les suivantes :

- un utilisateur (donc un membre de la classe user_table) crée un ticket (il est donc un submitter de ce ticket)

- un utilisateur (donc un membre de la classe user_table)(pas forcément le même que le submitter) a un problème sur une application et donc un ticket a été créé à ce sujet. Cet utilisateur est nommé customer.

Je ne sais pas si c'est clair. En tous cas, une entité ticket est reliée 2 fois à la classe d'entité user_table, une fois pour le submitter (ou créateur du ticket) et une autre fois pour le customer qui désigne l'utilisateur qui a un problème sur une application. Cela fait donc 2 entités de la classe user_table. Comme la clé primaire de cette table est id_user, il me semblait logique de créer 2 clés étrangères sur cette colonne. Comme ça ne se fait pas, comment aurais-je pu faire ?

[al1_24]

Rien n'empêche d'avoir deux clés étrangères vers la même table si fonctionnellement le besoin est correctement défini.
Quant à la requête d'insertion, elle nécessite deux accès à la table référencée :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
INSERT INTO ticket
    (   num_ticket
    ,   id_submitter
    ,   id_customer
    )
SELECT  12345
    ,   sbm.id_user
    ,   cst.id_user
FROM    user_table  sbm
    CROSS JOIN
        user_table  cst
WHERE   sbm.id_user = 456789
    AND cst.id_user = 987654
;

Si le id_user a été vérifié par ailleurs, il serait plus simple ici d'insérer directement les valeurs :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
INSERT INTO ticket
    (   num_ticket
    ,   id_submitter
    ,   id_customer
    )
VALUES
    (   12345
    ,   456789
    ,   987654
    )
;

[Artemus24]

Salut laurentSc.

Je ne suis pas du même avis que AL1_24.

La table ticket a 2 clés étrangères vers la table user_table, donc elle a 2 colonnes qui pointent vers user_table : id_submitter et id_customer.

D'accord, et donc le problème est d'avoir pour ces deux colonnes une valeur qui est référencée dans la table user_table.

mais comme il faut insérer dans 2 colonnes, peut-on le faire et comment ?

Si j'ai bien compris votre problème, votre traitement (insertion dans la table ticket) doit se faire en deux étapes :

a) à la création du "submitter".
Vous renseigner la colonne "id_submitter" avec sa valeur connue.
Mais par contre, la colonne "id_customer" devra être marquée à NULL car vous ignorez à ce moment sa valeur.

b) à la création du ou des "customer".
Dans ce cas là, ce n'est plus une insertion mais une mise à jour (update) de la table ticket. Pourquoi ?
Car le "submitter" doit exister au préalable pour qu'un "customer" puisse existe.

Donc oui c'est faisable, avec le marquage à NULL de la colonne id_customer lors de la création du "submitter".

Par contre, la question pertinente qui est soulevée par Escartefigue est de savoir si la modélisation est correcte ?
Pour ma part, ce qui me dérange est d'avoir une colonne marquée à NULL et qu'elle puisse rester ainsi.
D'où une perte de place inutile qui n'est pas justifier par la modélisation. Pourquoi ?
Car pour ce "submitter", il se peut qu'aucun "customer" n'ait un quelconque problème et donc l'absence de problème ne doit pas se justifier par un marquage à NULL.

Pour la colonne "id_customer", je pense qu'il faut l'externaliser dans une table associative qui contiendra le couple (id_ticket ; id_customer) en tant que clef primaire.
Pour un "submitter" donné, sa valeur devra être déjà existant dans la table ticket.
C'est pourquoi il faut mettre l'identifiant du ticket, et non l'identifiant du "submitter".
La table associative sera vide tant qu'il n'existe pas un "customer" ayant un problème pour ce ticket.
De ce fait, la colonne "id_ticket" en tant que clef étrangère devra pointer sur la table ticket et la colonne "id_customer" devra pointer sur la table user_table.

Comme je ne connais pas la problématique de votre application, il m'est difficile de dire plus à ce sujet.

@+

[Paprick]

Bonjour,

Donc oui c'est faisable, avec le marquage à NULL de la colonne id_customer lors de la création du "submitter".

Si tel est le cas, dans le MCD, la cardinalité doit être 0,1 au lieu de 1,1.

Par contre, la question pertinente qui est soulevée par Escartefigue est de savoir si la modélisation est correcte ?
Pour ma part, ce qui me dérange est d'avoir une colonne marquée à NULL et qu'elle puisse rester ainsi.
D'où une perte de place inutile qui n'est pas justifier par la modélisation. Pourquoi ?
Car pour ce "submitter", il se peut qu'aucun "customer" n'ait un quelconque problème et donc l'absence de problème ne doit pas se justifier par un marquage à NULL.

Pour la colonne "id_customer", je pense qu'il faut l'externaliser dans une table associative qui contiendra le couple (id_ticket ; id_customer) en tant que clef primaire.
Pour un "submitter" donné, sa valeur devra être déjà existant dans la table ticket.
C'est pourquoi il faut mettre l'identifiant du ticket, et non l'identifiant du "submitter".
La table associative sera vide tant qu'il n'existe pas un "customer" ayant un problème pour ce ticket.
De ce fait, la colonne "id_ticket" en tant que clef étrangère devra pointer sur la table ticket et la colonne "id_customer" devra pointer sur la table user_table.

Je suis d'accord avec ce raisonnement lorsqu'on veut à tout prix éviter d'avoir des NULL qui se promènent dans les clés étrangères.
En fait, il y a deux approches en cas de cardinalité 0,1 :

• Soit on accepte qu'une clé étrangère soit NULL et on l'inclut directement dans la table associée (c'est la solution part défaut proposée par Looping).
• Soit on demande à Looping de générer une table d'association en cas de cardinalité 0,1 : dans ce cas, comme indiqué ci-dessus, plus de NULL intempestif !

Chacun peut choisir selon sa sensibilité, sachant que certains sont plus sensibles aux NULL que d'autres !

[Artemus24]

Salut à tous.

Je suis d'accord avec ce raisonnement lorsqu'on veut à tout prix éviter d'avoir des NULL qui se promènent dans les clés étrangères.

Pas uniquement dans des clefs étrangères mais aussi dans n'importe quelles colonnes.
Le but du marquage NULL est qu'au moment du remplissage, l'utilisateur qui fait la saisie ne connait pas la valeur de cette colonne.
Mais celle-ci (la valeur de cette colonne) sera par la suite renseignée. J'insiste sur ce dernier point.

Si par contre, la même colonne reste marquée à NULL définitivement, c'est qu'il y a un problème de modélisation.

La solution consistant à marquer à NULL une clef étrangère ne me choque pas trop, encore que, il y a matière à discussion.
Le fait que la clef étrangère ne fasse pas partie de la clef primaire, permet à celle-ci d'être marquée à NULL.
Mais dans ce cas, qu'elle est l'intérêt d'avoir une clef étrangère marquée à NULL ?
Je m'interroge sur la volonté d'insérer une ligne sachant que l'on ne connait pas la valeur de cette clef étrangère.
Est-ce que la saisie se fait trop tôt ? Il faudrait ne pas anticiper la saisie tant que l'on a pas toutes les informations.

Ou alors comme je le suppose, nous avons un problème de modélisation.
Que l'on choisisse de laisser cette clef étrangère à NULL, ou que l'on utilise une table associative pour résoudre ce problème, cela doit se justifier d'une manière fonctionnelle.

Mais de toutes les façon, je préconise plutôt de créer une table associative, que de laisser la clf étrangère marquée à NULL.

@+

[laurentSc]

Merci pour vos réponses que je découvre ce soir. Comme peu de batterie et pas chez moi, je les regarderai plus longuement demain soir.

[escartefigue]

Bonjour

J'ai une réponse de Escartefigue, reçue par mail, mais qui a disparu depuis. Fausse manip ?

J'ai supprimé mon message immédiatement après l'avoir validé car j'ai pensé après coup aux tables associatives de type parent/enfant ou composant/composé par exemple, tables dans lesquelles on a systématiquement deux FK pour la même colonne.


Concernant les FK "nullables"

Pour ma part, ce qui me dérange est d'avoir une colonne marquée à NULL et qu'elle puisse rester ainsi.

En fait, il y a deux approches en cas de cardinalité 0,1 :

• Soit on accepte qu'une clé étrangère soit NULL et on l'inclut directement dans la table associée (c'est la solution part défaut proposée par Looping).
• Soit on demande à Looping de générer une table d'association en cas de cardinalité 0,1 : dans ce cas, comme indiqué ci-dessus, plus de NULL intempestif !

Chacun peut choisir selon sa sensibilité, sachant que certains sont plus sensibles aux NULL que d'autres !

Je suis d'accord avec Paprick, c'est un choix, pour le quel je penche pour... du pragmatisme.
Par exemple, dans le cas où un type d'entité fait l'objet de plusieurs associations facultatives et mutuellement exclusives, plutôt que de créer autant de tables qu'il y a d'associations, l'utilisation de FK nullables simplifie le modèle sans compliquer les requêtes.

Un exemple concret ci dessous (extrait d'un sujet du forum schéma), dans lequel la règle de gestion stipule qu'une affectation concerne soit un véhicule, soit un emplacement de stockage en magasin. Le MCD qui en découle est le suivant :

Pièce jointe 598853

Si on accepte les FK nullables, le module tabulaire devient :
Pièce jointe 598854

Alors que si on n'en veut pas, le modèle tabulaire est alors :
Pièce jointe 598855
On passe de 3 à 5 tables, ce n'est pas rien.

[laurentSc]

Bonjour,
j'ai essayé de tenir compte de toutes vos interventions, avec ma très faible expérience.

Tout d'abord, j'ai tenu compte d'une remarque de Paprick et ai modifié une cardinalité de is_customer entre les classes ticket et user_table pour la passer de 1,1 à 0,1. Voici la dernière version du MCD :

Ensuite, je mets à jour les 2 colonnes de ticket qui sont 2 clés étrangères vers la colonne id_user de la table user_table en 2 requêtes : un INSERT où l'une d'entre elles est mise à NULL, puis un UPDATE.

Voici un exemple :

Code sql :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
insert into ticket (num_ticket, id_submitter, id_customer) 
select 123456, id_user, null from user_table 
WHERE sesa=29353
 
UPDATE ticket
SET id_customer = (select id_user from user_table where sesa=168129) 
WHERE id_ticket=4

Cette façon de faire est-elle correcte ?

[escartefigue]

Bonsoir,

Tout d'abord, j'ai tenu compte d'une remarque de Paprick et ai modifié une cardinalité de is_customer entre les classes ticket et user_table pour la passer de 1,1 à 0,1.

Attention, la remarque de Paprick répondait au besoin de pouvoir rendre nulle une colonne FK.
MAIS : les cardinalités doivent refléter exactement les règles de gestion, il n'est pas question de les modifier par confort d'utilisation.
Ainsi, remplacer le minimum 1 par 0 autorise désormais à avoir un ticket créé par... personne ! Je doute que ça reflète la réalité.
Si toutefois c'est conforme, alors dans ce cas seulement il faut remplacer la cardinalité minimale de 1 par 0.

Ensuite, je mets à jour les 2 colonnes de ticket qui sont 2 clés étrangères vers la colonne id_user de la table user_table en 2 requêtes : un INSERT où l'une d'entre elles est mise à NULL, puis un UPDATE.

Tous les SGBD fournissent des fonctions qui permettent de récupérer les valeurs des identifiants quand ceux-ci sont calculés par le SGBD (c'est à dire les colonnes IDENTITY en général et les colonnes AUTO_INCREMENT dans le cas de MySQL).
Ainsi, après insertion dans la table "user_table", la fonction LAST_INSERT_ID() de MYSQL renvoie la dernière valeur insérée par la transaction en cours, il suffit de la stocker dans une variable pour pouvoir l'utiliser ensuite comme valeur FK à insérer dans la table "ticket"
Même principe pour toutes les FK.
Il ne faut pas faire un INSERT puis un UPDATE, c'est inutile et contre performant

[Artemus24]

Salut à tous.

Je suis d'accord avec Paprick, c'est un choix, pour le quel je penche pour... du pragmatisme.

Déjà le mot "pragmatisme" me dérange dans l'élaboration d'une modélisation. Ce n'est pas le critère que l'on doit retenir !

Dans ton exemple, le MCD indique un "x" et je comprends qu'il s'agit d'un "ou exclusif".
A savoir qu'il doit exister obligatoirement une affectation et que celle-ci doit être unique. C'est soit :
--> un véhicule,
--> un emplacement de stockage en magasin.
mais pas les deux à la fois.

Or, je ne vois pas apparaitre par la suite, dans ta simplification, la règle du "ou exclusif" ?
Ce qui sous-entend que l'on peut avoir deux affectations ou bien aucune, ce qui est contraire à ta règle de gestion.

Je pense que tu n'as pas raison de pratiquer cette simplification car il y a une perte d'information.

Il ne faut pas faire un INSERT puis un UPDATE, c'est inutile et contre performant

D'après ce que j'ai compris du sujet soulevé par laurentSc, il s'agit de la gestion des tickets.

Je ne sais pas si c'est clair.

Je viens de m'apercevoir que vos explications ne sont pas clair du tout.

Je pense qu'il n'est pas nécessaire de faire la distinction entre le "submitter" et le "customer".

Pour moi, c'est la même gestion du problème mais pas le même ticket.
Un utilisateur rencontre un problème, il ouvre un ticket.
Un autre utilisateur rencontre le même problème, il doit ouvrir un autre ticket.

Les explications alambiquées données par chaque utilisateur dans les tickets, ne peuvent servir de critère de regroupement.

Il me semblait logique de faire la création des clefs étrangères en deux temps, dont l'un est un insert et l'autre un update.
Mais je ne vois pas l'intérêt de faire une distinction entre le "submitter" et le "customer".
Il faudrait expliciter un peu plus ce double choix.

@+

[escartefigue]

Bonsoir Artemus24

Déjà le mot "pragmatisme" me dérange dans l'élaboration d'une modélisation. Ce n'est pas le critère que l'on doit retenir !

Heu, si j'en crois la définition du petit Robert ici, c'est tout à fait applicable

Dans ton exemple, le MCD indique un "x" et je comprends qu'il s'agit d'un "ou exclusif".
A savoir qu'il doit exister obligatoirement une affectation et que celle-ci doit être unique. C'est soit :
--> un véhicule,
--> un emplacement de stockage en magasin.
mais pas les deux à la fois.

Or, je ne vois pas apparaitre par la suite, dans ta simplification, la règle du "ou exclusif" ?
Ce qui sous-entend que l'on peut avoir deux affectations ou bien aucune, ce qui est contraire à ta règle de gestion.

Oui, c'est bien la règle de gestion que j'ai donnée dans ma réponse précédente.
Et effectivement, cette règle disparaît complètement dans le MLD simplifié.
Mais, elle disparaît également du MLD non simplifié, et ce, tout simplement parce que, contrairement à une contrainte d'inclusion, une contrainte d'exclusion ou de partition n'est pas traduisible sous forme de DDL.
Ce type de contrainte devient soit un trigger, soit une UDF associée à une contrainte check (mais je ne crois pas qu'on puisse le faire avec MySQL y compris en V8... malheureusement), soit encore par traitement.
La solution par traitement est évidemment plus risquée puisqu'elle n'offre pas la garantie de contrôle qu'offre le moteur du SGBD.

Je pense que tu n'as pas raison de pratiquer cette simplification car il y a une perte d'information.

Cette perte n'est donc pas inhérente à la simplification ou non du MLD, mais bien à la limite de traduction de certains types de contraintes.

Je pense qu'il n'est pas nécessaire de faire la distinction entre le "submitter" et le "customer".
Pour moi, c'est la même gestion du problème mais pas le même ticket.
Un utilisateur rencontre un problème, il ouvre un ticket.
Un autre utilisateur rencontre le même problème, il doit ouvrir un autre ticket.

Non : le "submitter" est la personne qui déclare l'incident, le "customer" est la personne qui est victime de ou pénalisée par l'incident
C'est un cas fréquent, exemple type : une personne P1 a son PC en panne, elle ne peut donc pas se connecter aux applications et notamment à celle qui permet de déclarer et suivre les incidents.
Elle demande donc à une autre personne P2 (l'un de ses collègues) d'ouvrir pour elle l'incident en question.
Dans ce cas, l'incident aura pour "submitter" la personne P2 et pour "customer" la personne P1.

[laurentSc]

Mais je ne vois pas l'intérêt de faire une distinction entre le "submitter" et le "customer".
Il faudrait expliciter un peu plus ce double choix.

Il faut les distinguer car ce ne sont pas toujours les mêmes.
- un customer rencontre un problème sur une application, donc un ticket doit être créé pour signaler ce problème.
- un submitter (souvent le customer mais pas toujours) crée le ticket.
Est-ce clair comme cela ?

Ainsi, remplacer le minimum 1 par 0 autorise désormais à avoir un ticket créé par... personne ! Je doute que ça reflète la réalité.

Eh non ! car la cardinalité 0,1 concerne le customer et c'est le submitter qui crée le ticket, mais c'est vrai que s'il n'y a pas de customer, c'est temporaire au niveau de mon application alors qu'en réalité, il existe. De ce fait, la cardinalité est peut-être quand même 1,1 , non ?

Il ne faut pas faire un INSERT puis un UPDATE, c'est inutile et contre performant

C'est peut-être contre performant, mais avec la puissance des machines actuelles et la simplification du code que ça apporte...Car pour éliminer le UPDATE, il faudrait stocker chaque ID_USER à sa création associée à une autre clé unique (par exemple le code SESAqui est l'identifiant du user), donc créer un tableau avec des couples (ID_USER, SESA) et au moment d'effectuer le INSERT, aller chercher dans ce tableau le ID_USER qui correspond au SESA que l'on doit traiter. C'est faisable, mais le jeu en vaut-il la chandelle ?

[Artemus24]

Salut à tous.

Il faut les distinguer car ce ne sont pas toujours les mêmes.
- un customer rencontre un problème sur une application, donc un ticket doit être créé pour signaler ce problème.
- un submitter (souvent le customer mais pas toujours) crée le ticket.
Est-ce clair comme cela ?

D'accord. J'avais un doute sur le rôle joué par le "customer".

Mais dans le cas qui vous pose problème, celui qui crée le ticket connait nécessairement celui qui rencontre le problème.
Il n'est pas nécessaire de faire la création du ticket en deux étapes.

De ce fait, la cardinalité est peut-être quand même 1,1 , non ?

La cardinalité s'applique au ticket et non au "customer". De ce fait, c'est bien "1,1" qu'il faut mettre.

@+

[escartefigue]

Bonjour Laurent,

C'est peut-être contre performant, mais avec la puissance des machines actuelles et la simplification du code que ça apporte...Car pour éliminer le UPDATE, il faudrait stocker chaque ID_USER à sa création associée à une autre clé unique (par exemple le code SESAqui est l'identifiant du user), donc créer un tableau avec des couples (ID_USER, SESA) et au moment d'effectuer le INSERT, aller chercher dans ce tableau le ID_USER qui correspond au SESA que l'on doit traiter. C'est faisable, mais le jeu en vaut-il la chandelle ?

La gestion d'incident ne concerne pas des insertions en masse mais de façon unitaire : déclaration sur entretien téléphonique avec le help desk, au moyen d'une application à dispo des utilisateurs ou automatiquement en batch lors de la détection de plantages de traitements. Donc ici nul besoin de tableau pour stocker une pile d'identifiants.

Pour pouvoir créer le ticket, puisque celui-ci possède deux FK issues de la table "user_table", il faut, grâce aux éléments fournis dans le formulaire de déclaration de l'incident, retrouver l'identifiant du déclarant (submitter) et, si bénéficiaire et déclarant sont des personnes différentes, retrouver également l'identifiant du bénéficiaire (customer).

Le contexte étant la gestion d'incidents, le cas le plus fréquent est que les deux personnes, déclarant (submitter) comme bénéficiaire (customer) sont des personnes déjà connue dans la base de données. Le traitement fera une (déclarant = bénéficiaire) ou deux (déclarant <> bénéficiaire) requêtes SELECT pour retrouver le ou les identifiants id_user.
L'id_user ou les deux id_user trouvé(s) permettront de faire l'insertion du ticket avec ses deux valeurs de FK.

Si toutefois le déclarant ou le bénéficiaire n'est pas connu dans la table "user_table", cas certainement très marginal, c'est là que l'application devra créer par insert le déclarant et récupérer son identifiant grâce à la fonction LAST_INSERT_ID dont le résultat sera stocké dans une host variable, faire de même si besoin avec le bénéficiaire, puis insérer dans la table "ticket".

[laurentSc]

Bonjour et merci pour les réponses.

Donc OK, j'abandonne l'idée de créer un tableau et d'y stocker les id_user. Si je comprends bien, remplacer le UPDATE par un SELECT, c'est plus performant ?

En tout cas, c'est ce que je crois comprendre. Pour effectuer ça, mon idée est de créer des variables SQL :
1- on fait le SELECT et on stocke le résultat dans une variable.
2- on fait le INSERT en utilisant la variable.

Si l'idée est bonne, j'ai d'abord tenté la création de la variable :

Code sql :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
DECLARE @idsubmitter int
DECLARE @SQLReq varchar(100)
@id_submitter=12345
SET @SQLReq='SELECT id_user FROM user_table WHERE sesa = ''' + @idsubmitter + ''''
SELECT @SQLReq

mais erreur SQL. Quel est le problème SVP ?

[escartefigue]

Il n'y a pas besoin de construire du SQL dynamique ici : il suffit de faire la requête SELECT pour récupérer l'ID dans une variable (INTO), puis la requête INSERT qui affectera la valeur de cette variable à la colonne FK :

Code SQL :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
DECLARE @idsubmitter int
SELECT id_user 
INTO @idsubmitter
FROM   user_table 
WHERE sesa = @ma_valeur_sesa

[laurentSc]

Merci pour la réponse. Je ne connaissais pas la syntaxe SELECT INTO, mais c'est bien pratique ! Par contre, en faisant

Code sql :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
DECLARE @idsubmitter int
SELECT id_user 
INTO @idsubmitter
FROM   user_table 
WHERE sesa = 12345

, erreur SQL. Qu'est-ce qui ne va pas ?

[isabelle.letrong]

Bonjour,

A la vue des discussions il apparait clairement que le modèle n'est pas encore abouti…

Par exemple :

• Il y a des discussions concernant les notions de 'custumer' et de 'submitter' mais ces concepts n'apparaissent même pas sur le MCD !

• Il y a surement beaucoup de questions, pas encore posées, qui attentent des réponses !
  - un 'submitter' peut-il posséder une une licence ?
  - la 'Company', définie 'en vrac' au niveau de l'utilisateur (custumer, submitter ou les 2 à la fois'), ne sera-t-elle pas un objet de gestion à sortir du USER ?
  - on perçoit que la notion de rôles de l'utilisateur (et peut-être même de la 'Company...) doit être creusée
  -...

Le fait que l'on tolère autant de NULL dans votre DDL est également un marqueur de réflexion non encore aboutie...

[laurentSc]

Le fait que le modèle ne soit pas parfait n'est pas surprenant vu que ça ne fait que quelques semaines que j'ai découvert la modélisation et notamment les MCD...

Vous parlez de 'custumer' au lieu de 'customer'. Je n'ai pas trouvé où était cette faute de frappe...

Les notions de id_customer et de id_submitter, sont présentes dans le MCD sous la forme de FK de la table ticket vers la table user_table.

Sortir company, comme buunitname et organization de user_table aurait pour conséquence de rajouter l'existence de 3 tables, ce qui alourdirait le modèle...

on perçoit que la notion de rôles de l'utilisateur (et peut-être même de la 'Company...) doit être creusée

Vous pouvez préciser ?

Le fait que l'on tolère autant de NULL dans votre DDL est également un marqueur de réflexion non encore aboutie...

Vous pouvez préciser aussi ? Déjà, comment voyez-vous que des NULL sont autorisés ? S'agit-il de toutes les colonnes sans NOT NULL ?