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
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
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.
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 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 :-(
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.....
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.
Ceci est plus simple :
Exec SPGetHeadquarters
Que ceci :
Pour obtenir le même résultat et j'ai lu deux choses :SELECT [HeadquartersName] FROM [DZINDZIO_TRUCKS_MANAGEMENT_GILLES].[dbo].[TRUCK_HEADQUARTERS_V]
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
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.
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...
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" !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...
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 ;
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 ?L'intérêt est de me simplifier la conception des drop down list dynamiques en cascade sans passer par du JScript
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.
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.
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.Lorsque je fais disons un 'INSERT', le Trigger il gère tout.
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.
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....
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.
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Partager