Discussion :

[Khaoula.85]

Bonjour,

Je voudrais écrire une procédure stockée qui me permet de créer une table dans une base de données.
Ca me semble évident d'écrire ces lignes :

Code :

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

1
2
3
4
5
use basePFA
create procedure cTable 
as
CREATE TABLE  nameTable
go

Je ne sais pas qu'est-ce que je dois ajouter pour rendre ma requête exécutable.
Merci de votre aide !

[Ry_Yo]

Euhh.. il faudrait être plus précis...

Car il me semble que créer une table sans spécifié au moins 1 colonne et son typage sera rejeté quelque soit le SGBD....

donc un simple CREATE maTable sans rien derrière écrit seul ou dans une procédure stockée ne fonctionnera pas....

Et la demande devrait être reformulé, car si on la lit... tu demandes à faire un CREATE...

bref pas tout compris au sens profond de ta demande....

[Khaoula.85]

Merci de ta réponse
Au fait, je veux créer une procédure stockée qui -lors de son appel- me permettra de créer une table.
J'ai pensé à définir quelques paramètres pour ma procédure genre nameTable et columnOne, ce qui donne :

Code :

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

1
2
3
4
5
6
7
8
9
use basePFA
create procedure cTable 
@nameTable varchar2(50),
@colTable int
as
begin
CREATE TABLE @nameTable(@colTable int)
end
go

Est-ce correct ?
Le problème est que les colonnes seront les mêmes dans toutes les tables, donc le fait de définir une seule colonne (colTable) comme je l'ai fait me semble insensé, encore lui définir un type par défaut (int)

[Snipah]

Et n'oublie pas de préciser ton sgbd.

[Khaoula.85]

J'utilise SQL Server 2008.

[Waldar]

Question bête, mais pour quoi faire ?
Pourquoi vouloir recréer un CREATE TABLE alors que vous l'avez déjà ?

[Khaoula.85]

Je me suis mal exprimée peut-être. Il s'agit de développer une console d'administration d'un serveur SQL Server à distance.
Donc, je veux définir des procédures stockées pour les appeler après, je vais aussi devoir créer des procédures pour mettre à jour des tables, pour les supprimer, pour créer des triggers, les supprimer, ajouter des indexes...etc.

Les services de l'application vont faire un appel de la procédure stockée à chaque fois où le client désire créer un objet de la base.

[cavo789]

Avant de le faire par procédure stockée; pourquoi ne pas essayé de le faire directement.

Change ton code comme ceci :

Code :

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

1
2
3
4
5
6
7
8
9
10
 
USE basePFA
GO
DECLARE @nameTable varchar2(50)
DECLARE @colTable int
 
SET @nameTable = 'Table1'
SET @colTable = 'Column1'
 
CREATE TABLE @nameTable(@colTable int);

Ainsi, tu obtiendrais le même résultat mais cela te permet de comprendre si ton code fonctionne et si pas, sur quelle ligne se trouve ton erreur.

Et ici, j'ai comme l'impression que ton code ne pourra pas fonctionner car, dans ce cas précis, tu devrais passer par du dynamic SQL c-à-d coder ton instruction dans une chaîne de caractères puis de faire un sp_executeSQL ou un simple EXEC. Voir ici http://www.sqlteam.com/article/intro...mic-sql-part-2

[Ry_Yo]

Perso si je devais faire ce genre d'outil, ça serait à l'appli de construire ma requête correctement, et le bouton valider ne ferait qu'envoyer une bête requête de CREATE/UPDATE/DELETE (construite au fur et à mesure des choix de l'utilisateur) au serveur....

[cavo789]

Et ce serait une très très mauvaise idée. Préparer ton SQL statement puis l'envoyer à ta db revient à ouvrir tout grande la porte pour le SQL injection.

Normallement, tu devrais UNIQUEMENT coder ton SQL dans SQL Server (sous forme de stored procedure p.e.) et limiter tes appels à des exécutions de stored procedure.

[Ry_Yo]

Euhh.... j'ai pas tout compris...

Prenons un exemple... si je développe un programme de gestion... je serais bien obliger de créer des fenêtres de paramétrages de mes différentes tables dans ma BdD ? et donc écrire côté programmes des requêtes INSERT et autre ? non ? En tout cas c'est comme ça que je fais (qui est peut être mal) depuis que je programme.... j'ai une variable qui contient mes requêtes d'UPDATE, INSERT, SELECT, etc... et je les passe à ma BdD via oledb ou autre selon les cas....

Bref je pense que je n'ai pas compris ta remarque sinon cela voudrais dire que je suis depuis toujours un très mauvais codeur (qui ma foi peut aussi être vrai dans tous les cas )

[Snipah]

Dans beaucoup de cas Ry_Yo, ton appli peut se contenter de rassembler des paramètres pour les envoyer à une procédure stockée ou une fonction.

Par exemple, tu crées une procédure stockée qui te permet d'ajouter un enregistrement dans une table : elle prend en paramètre les valeurs de chaque champs, et ton appli fait appel à cette procédure avec les paramètres voulus au lieu de faire directement un 'insert'.

[Ry_Yo]

Ah ok ! Je comprends le principe...

C'est comme si on faisait de la POO mais avec une BdD, on crée un max de "méthode" (traduit par fonction scalaire et autre...) et côté appli on pioche uniquement dans ce jeu de méthode...

Pas bête

Par contre à la fin, selon la taille de l'appli, il va y avoir un max de procédure / fonction dans la base...

Ben je vais essayer de changer mes habitudes pour voir...

Merci

[Snipah]

Par contre à la fin, selon la taille de l'appli, il va y avoir un max de procédure / fonction dans la base...

Si tu t'organises bien, en regroupant tes proc/fonctions par packages, ça devrait pas être problématique

