Discussion :

[ordigil]

Merci fsmrel.
Ce n'est pas urgent car j'ai tellement à faire avec le site web pour les formulaires.
C'est vraiment difficile de tout gérer, ça n'avance pas vite haha
Passez une belle soirée

Bonsoir Gilles,

Pour le moment je surchargé, mais je ne vous oublie pas. Dès que je pourrai, je reviendrai voir nos tandems, essieux et tout ça.

A bientôt j’espère,

François

 

[ordigil]

J'ai fais cette vue pour simplifier les ComboBox sur le site WEB. Je ne sais pas en français comment on traduit : "Dynamic Cascading ComboBox".

USE [DZINDZIO_TRUCKS_MANAGEMENT_GILLES]
GO


/****** Object:  View [dbo].[TRUCK_HEAD_MAN_MOD_V]    Script Date: 2020-03-31 16:13:37 ******/
SET ANSI_NULLS ON
GO


SET QUOTED_IDENTIFIER ON
GO


CREATE VIEW [dbo].[TRUCK_HEAD_MAN_MOD_V]
AS
SELECT        x.ContactName AS Headquarters
            , y.ContactName AS Manufacturer
            , z.ModelName AS Model
FROM            dbo.HEADQUARTERS_V AS x 
     INNER JOIN dbo.TRUCK_MANUFACTURER_V AS y ON x.ContactName = y.HeadQuartersName 
     INNER JOIN dbo.TRUCK_MODEL_V AS z ON y.ContactName = z.ManufacturerName
GO

[ordigil]

J'ai refais la Vue "TRUCK_HEAD_MAN_MOD_V" à l'aide des Tables au lieu qu'avec d'autres Vues....

USE [DZINDZIO_TRUCKS_MANAGEMENT_GILLES]
GO


/****** Object:  View [dbo].[TRUCK_HEAD_MAN_MOD_V]    Script Date: 2020-04-03 09:37:29 ******/
SET ANSI_NULLS ON
GO


SET QUOTED_IDENTIFIER ON
GO


CREATE VIEW [dbo].[TRUCK_HEAD_MAN_MOD_V]
AS
SELECT        t.ContactName AS HeadQuarters
            , x.ContactName AS Manufacturer
            , s.TruckModelName AS Model
FROM            dbo.CONTACT AS x 
     INNER JOIN dbo.MANUFACTURER AS y ON x.ContactId = y.ManufacturerId 
     INNER JOIN dbo.HEADQUARTERS AS z ON z.HeadquartersId = y.HeadquartersId 
     INNER JOIN dbo.CONTACT AS t ON t.ContactId = z.HeadquartersId 
     INNER JOIN dbo.TRUCK_MANUFACTURER AS u ON u.ManufacturerId = y.ManufacturerId 
     INNER JOIN dbo.TRUCK_MODEL AS s ON u.ManufacturerId = s.TruckManufacturerId
GO

[ordigil]

Bonjour fsmrel.

J'ai réussi à installer un Différentiel d'une marque dans un Essieu d'une autre marque.
Je sais, c'est magique.
Mais ça cause un problème car dans le monde réel, c'est presque impossible qu'un différentiel d'une marque puisse être installé dans l'essieu d'une autre marque.
Pourtant vous aviez conçu le Trigger pour ne pas permettre cela.
Peut-être que vous l'avez fait pour le INSERT mais pas pour le UPDATE.
Pour l'instant ce n'est qu'un petit détail à régler plus tard lorsque vous serez libre.
Je n'ai pas regardé le Trigger car il y a d'autres choses de plus important à régler. La gestion du site WEB est très difficile et je dois faire des petites corrections dans les Tables. Je m'amuse à faire des changements dans "DZINDZIO_TRUCKS_MANAGEMENT_GILLES" mais je laisse intacte "DZINDZIO_TRUCKS_MANAGEMENT_TEMP" pour ne pas que vous perdiez votre temps à chercher les erreurs pour les Triggers lorsque vous aurez du temps à me consacrer.

[ordigil]

Est-ce que c'est sécuritaire d'enregistrer une procédure sur SQL Server et d'appeler cette procédure à partir d'un Site WEB ou s'il vaut mieux éviter de le faire ???

[fsmrel]

Est-ce que c'est sécuritaire d'enregistrer une procédure sur SQL Server et d'appeler cette procédure à partir d'un Site WEB ou s'il vaut mieux éviter de le faire ???

Bonjour Gilles,


La question est plutôt à poser dans le forum SQL Server...

Cela dit, j'espère que tout va bien pour vous. A Paris on a des problèmes...

[ordigil]

