Qu'est-ce qu'il manque selon vous à SQL-Server ?

Comment Date envisage de gérer le cas de colonnes non-nulles sans attribut DEFAULT :

Code:

---

1 2 3

create table t1 (c1 int not null, c2 int not null);   create view v1 as select c1 from t1;

---

On fait comment pour insérer dans la vue ?

Bonsoir tout le monde,

Chris Date a dédié un chapitre (environ 40 pages) à la mise à jour des vues dans Database Explorations: Essays on the Third Manifesto and Related Topics (2010).

Je n'ai pas étudié la chose en détail, mais ce qu'il propose c'est la mise en place de règles définies au niveau de la vue qui vont répercuter les mises à jour sur les tables sous-jacentes.

Des "actions de compensation" sont déclenchées lorsqu'un UPDATE/INSERT/DELETE est réalisé sur une vue.

Exemple ci-dessous:

On a deux relvars (deux tables en gros) LS et NLS.
LS contient tous les fournisseurs (supliers) situés à Londres.
NLS contient tous les autres fournisseurs.

Les contraintes CX3 et CX4 assurent le respect de ces deux règles de gestion.

La virtual relvar (vue) S est l'union de LS et NLS.
S nous présente donc tous les fournisseurs.

C'est du Tutorial D, vous traduirez implicitement en SQL à la lecture :lol:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14