[cavo789]

Bonjour

Loin, très loin de moi l'idée d'émettre des doutes par rapports à la qualité de ta programmation, Ry_yo.

Ci-après un super lien vers une webcast pour bien comprendre ce qu'est le SQL Injection. En plus, c'est en Français pour ne rien gâcher.

http://www.microsoft.com/france/visi...6-e9852f0f828a

En gros, qu'est-ce que le SQL Injection : c'est une technique de codage qui permet à une application d'envoyer des instructions SQL à une base de données. Si ton application envoie une instruction "SELECT ... FROM ...", la base de données retournes un jeu d'enregistrement mais quid si l'application fait un "DELETE FROM ..." ? Lorsque un hacker essaie de pénétrer une base de données; il peut le faire au moyen d'un programme qui envoi des commandes SQL et les détourne c-à-d remplace ou annihile l'instruction originelle et la remplace par une autre. La video est très claire à ce sujet.

Comme cela a été répondu par Snipah, il faut que ta base de données contiennent des procédures stockées, des fonctions, des vues, ... que tu vas te contenter d'appeller depuis ton code en passant les paramètres adéquats. Ainsi, ta base de données contient toutes la logique au niveau des données (data layer) et ton application va se contenter de faire des exec / select.

Cette manière de travailler offre plusieurs avantages : réutilisation du code, diminution de la charge réseau, meilleure vue des transactions, garanti une meilleure sécurité, ...

Par contre à la fin, selon la taille de l'appli, il va y avoir un max de procédure / fonction dans la base...

C'est exact. Ici, je te préconise de travailler avec des schémas; cela permet de regrouper les mêmes types de fonctions ensemble. Par exemple, j'utilise le schéma Reporting pour toutes les vues, fonctions et stored procedures qui sont utilisés dans une optique de reporting. Et je gère la sécurité à "Read-Only" pour ce schéma. Ainsi, il devient tout simplement impossible de faire du dégat à ma db avec une attaque de SQL Injection (si tant est que le hacker réussit à le faire) vu que l'utilisateur reporting n'a qu'un accès très très limité aux données.

[Ry_Yo]

Bonjour

Loin, très loin de moi l'idée d'émettre des doutes par rapports à la qualité de ta programmation, Ry_yo.

T'inquiète pas de ce côté, j'ai appris à coder sur le tas et sans guide... Donc tu peux émettre des doutes, car je doute souvent moi-même de la qualité de mes applis (au niveau maintenance et évolutions...), et d'après ce que j'ai lu sur ce forum dans la section dev., je fais parti de la catégorie des bidouilleurs

De ce fait, je suis toujours ouvert quand des gens essai de m'expliquer la bonne façon de faire, même si en pratique selon la demande/temps du client je fais au plus court

...
C'est exact. Ici, je te préconise de travailler avec des schémas;...

Je ne me suis jamais servi de schema car comme vous l'aurez compris, je faisais très peu de procédure stockée... je vais essayer de trouver un p'tit papier sur le sujet, histoire d'être plus cultivé

Merci pour vos conseils.

[cavo789]

Pour simplifier : un schéma, c'est comme un dossier sous Windows. Tu vas y stocker des "fichiers" et tu vas assigner des droits d'accès au dossier (telle personne peut accéder en lecture, telle personne en lecture/écriture et les autres, non reprises dans ta liste, n'auront aucun accès).

Un schéma est donc un container de tables, vues, stored procedures, fonctions, ... bref, d'objets SQL Server. L'avantage est de permettre de gérer la sécurité au niveau du schéma et plus individuellement au niveau des objets; un par un. C'est aussi un excellent moyen de regrouper des objets (un schema RH qui va regrouper les objets concernant les ressources humaines, un schéma Sales ... pour tout ce qui a attrait à la vente, ...).

[Khaoula.85]

Bonsoir,
J'apprends des choses en suivant la discussion, merci.
Je pense que j'ai trouvé une idée mais sur Oracle, qui est la suivante :

Code :

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
 
CREATE OR REPLACE PROCEDURE CreateDynamicTables(
p_Method IN VARCHAR2)
AUTHID CURRENT_USER AS
v_CreateString1 VARCHAR2(100) :='CREATE TABLE Etudiants (f1 NUMBER)';
v_CreateString2 VARCHAR2(100) :='CREATE TABLE Professeurs (f1 NUMBER)';
v_Dummy INTEGER;
v_CursorID INTEGER;
BEGIN
  IF p_Method = 'DBMS_SQL' THEN
    v_CursorID := DBMS_SQL.OPEN_CURSOR;
    DBMS_SQL.PARSE(v_CursorID, v_CreateString1, DBMS_SQL.NATIVE);
    DBMS_SQL.CLOSE_CURSOR(v_CursorID);
  ELSE
    EXECUTE IMMEDIATE v_CreateString2;
  END IF;
  END CreateDynamicTables;

D'après ce que j'ai compris, il s'agit de la création des tables dynamiques. Il m'est archi compliqué de trouver un équivalent sous SQL Server

[Ry_Yo]

J'ai pas testé si c'est possible, mais les tables sys.object, sys.tables, etc...
Contiennent la structure des tables et les différents renseignement (dépendance, colonne, etc...). Donc peut être en attaquant directement la base master cela devrait fonctionner ?

[Khaoula.85]

Bonsoir,
Voici, j'ai trouvé la solution à mon problème en SQL dynamique :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
CREATE PROCEDURE Ctable
                @nameTable VARCHAR(50),
                @col       VARCHAR(50)
AS
  BEGIN
    DECLARE  @sql VARCHAR(1000)
    SET @sql = 'CREATE TABLE '
                 + @nameTable
                 + '('
                 + @col
                 + ' int)'
    EXEC( @sql)
  END
GO

A bientôt !