Bonjour fsmrel.... Je m'en remets simplement à votre expérience. Peu importe si on utilise SQL Server, PostgreSQL, MySQL ou autre. Est-ce qu'on le fait couramment ou il vaut mieux éviter de le faire.

J'espère aussi que ça va bien pour vous. Ici les problèmes commencent. Mais ça va cogner très dur car tout est en train de fermer. Notre baril de pétrole varie entre $4,69 et $9,69 alors notre pétrole on ne le vend pas on le donne :-(

Bonjour Gilles,


La question est plutôt à poser dans le forum SQL Server...

Cela dit, j'espère que tout va bien pour vous. A Paris on a des problèmes...

[ordigil]

Oupssssss, j'ai un petit pépin...... Volvo est à la fois le Headquarters et le Manufacturier et la base de données ne le permet pas.... Disons que je vais avoir un plus gros problème car Volvo est le Headquarters, le Manufacturier de pièces et le Manufacturier de Camions.....

[CinePhil]

Bonjour,

54 pages et plus de mille réponses ! Diantre ! Fichtre !

Est-ce que c'est sécuritaire d'enregistrer une procédure sur SQL Server et d'appeler cette procédure à partir d'un Site WEB ou s'il vaut mieux éviter de le faire ???

Il faut bien que la procédure soit exécutée à un moment ou un autre par un programme, que celui-ci soit une application web ou pas.

L'avantage des procédures est que le programme ne peut ainsi manipuler les données que de la manière qui a été prévue par la construction de la BDD. Une base de données ne devrait être accessible aux programmes que via les vues pour la consultation et via des procédures pour la transformation des données (INSERT, UPDATE, DELETE). Idéalement, l'utilisateur SQL dont se sert l'application pour manipuler les données n'a que les privilèges SELECT et EXECUTE, et encore, pas forcément sur tous les objets de la BDD. C'est plus lourd à gérer mais c'est ce qu'il y a de plus sécurisé.

C'est le principe du développement en bases de données épaisses présenté par SQLPro il y a un certain nombre d'années.

[ordigil]

Ceci est plus simple :

Exec SPGetHeadquarters

Que ceci :

SELECT [HeadquartersName]
  FROM [DZINDZIO_TRUCKS_MANAGEMENT_GILLES].[dbo].[TRUCK_HEADQUARTERS_V]

Pour obtenir le même résultat et j'ai lu deux choses :
1- C'est plus sécuritaire appeler une procédure que d'utiliser les tables directement
2- Ça diminue grandement le traffic sur le réseau.

Si quelqu'un me confirme alors je passe tout par des procédures

Ce site WEB et cette base de données n'entreront jamais en production, ils ne sont qu'un perpétuel outil d'apprentissage

    HeadquartersName
_______________________________
1 |  Daimler
2 |  Navistar
3 |  Paccar
4 |  Compagnie internationale DAC
5 |  Compagnie internationale Naudin
6 |  Volvo

[CinePhil]

Oui, enfin... faire une procédure stockée qui fait une requête SELECT, je n'en vois pas trop l'intérêt.

Par contre, faire un SELECT sur une vue est pertinent. L'utilisateur SQL de l'application peut n'avoir de privilège SELECT que sur les vues et du coup il ne connaît pas la structure des tables et ne peut accéder qu'aux données qu'on veut bien lui montrer via les vues.

Les procédures sont pertinentes pour les INSERT, UPDATE et DELETE, surtout si c'est opéré sur plusieurs tables. Par exemple, une procédure d'insertion en BDD d'un salarié va insérer dans la table des personnes puis dans la table des personnes physiques et enfin dans la table des salariés, ces trois tables héritant l'une de l'autre. Ça permet en plus de vérifier que les données qu'on souhaite insérer sont conformes aux règles de gestion des données.

[ordigil]

Bonjour CinePhil,

Merci pour l'information. Oui je ne me sers uniquement que des Vues et les (INSERT, UPDATE, DELETE) sont tous gérés par les excellents Triggers conçus spécialement par fsmrel ;-) Par contre pour me simplifier la conception du site WEB et pour diminuer le traffic réseau, j'ai pensé à concevoir des Procédures Stockées pour faire appel aux Triggers...

Bonjour,

54 pages et plus de mille réponses ! Diantre ! Fichtre !


Il faut bien que la procédure soit exécutée à un moment ou un autre par un programme, que celui-ci soit une application web ou pas.

L'avantage des procédures est que le programme ne peut ainsi manipuler les données que de la manière qui a été prévue par la construction de la BDD. Une base de données ne devrait être accessible aux programmes que via les vues pour la consultation et via des procédures pour la transformation des données (INSERT, UPDATE, DELETE). Idéalement, l'utilisateur SQL dont se sert l'application pour manipuler les données n'a que les privilèges SELECT et EXECUTE, et encore, pas forcément sur tous les objets de la BDD. C'est plus lourd à gérer mais c'est ce qu'il y a de plus sécurisé.