VAR LS BASE RELATION { S# S#, SNAME NAME, STATUS INTEGER, CITY CHAR} KEY { S# };   VAR NLS BASE RELATION { S# S#, SNAME NAME, STATUS INTEGER, CITY CHAR} KEY { S# };   CONSTRAINT CX3 IS_EMPTY (LS WHERE CITY = 'London'); CONSTRAINT CX4 IS_EMPTY (NLS WHERE CITY <> 'London');   VAR S VIRTUAL (LS UNION NLS) KEY { S# }

---

Lors d'un DELETE sur S, c'est une action de compensation préalablement définie qui va réaliser les suppressions en cascade.

Code:

---

1 2	ON DELETE s FROM S : DELETE ( s WHERE CITY = 'London' ) FROM LS , DELETE ( s WHERE CITY <> 'London' ) FROM NLS ;

---

Pour chaque ligne "s" supprimée dans S, en fonction de la valeur de l'attribut CITY la suppression est faite sur la bonne table: LS ou NLS.

Idem pour les insertions:

Code:

---

1 2	ON INSERT s INTO S : INSERT ( s WHERE CITY = 'London' ) FROM LS , INSERT ( s WHERE CITY <> 'London' ) FROM NLS ;

---

Voici l'esprit de la chose.

Donc ces actions de compensations pourraient être définies au niveau des vues pour réaliser nos propres insert/update/delete comme ont le fait avec des trigger instead of.

Pour l'insert sans données dans une colonne sans valeur par défaut de l'exemple à Waldar, si le SGBD n'a pas de valeur à insérer une erreur doit être renvoyée au moment de l'insert sur la vue, puisque l'insert dans la table sous-jacente n'est pas possible ?

Salut
fsmrel, je ne vais pas insister sur votre algorithme (juste mais assez simpliste) car je me dis que vous avez relevé des problèmes aux passages. Des problèmes tels que la gestion de clé auto incrémenté, les contraintes de suppression en cascade. Le problème non évident est celui d’un formulaire ouvert sur la vue (facture join reglement). Si je modifie par exemple la date de la facture ou je supprime une ligne, quel doit être le comportement du formulaire? Rafraichir les autres lignes ou laisser tel. Un autre problème est celui de l’insertion*:l’opérateur entre les infos (sans clé) d’une facture déjà existante et une nouveau règlement. Sans clé, comment le SGBD interprète les données de la facture (nouvelle ou existante)? Pour finir je dirais que, vu que l’intégrité des données ne peut être péril, les éditeurs ont intérêt à imposer de tels garde-fou et proposer d’autres alternatives (qui font partie intégrante du domaine des bases de données) plutôt que de créer de gadgets.
Etienne, pourquoi poser des contraintes de sur des tables, créer des vues sur ces mêmes tables et poser encore des contraintes sur les vues?
@+

Bonsoir,

Citation:

---

Envoyé par Waldar

Comment Date envisage de gérer le cas de colonnes non-nulles sans attribut DEFAULT :

Code:

---

1 2 3

create table t1 (c1 int not null, c2 int not null);   create view v1 as select c1 from t1;

---

On fait comment pour insérer dans la vue ?

---

On fait comme pour insérer dans la table (laquelle, en passant, est ici un sac puisqu’elle n’a pas de clé). Les instructions :

INSERT INTO V1 (C1) VALUES (1) ;

et

INSERT INTO T1 (C1) VALUES (1) ;

sont interchangeables, ce qui vaut pour l’une vaut pour l’autre. En l’occurrence (comme l’a signalé le vaillant Oishiiii) il y a rejet de l’opération puisqu’il n’y a pas de valeur par défaut prévue pour la colonne C2.


Pour en dire un peu plus : la vue en cause correspond à une opération de projection et comme dans la discussion traitant des préliminaires de la mise à jour des vues de jointure, je me réfère à ce qu’écrit Date dans An Introduction to Database Systems, Eighth Edition (Addison Wesley), page 311.

Comme on doit parler de prédicat de relvar, Je rappelle au préalable que l’éternel exemple de Date est le suivant (et dont se sert aussi Oishiiii à l’occasion de sa réponse) :

Relvar des fournisseurs :

Code:

---

1 2 3 4 5 6

VAR S BASE RELATION {SNO CHAR, SNAME CHAR, STATUS INTEGER, CITY CHAR} KEY {SNO} ;

---

Qui a pour prédicat PS (son intension si vous préférez, et prenant la valeur soit VRAI, soit FAUX) :

Le fournisseur SNO a pour nom SNAME, il a pour statut STATUS et il est localisé dans la ville CITY.

A signaler que le prédicat d'une relvar intègre les contraintes définies pour cette relvar (par exemple la clé candidate définie par la clause KEY pour la relvar S).

Dans le cas général, soit A une relvar de prédicat PA et dont on partitionne les attributs en deux groupes disjoints, disons X et Y. Considérons X comme un seul attribut composé, même chose pour Y et soit A{X} la projection de A sur X. Soit (x) un tuple (ligne en SQL) de cette projection, laquelle a un prédicat qui ressemble à ceci :

Pour tous les (x), il existe un (y) du domaine des valeurs de Y tel que le tuple (x, y) vérifie le prédicat PS de la relvar S.

Si on considère par exemple la projection S{X} de la relvar S sur SNO, SNAME et CITY, chaque tuple (s, n, c) appartenant à cette projection est tel qu’il existe une valeur t de statut tel que le tuple (s, n, t, c) vérifie le prédicat PS.


Les règles pour mettre à jour A{X} sont les suivantes :

INSERT :
Soit (x) le tuple à insérer et y la valeur par défaut de Y (l’absence de valeur par défaut se traduit par une erreur comme évoqué plus haut), le tuple (x, y) (qui doit respecter le prédicat PA) est inséré dans A.

DELETE :
Tous les tuples de A qui ont la même valeur X que le tuple à supprimer de A{X} sont supprimés de A.

UPDATE :
Soit (x) le tuple à modifier et (x’) le tuple de remplacement. Soit a un tuple de A dont la valeur pour X est égale à x et soit y la valeur de Y dans a. Tous les tuples tels que a sont supprimés de A (sans déclenchement automatique d’actions quelconques ni de contrôles de prédicats). Ensuite, le tuple (x’, y) — qui doit respecter PA — est inséré dans A. (Bien entendu, Date fournit des indications plus précises pour raffiner cette description qui pourrait paraître un peu fruste à d’aucuns).


A propos des valeurs par défaut :

Dans leur ouvrage de référence Databases, Types, and the Relational Model The Third Manifesto (Third Edition), Chris Date et Hugh Darwen laissent le soin aux SGBD de type D (c'est-à-dire se référant à Tutorial D) de définir un mécanisme du genre « valeurs par défaut », mais pas forcément ce lui qu’on connaît traditionnellement en SQL et ils ne veulent pas forcer la main de ceux qui modélisent et proposent ces SGBD. Se reporter aux pages 215 et 425 de l’ouvrage.

Pour ne pas innover, on peut par exemple considérer ici un scénario orienté SQL pour la relvar S :

Code:

---

1 2 3 4 5 6 7 8 9

VAR S BASE RELATION {SNO CHAR, SNAME CHAR, STATUS INTEGER, CITY CHAR} KEY {SNO} DEFAULT {SNAME ''} DEFAULT {STATUS 10} DEFAULT {CITY ''} ;

---

Waldar, ai-je répondu à votre question ?


[EDIT]

A la page 312 de son Introduction, Chris Date donne des exemples de mise à jour d’une vue de projection.

Vue à mettre à jour :

Code:

---

1 2 3 4 5 6 7

SC SNO CITY S1 London S2 Paris S3 Paris S4 London S5 Athens

---

Quelques tentatives caractéristiques de mise à jour de la vue SC :

— La tentative d’ajout dans SC du tuple (S6, Athens) sera couronnée de succès. Au résultat il y aura ajout du tuple (S6, n, t, Athens) dans la relvar de base S, où n et t sont les valeurs par défaut respectives des attributs SNAME et STATUS.

— La tentative d’ajout dans SC du tuple (S1, Athens) échouera parce que le prédicat PS de la relvar S n’est pas respecté (donc celui de la vue SC) : en effet, il y a là une tentative de créer la valeur clé S1 en double.

— La tentative de suppression dans SC du tuple (S4, London) sera couronnée de succès, avec pour conséquence la suppression dans la relvar S du tuple correspondant à S4.

— La tentative de remplacement dans SC du tuple (S1, London) par le tuple (S1, Athens) sera couronnée de succès. Supposons que le tuple correspondant dans la relvar S soit (S1, Smith, 20, London) : il sera remplacé par le tuple (S1, Smith, 20, Athens).

— La tentative de remplacement dans SC du tuple (S1, London) par le tuple (S2, London) échouera. J’espère que tout le monde saura expliquer pourquoi. :lol:

Citation:

---

Envoyé par fsmrel

Waldar, ai-je répondu à votre question ?

---

Oui parfaitement !

Ok Waldar.

Pour être plus complet, j'ai ajouté à la fin de mon message quelques exemples de mise à jour d'une vue de projection.

Bonjour

Citation:

---

Envoyé par fsmrel

Ok Waldar.

Pour être plus complet, j'ai ajouté à la fin de mon message quelques exemples de mise à jour d'une vue de projection.

---

Pour les vues de jointures...?
François, sachez que j'ai un profond respect pour votre rang:king:, d'ailleurs si j'avais le moyen je téléchargerais toutes vous interventions:merci:. Mais je préfère rester sincère dans ce respect.
Si c'est pour ma propre formation alors la réponse de Oishiii me suffit amplement. Mais n'allons pas faire croire ce qui na pas été démontré!!!
@+

Citation:

---

Envoyé par alassanediakite

je ne vais pas insister sur votre algorithme (juste mais assez simpliste) car je me dis que vous avez relevé des problèmes aux passages. Des problèmes tels que la gestion de clé auto incrémenté, les contraintes de suppression en cascade.

---

Ce que j’ai décrit n’est en rien un algorithme, mais un ensemble de règles faciles à comprendre, et surtout incontournables et inviolables avec leurs prémisses et leurs conséquences. Ne mélangez pas tout, les problèmes que vous évoquez sont orthogonaux. L’auto-incrémentation des clés ne concerne pas le Modèle Relationnel de Données, c’est une facilité proposée par tel ou tel SGBD à partir d'une certaine de ses versions et n’ayant pas d’incidence sur les règles énoncées par Date dans son Introduction. Évidemment vu l’abondance de la matière traitée par Date et Darwen je n’ai pas parlé des effets secondaires mais comme je vous l’ai dit :

Citation:

---

Envoyé par fsmrel

Chris Date étudie ensuite de façon systématique et détaillée les conditions dans lesquelles une mise à jour d’une vue « de jointure » est acceptée ou doit être rejetée, selon que A et B entretiennent des relations de type un-à-un, un-à-plusieurs ou plusieurs à plusieurs. Je vous invite à le suivre dans son étude (aux pages 315-318 de son ouvrage).

---

En ce qui concerne les suppressions en cascade, je vous invite par conséquent à suivre l’exemple d’Oishiiii qui a pris la peine de fouiller dans le chapitre 10 « How to Update Views » de l’ouvrage de Date et Darwen : Database Explorations: Essays on the Third Manifesto and Related Topics (Trafford 2010). Oishiiii s’est penché avec courage et raison sur les « actions compensatoires » (compensatory actions). Je cite et traduis D & D :

Action compensatoire :
« Mise à jour effectuée automatiquement par le système, en sus d’une demande de mise à jour, l’objet étant d’éviter une violation d’intégrité qui à défaut pourrait avoir lieu. Une opération de suppression en cascade en est un exemple caractéristique. Ce genre d’action devrait faire l’objet d’une déclaration pour elle-même et les utilisateurs en avoir la connaissance, c'est-à-dire savoir à quel moment leurs requêtes de mise à jour sont des raccourcis pour un ensemble en réalité plus complet d’actions définies, sans quoi ils pourraient penser à une violation potentielle du Principe d’affectation » ⁽¹⁾.

Allez Bugs Bunny, 40 pages à lire, c'est jouable et vous aurez les réponses à vos interrogations.

Citation:

---

Envoyé par alassanediakite

quel doit être le comportement du formulaire?

---

Plaît-il ? Qu’entendez-vous par formulaire ? Ce concept entre dans le cadre de quelle théorie ?

Citation:

---

Envoyé par alassanediakite

Sans clé, comment le SGBD interprète les données de la facture nouvelle ou existante)?

---

Une table sans clé n’est qu’un sac et le Modèle Relationnel de Données rejette cette chose-là. Voyez aussi la réponse que j’ai faite à Waldar : la clé participe au prédicat d’une relvar et en cas de violation, une mise à jour de vue sera rejetée. Quant au SGBD, s’il est conforme au Modèle Relationnel de Données, son comportement sera le bon. A défaut il fait ce qu’il veut, avec tous les aléas et bugs :D possibles.

Citation:

---

Envoyé par alassanediakite

Pour finir je dirais que, vu que l’intégrité des données ne peut être péril, les éditeurs ont intérêt à imposer de tels garde-fou et proposer d’autres alternatives (qui font partie intégrante du domaine des bases de données) plutôt que de créer de gadgets.

---

De quels garde-fous parlez-vous ? Donnez des exemple, même chose pour les gadgets.


-----------------------------------
⁽¹⁾ Principe d’affectation
Suite à affectation de la valeur v à la variable V, la comparaison v = V doit être évaluée à VRAI. Truisme ? Soit X une variable SQL, peu importe son type, et affectons x à X : si x est le bonhomme NULL, la comparaison X = x est évidemment évaluée à UNKNOWN. Si la variable SQL C est de type CHAR(3), la comparaison C = 'AB' est évaluée à FAUX puisque la chaîne de caractères 'AB' ne comporte que deux caractères au lieu des trois requis.

Citation:

---

Envoyé par alassanediakite

Mais n'allons pas faire croire ce qui na pas été démontré!!!

---

C'est-à-dire ? Qu’est-ce qui n’a donc pas été démontré ?

Citation:

---

Envoyé par alassanediakite

Pour les vues de jointures...?

---

Votre cas de figure entre dans la catégorie des liens de un à plusieurs déjà mentionné. Il peut donc être rapproché du célèbre, sempiternel et immuable exemple de Chris Date, francisé à ma façon et dans lequel les relations entre les fournisseurs (F) et les livraisons de pièces par les fournisseurs (FP) entrent aussi dans la catégorie un-à-plusieurs (avec contrainte d’intégrité référentielle entre F et FP) :

http://fsmrel.developpez.com/basesre...s_Livr_110.png

Soit la vue FFP définie par la jointure (naturelle) :

F JOIN FP

http://www.fsmwarden.com/developpez_...ti)vue_FFP.png

— La tentative d’ajout dans FFP du tuple (S4, Catherine, 20, Lille, P6, 100) réussira et aura pour effet l’ajout du tuple (S4, P6, 100) dans la relvar FP puisqu’il en est absent. La partie (S4, Catherine, 20, Lille) est déjà présente dans F : il ne passe rien de ce côté-là.

— La tentative d’ajout dans FFP du tuple (S5, Alain, 30, Arles, P6, 100) réussira et aura pour effet l’ajout du tuple (S5, P6, 100) dans la relvar FP.

— La tentative d’ajout dans FFP du tuple (S6, Germaine, 20, Lille, P6, 100) réussira et aura pour effet l’ajout du tuple (S6, Germaine, 20, Lille) dans la relvar F, ainsi que du tuple (S6, P6, 100) dans la relvar FP.

— La tentative d’ajout dans FFP du tuple (S4, Catherine, 20, Arles, P6, 100) échouera. En effet, la partie (S4, Catherine, 20, Arles) n’existe pas dans F, donc elle est à y insérer, mais le prédicat de F ne serait alors pas respecté (clé en double).

— La tentative d’ajout dans FFP du tuple (S1, Salsa, 20, Lille, P1, 400) échouera. Pourquoi ?

— La tentative de suppression dans FFP du tuple (S3, Bernard, 30, Paris, P2, 200) réussira et aura pour effet la suppression dans F du tuple (S3, Bernard, 30, Paris) et dans FP la suppression du tuple (S3, P2, 200).

— La tentative de suppression dans FFP du tuple (S1, Salsa, 20, Lille, P1, 300) « réussira » (sous réserve de ce qui est dit dans la note qui suit immédiatement) avec pour effet la suppression dans F du tuple (S1, Salsa, 20, Lille) et dans FP la suppression du tuple (S1, P2, 300).
Note : en réalité, le succès de l’opération dépendra de la règle de suppression associée à la clé étrangère connectant F et FP. Si l’option est CASCADE, les autres tuple S1 seront supprimés de FP. Si l’option est NO CASCADE (RESTRICT, NO ACTION en SQL), la présence des autres tuples S1 fera que la tentative de suppression du tuple (S1, Salsa, 20, Lille, P1, 300) échouera.

— La tentative de modification dans FFP du tuple (S1, Salsa, 20, Lille, P1, 300) en (S1, Salsa, 20, Lille, P1, 400) réussira, avec pour effet le remplacement dans FP du tuple (S1, P1, 300) par le tuple (S1, P1, 400).

— La tentative de modification dans FFP du tuple (S1, Salsa, 20, Lille, P1, 300) en (S1, Salsa, 20, Arles, P1, 400) réussira, avec pour effet le remplacement dans F du tuple (S1, Salsa, 20, Lille) par le tuple (S1, Salsa, 20, Arles) et le remplacement dans FP du tuple (S1, P1, 300) par le tuple (S1, P1, 400).

— La tentative de modification dans FFP du tuple (S1, Salsa, 20, Lille, P1, 300) en (S6, Salsa, 20, Arles, P1, 300) « réussira » (sous réserve de ce qui est dit dans la note qui suit) avec pour effet le remplacement dans F du tuple (S1, Salsa, 20, Lille) par le tuple (S6, Salsa, 20, Arles) et le remplacement dans FP du tuple (S1, P1, 300) par le tuple (S6, P1, 300).
Note : en réalité, le succès de l’opération dépendra de la règle de modification associée à la clé étrangère connectant F et FP. Si l’option est CASCADE, la modification sera répercutée sur les autres tuple S1 dans FP. Si l’option est NO CASCADE (RESTRICT, NO ACTION en SQL), la présence des autres tuples S1 dans FP fera que la tentative de modification du tuple (S1, Salsa, 20, Lille, P1, 300) échouera.

Bonjour
François, (j'étais pas absent, je fouillais:oops:)

Citation:

---

Une table sans clé n’est qu’un sac et le Modèle Relationnel de Données rejette cette chose-là.

---

SQLpro affirme qu'une table (il ne précise pas sans ou avec clé) SQL est un sac. Il le compare même aux sacs des dames!

Citation:

---

La tentative d’ajout dans FFP du tuple (S1, Salsa, 20, Lille, P1, 400) échouera. Pourquoi ?

---

réponse: la facture ne peut avoir plus d'une fois le même produit!
Pour conclure (pour ma part) ce point: j'ai un peu lu chez Gardarin, Philipe Rigaux, sqlpro (son livre et son site) et André Gamache; Finalement je retiens l'explication par sqlpro des 12 règles de Codd dans le chapitre "règle 6".
Pour le livre (introduction aux bases de données) de C. Date, je le mets dans mon agenda. Le titre que vous donnez semble ne pas exister en français!
@+++

Le 19/05/2008 à 12H13 Fabien (oadin) a posé la question suivante :

Citation:

---

...
Nous avons passé nos serveurs en mirroir ce week-end, le problème est la taille du journal de transaction le jour du rebuild des index.
Il y a des moyens mal propre qui consiste a faire un backup directement après full et après effacer tous les fichiers de log.
Mais ça me force a avoir 2 fois la taille de ma base de donnée minimum (une fois pour mon backup, une fois pour mon journal des log qui fait la même taille que ma base de donnée ou presque).
On a regardé avec notre consultant sql si il existait un moyen propre de réduire cette taille de log, mais il n'a pu me fournir aucune solution valable.
Si ce n'est défragmenter qu'une partie de mes index (pas tous), ou de faire des backups du log pdt l'opération de reconstruction d'index... (je ne vois pas la différence que j'aurai entre un fichier de 40go et 10 fichiers de 4go ).
Il n'a pas pu me donner une méthode de reconstruction d'index n'utilisant pas le journal de transaction, on utilise un maintenance plan actuellement pour réorganiser notre base de données le week-end.
Nous sommes en sql server 2005 SP2 x64 avec des bases de donnée en compatibilité 8.0 rien de compliqué sur nos tables sauf des accès sql, du mirroring

---

Voici la réponse proposée par les experts SQL Server

1. Sauvegarde Complète de la base
2. BACKUP LOG BasedeDonnées WITH TRUNCATE_ONLY
3. Suppression du fichier de backup log / ou déplacer le fichier de backup log
4. ...

=> Ma contribution
Sous ORACLE, il existe l'option NOLOGGING qui permet d'éviter d'écrire dans le journal de transaction (JT) des instructions SQL.
Cette option NOLOGGING permet d'éviter le grossisement du JT lors des opérations de maintenance :
* MERGE (INSERT, UPDATE,DELETE)
* CREATE TABLE, ALTER TABLE
* CREATE INDEX, ALTER INDEX ...REBUILD

=> Mes Questions
Je ne sais pas si cette option est implémentée sous SQL Server 2012 !?
Par ailleurs est ce quelqu'un peut nous donner la liste exhaustive des commandes SQL qui ne sont pas inscrites dans le JT lorsqu'une base est en mode de restauration SIMPLE ?

Merci d'avance ;)

Cf http://www.developpez.net/forums/d54...x/#post6787849

++

SQL Standard a une liste de mots clés. Cette liste de mots clés n'est pas figée, elle évolue. La norme SQL fait la différence entre mots clés réservés et mots clés non réservés. Au sens strict ce sont les mots clés réservés qui constitue la liste des mots clés. Il est donc recommandé de ne pas utiliser les mots clés réservés comme identificateurs ou noms d'objets. Généralement les mots clés non réservés sont les noms d'objets systèmes (tables, fonctions, procédures, ... systèmes). Dans la documentation en ligne de SQL Server on a le tableau :
* des mots clés réservés par SQL Server
* des mots susceptibles d'être réservés dans les prochaines versions de SQL Server.

Mais SQL Server n'a pas implémenté de vue système (DMV) ou procédure système qui permet de lister ces mots clés réservés !

Quel est l'intérêt d'implémenté de telle vue (DMV) ? Quelle utilité ?

1. D'abord pour des raisons d'ordre didactique : lors des training T-SQL c'est beaucoup plus pratique de monter les mots clés en exécutant une requête du genre :

Code:

---

SELECT * FROM sys.reserved_words

---

que de renvoyer les participants sur des sites internet ou pire de faire de photocopie de tableau de mots clés !

2. Pour lister les tables, vues, ... qui ont pour nom des mots clés
On peut me dire que c'est facile à faire il suffit de créer une table de mots clés et puis ..... mais on y gagne pas en productivité
Regarder par exemple sous ORACLE, pour répondre à de tel besoin il suffit de faire :

Code:

---

1 2 3 4 5

SELECT object_name,object_type,owner,keyword FROM dba_OBJECTS,v$reserved_words WHERE object_name=keyword AND reserved = 'Y' AND owner = 'mon_schema';

---

3. Pour lister les colonnes (de tables) ... qui ont pour nom des mots clés

4. Pour mettre en place des règles de création des objets dans la base

5. ...........................

ça pourrait être intéressant de voir un jour cette DMV sys.reserved_words dans MS SQL Server !

Citation:

---

ça pourrait être intéressant de voir un jour cette DMV sys.reserved_words dans MS SQL Server !

---

Pas bête !!! Tu peux faire une entrée sur connect pour cela.

++

Citation:

---

Envoyé par mikedavem

Pas bête !!! Tu peux faire une entrée sur connect pour cela.
++

---

c'est fait

Ce serait bien si Sql Server gérait l'utf8... Je cherche à faire des BCP ou bulk insert de fichiers encodés en UTF8 et je suis obligé de ruser pour les intégrer facilement. Ou alors j'ai raté certaines choses...

code page 65001?

Le moteur SQL Server gère l'UTF8 et depuis 2012 l'UTF16

ah autant pour moi :oops:

Pour avoir été obligé d'écrire beaucoup de sql dynamique ces derniers temps (import de fichiers à colonnes variables et n'entrant pas dans le modèle), j'aimerai que le langage soit plus dynamique et plus souple à l'utilisation, permettant de remplacer dynamiquement certaines syntaxes fixes. Par exemple :

1. Pivot (unpivot)
   
   • liste de colonnes dynamique :
     pivot ( max(val) for col in (select label from listecol))
   • pivot sur donnée unique (donc avec une erreur si la donnée existe 2 fois) :
     pivot ( val for col in ("C1", "C2", "C3"))
   • possibilité de mettre un valeur calculée :
     pivot ( case val when 1 then 'N/A' else isnull(autre_val, 'erreur) for col in ("C1", "C2", "C3")) )
   • et du coup, le mélange de l'ensemble :
     pivot ( case val when 1 then 'N/A' else isnull(autre_val, 'erreur) for col in (select label from listecol))
   
   
2. Cast
   
   • Pouvoir donner dynamiquement le type :
     create matable (myval varchar(255), montype varchar(255))
     insert into mytable(myval, montype) select '5', 'int'
     select cast(myval as montype) from matable
   
   
3. Executesql en fonction
   
   • execution de code
     create matable (myval varchar(255), montype varchar(255), moncontrole varchar(255))
     insert into mytable(myval, montype, moncontrole) select '5', 'int', 'case when myval > 3 then 1 else 0 end'
     select cast(myval as montype) from matable where executesql(moncontrole) = 1
   • execution de fonction
     create matable (myval varchar(255), montype varchar(255), moncontrole varchar(255))
     insert into mytable(myval, montype, moncontrole) select '5', 'int', 'udf_controle(myval)'
     select cast(myval as montype) from matable where executesql(moncontrole) = 1
   
   
4. Création de table
   Pouvoir créer des tables (au moins temporaires) dynamiquement sans avoir à faire du sql dynamique (pas d'idée de syntaxe pour ça...)