par
sadeq » 25 nov. 2008, 12:55
Bonjour tout le monde.
Les 2 solutions se complètent, l'usage d'une procédure stockée est recommandé et la requête de
zeus est son contenu.
Pour expliquer mieux la problématique posée au niveau conceptuel, il faut rappeler que c'est normal d'éprouver dans le cas posé un malaise conceptuel vu qu'en fait la procédure voulu par notre ami n'est qu'un transfert de données entre une source de données et une table spécifique. Et c'est la table de destination qui appartient au modèle de données métier et non celle qui fait office de source de données. Ce qui justifie la redondance de données soupçonnée dans un tel cas.
Ici, ce qu'il faut c'est un schéma de transfert de données et non un MCD conceptuel vu qu'on se positionne dans le modèle opérationnel de traitement.
Donc, comme l'a précisé
zeus dans sa solution SQL (modèle opérationnel de traitement), il s'agit bien d'une importation de données dans la table de destination depuis une source de données:
Code : Tout sélectionner
INSERT INTO table_destination ([champs de destination]) SELECT [champs sources] FROM table_source
L'interface de données entre la procédure d'extraction (SELECT) et celle d'injection (INSERT) est constituée d'une connexion entre les [champs de destination] et les [champs sources]. Connexion qui doit respecter l'ordre, le type et la taille des données sujets du transfert.
Par exemple:
Exige que les champs A, B et C, D soient respectivement égaux dans l'ordre de citation et dans leur type/taille
C'est à dire : A équivalent à C et B équivalent à D dans leur type/taille. sinon, si les types ne sont pas équivalents, il faut appliquer judicieusement des fonctions de conversion de type pour
adapter la source à la destination. Si c'est un problème de taille, la source s'adapte forcément à la destination et l'on risque des troncatures ou des erreurs de données.
Pour stocker durablement cette opération ainsi conçue on peut utiliser une procédure stockée, ainsi, on enrichi notre modèle opérationnel de traitement enregistré dans le schéma de la base de données pour permettre aux développeurs de réutiliser les procédures pour construire des applications.
Exemple de déploiement de cette opération en procédure stockée:
Code : Tout sélectionner
delimiter |
CREATE PROCEDURE transfert1 ()
BEGIN
INSERT INTO table2 (A, B) SELECT C, D FROM table1;
END
Pour l'exécuter cette procédure stockée on lance la commande:
Tout ça c'est du SQL, et l'avantage de cette méthode d'intégration du modèle physique de données (tables, contraintes, indexes et relations durables) et du modèle opérationnel (triggers, vues, procédures stockées et fonctions) dans la même base de données, est d'abord la standardisation SQL, la réutilisabilité multi-plateforme de développement, la maintenance rapprochée et uni-langage...etc... sans rappeler le partage de charge de mise en œuvre et de fonctionnement des applications.
Bonjour tout le monde.
Les 2 solutions se complètent, l'usage d'une procédure stockée est recommandé et la requête de [b]zeus[/b] est son contenu.
Pour expliquer mieux la problématique posée au niveau conceptuel, il faut rappeler que c'est normal d'éprouver dans le cas posé un malaise conceptuel vu qu'en fait la procédure voulu par notre ami n'est qu'un transfert de données entre une source de données et une table spécifique. Et c'est la table de destination qui appartient au modèle de données métier et non celle qui fait office de source de données. Ce qui justifie la redondance de données soupçonnée dans un tel cas.
Ici, ce qu'il faut c'est un schéma de transfert de données et non un MCD conceptuel vu qu'on se positionne dans le modèle opérationnel de traitement.
Donc, comme l'a précisé [b]zeus[/b] dans sa solution SQL (modèle opérationnel de traitement), il s'agit bien d'une importation de données dans la table de destination depuis une source de données:
[code]INSERT INTO table_destination ([champs de destination]) SELECT [champs sources] FROM table_source[/code]
L'interface de données entre la procédure d'extraction (SELECT) et celle d'injection (INSERT) est constituée d'une connexion entre les [champs de destination] et les [champs sources]. Connexion qui doit respecter l'ordre, le type et la taille des données sujets du transfert.
Par exemple:
[code]INSERT INTO table2 (A, B) SELECT C, D FROM table1;[/code]
Exige que les champs A, B et C, D soient respectivement égaux dans l'ordre de citation et dans leur type/taille
C'est à dire : A équivalent à C et B équivalent à D dans leur type/taille. sinon, si les types ne sont pas équivalents, il faut appliquer judicieusement des fonctions de conversion de type pour [u]adapter la source à la destination[/u]. Si c'est un problème de taille, la source s'adapte forcément à la destination et l'on risque des troncatures ou des erreurs de données.
Pour stocker durablement cette opération ainsi conçue on peut utiliser une procédure stockée, ainsi, on enrichi notre modèle opérationnel de traitement enregistré dans le schéma de la base de données pour permettre aux développeurs de réutiliser les procédures pour construire des applications.
Exemple de déploiement de cette opération en procédure stockée:
[code]delimiter |
CREATE PROCEDURE transfert1 ()
BEGIN
INSERT INTO table2 (A, B) SELECT C, D FROM table1;
END[/code]
Pour l'exécuter cette procédure stockée on lance la commande: [code]CALL transfert1();[/code]
Tout ça c'est du SQL, et l'avantage de cette méthode d'intégration du modèle physique de données (tables, contraintes, indexes et relations durables) et du modèle opérationnel (triggers, vues, procédures stockées et fonctions) dans la même base de données, est d'abord la standardisation SQL, la réutilisabilité multi-plateforme de développement, la maintenance rapprochée et uni-langage...etc... sans rappeler le partage de charge de mise en œuvre et de fonctionnement des applications.