C'est le principe du développement en bases de données épaisses présenté par SQLPro il y a un certain nombre d'années.

[CinePhil]

les (INSERT, UPDATE, DELETE) sont tous gérés par les excellents Triggers conçus spécialement par fsmrel ;-)

Attention à la confusion !
Un trigger est une portion de code SQL qui s'exécute à chaque insertion, mise à jour ou suppression, selon la nature du trigger. Le trigger est associé à la table mais il n'est pas toujours nécessaire de recourir à un trigger quand on insère, met à jour ou supprime des données dans une table. C'est même relativement rare et heureusement !

Par contre pour me simplifier la conception du site WEB et pour diminuer le traffic réseau, j'ai pensé à concevoir des Procédures Stockées pour faire appel aux Triggers...

Non. Une procédure stockée ne va pas "appeler un trigger" !
Une procédure stockée est un programme SQL qui fait un certain nombre de choses et retourne ou pas une donnée. S'il y a dans la procédure stockée une requête INSERT, UPDATE ou DELETE et que cette requête porte sur une table qui est munie d'un TRIGGER ON INSERT, ON UPDATE ou ON DELETE, alors le trigger s'exécutera.

Par exemple, j'ai donné dans mon anicen blog un exemple de trigger d'incrémentation relative qui numérote automatiquement les chambres d'un hôtel à chaque fois qu'on ajoute une chambre.

On pourrait avoir une procédure stockée qui crée un hôtel en prenant en entrée parmi ses paramètres le nombre de chambres. Cette procédure exécuterait alors autant d'INSERT dans la table des chambres que demandé par le lancement de la procédure et le trigger d'incrémentation relative serait exécuté autant de fois qu'il y a de chambres à créer mais sans avoir à programmer un quelconque appel à ce trigger dans la procédure.

Une telle procédure pourrait ressembler à ça (pas testé) :

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
22
23
24
25
26
27
DELIMITER //
CREATE OR REPLACE PROCEDURE pi_ajout_hotel
(
	IN nom_hotel VARCHAR(50),
	IN nb_chambres TINYINT
	OUT id_hotel INT
)
BEGIN
	DECLARE numero TINYINT DEFAULT 1;
 
	INSERT INTO Hotel (htl_nom)
	VALUES (nom_hotel);
 
	id_hotel = LAST_INSERT_ID;
 
	chambres: LOOP
		INSERT INTO Chambre (chb_id_hotel)
		VALUES (id_hotel);
 
		SET numero = numero + 1;
 
		IF numero > nb_chambres THEN
			LEAVE chambres;
		END IF;
	END LOOP;
END//
DELIMITER ;

[ordigil]

L'intérêt est de me simplifier la conception des drop down list dynamiques en cascade sans passer par du JScript... Mais je peux être dans l'erreur car je suis en phase d'expérimentation ;-)

Oui, enfin... faire une procédure stockée qui fait une requête SELECT, je n'en vois pas trop l'intérêt.

Par contre, faire un SELECT sur une vue est pertinent. L'utilisateur SQL de l'application peut n'avoir de privilège SELECT que sur les vues et du coup il ne connaît pas la structure des tables et ne peut accéder qu'aux données qu'on veut bien lui montrer via les vues.

Les procédures sont pertinentes pour les INSERT, UPDATE et DELETE, surtout si c'est opéré sur plusieurs tables. Par exemple, une procédure d'insertion en BDD d'un salarié va insérer dans la table des personnes puis dans la table des personnes physiques et enfin dans la table des salariés, ces trois tables héritant l'une de l'autre. Ça permet en plus de vérifier que les données qu'on souhaite insérer sont conformes aux règles de gestion des données.

[CinePhil]

L'intérêt est de me simplifier la conception des drop down list dynamiques en cascade sans passer par du JScript

Ben de toute manière il faut bien utiliser Javascript et même Ajax pour que le contenu de la deuxième liste se mette à jour en fonction de la sélection par l'utilisateur dans la première, non ?

Donc ça reste un enchaînement de requêtes SELECT WHERE et pas besoin de procédure SQL.

Exemple de listes liées an Ajax sur mon nouveau blog.

[ordigil]

Désolé, je me suis mal exprimé.... Lorsque je fais disons un 'INSERT', le Trigger il gère tout. Je n'ai pas besoin d'utiliser une procédure pour faire un 'INSERT' ou un 'UPDATE'.. Je veux faire des Procédures pour autres choses sur le Site WEB, pour les dropdown list en me servant du retour des Procédures. J'ai vu le principe sur un site web développé avec ASP net.

Attention à la confusion !
Un trigger est une portion de code SQL qui s'exécute à chaque insertion, mise à jour ou suppression, selon la nature du trigger. Le trigger est associé à la table mais il n'est pas toujours nécessaire de recourir à un trigger quand on insère, met à jour ou supprime des données dans une table. C'est même relativement rare et heureusement !


Non. Une procédure stockée ne va pas "appeler un trigger" !
Une procédure stockée est un programme SQL qui fait un certain nombre de choses et retourne ou pas une donnée. S'il y a dans la procédure stockée une requête INSERT, UPDATE ou DELETE et que cette requête porte sur une table qui est munie d'un TRIGGER ON INSERT, ON UPDATE ou ON DELETE, alors le trigger s'exécutera.

Par exemple, j'ai donné dans mon anicen blog un exemple de trigger d'incrémentation relative qui numérote automatiquement les chambres d'un hôtel à chaque fois qu'on ajoute une chambre.

On pourrait avoir une procédure stockée qui crée un hôtel en prenant en entrée parmi ses paramètres le nombre de chambres. Cette procédure exécuterait alors autant d'INSERT dans la table des chambres que demandé par le lancement de la procédure et le trigger d'incrémentation relative serait exécuté autant de fois qu'il y a de chambres à créer mais sans avoir à programmer un quelconque appel à ce trigger dans la procédure.

[CinePhil]

Lorsque je fais disons un 'INSERT', le Trigger il gère tout.

Encore une fois, le trigger n'est pas systématiquement nécessaire. Dans une BDD en cours de développement, j'ai seulement 4 triggers pour 68 tables.

[ordigil]

Comme je l'ai dit les Triggers sont presque tous fait et ils fonctionnent très bien... Ce que je fais c'est que je m'amuse entre le site WEB et SQL Server pour voir toutes les facettes.... En fait je m'amuse avec Laravel et même si on me disait que c'était impossible de faire les INSERT et les UPDATE avec Eloquent avec les VUES de SQL Server, je me suis amusé à le rendre possible avec l'aide de fsmrel qui a passé plusieurs heures à concevoir les Triggers. Jusqu'à maintenant je n'utilise aucune JScript sur le site WEB. Je n'utilise pas VueJs ni Bootstrap.. Je code tout à la main et là je vais m'amuser un peu en appelant des Procédures stockées sur SQL Server. Évidemment c'est pour m'amuser. On apprend en s'amusant et on s'amuse en apprenant ;-) À chaque fois que j'avance sur le site WEB, je trouve autre chose alors je recommence et je recommence, c'est un éternel recommencement. S'il y a mille et une façons de concevoir quelque chose pour arriver au même résultat, j'en suis probablement rendu à mille, il n'y a jamais de mille et une, je trouve toujours autre chose hahaha.

Encore une fois, le trigger n'est pas systématiquement nécessaire. Dans une BDD en cours de développement, j'ai seulement 4 triggers pour 68 tables.

[ordigil]

C'est exactement ça que je vais essayer de casser en utilisant des Procédures Stockées sur SQL Server.... Désolé si je ne m'exprime pas clairement. Une procédure me donne un retour alors ce retour il pourrait bien servir pour que le contenu de la deuxième liste se mettre à jour en fonction de la sélection par l'utilisateur dans la première liste... Du moins en théorie....

Ben de toute manière il faut bien utiliser Javascript et même Ajax pour que le contenu de la deuxième liste se mette à jour en fonction de la sélection par l'utilisateur dans la première, non ?

Donc ça reste un enchaînement de requêtes SELECT WHERE et pas besoin de procédure SQL.

Exemple de listes liées an Ajax sur mon nouveau blog.

[CinePhil]

Le web n'a pas de mémoire !

L'utilisateur demande une page => le serveur compose et envoie la page avec les listes déroulantes pleines
=> L'utilisateur sélectionne un truc dans la première liste => pour que la liste suivante soit modifiée en fonction de cette sélection, il faut un programme Javascript qui filtre lui même les données présentes ou bien interroge de nouveau la BDD pour composer la deuxième liste. Ou alors vous redemandez l'affichage complet de la page au serveur avec en paramètre ce choix dans la première liste et le serveur recompose la page en entier pour la renvoyer à l'utilisateur.

Je ne vois pas comment ça peut fonctionner autrement et ce ne sont pas des procédures stockées qui y changeront quelque chose. Il vaut bien mieux interroger une vue avec une banale requête SELECT... WHERE.