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

**iberserk** · 15/03/2011, 17h29

Je viens de parcourir la discussion initiale (et initié par fsmrel) et je rebondi sur l'absence de TRY-CATCH comme regretté par ZINZINETI:

http://msdn.microsoft.com/fr-fr/library/ms175976.aspx

**SQLpro** · 15/03/2011, 17h50

Envoyé par iberserk

Je rejoins Waldar sur SSIS...
Le boulot à achever est énorme... à part de nouvelles taches (souvent un peu folklorique dailleurs

) peu de changement dans la version 2008 et l'EDI est toujours aussi lent.

INTERVAL j'en ai rêvé tous les jours pour modéliser le SI des hôpitaux (vacations de chirurgiens, séjours dans les chambres etc.).

Il est souvent plus simple d'utiliser une datetime + un offset (par exemple en minute) qu'un interval. Ne suffit plus que de prévoir des fonctions de conversion pour l'affichage et la saisie.

Pour ma part, modélisant un ERP dans le domaine de l'hopital nous avons choisit de n'utiliser que des offset et des durée en minutes.
Par exemple les soins sur un patient sont en offset par rapport à la date du séjour, tant est si bien que si le séjour est retardé, les retard des soins sont synchronisée puisque ce sont des offset.
Bien entendu dans la visualisation des données, les utilisateur saisissent des datetime et ce sont les vues qui simule le tout !

A +

**iberserk** · 15/03/2011, 20h15

Il est souvent plus simple d'utiliser une datetime + un offset (par exemple en minute) qu'un interval. Ne suffit plus que de prévoir des fonctions de conversion pour l'affichage et la saisie.

Pour ma part, modélisant un ERP dans le domaine de l'hopital nous avons choisit de n'utiliser que des offset et des durée en minutes.
Par exemple les soins sur un patient sont en offset par rapport à la date du séjour, tant est si bien que si le séjour est retardé, les retard des soins sont synchronisée puisque ce sont des offset.
Bien entendu dans la visualisation des données, les utilisateur saisissent des datetime et ce sont les vues qui simule le tout !

C'était géré de la même manière pour ce qui concernait les durée d'intervention, durée de vacation des chirurgiens...

Le plus de l'INTERVAL permettant de remonter les chevauchement par exemple s'est fait sentir plus sur la gestion de l'occupation des blocs opératoire/ chambre de patient notamment pour la recherche automatisée (placement automatique des patients dans des chambres par exemple) de "créneaux" libre et suffisamment longs...

Mais vous avez raison le problème survenait car il y avait deux datetime..

les vues qui simule le tout

Leur côté féminin qui ressort

**SQLpro** · 17/03/2011, 16h21

Pour les chevauchements, n'hésitez pas à placer des contraintes de non overlapping. Créez la fonction UDF OVERLAPS comme je l'ai indiqué ici : http://sqlpro.developpez.com/cours/gestiontemps/#L1.2.2
et utilisez là dans un CHECK au niveau table (en l'encapsulant dans une autre UDF spécifique) ou bien dans un trigger.

Je suis en train de rédiger un article sur les contraintes complexes avec SQL Server pour un livre qui sortira aux US (MVP Deep Dive II). Je traite ce genre de sujets....

A +

**Ptit_Dje** · 28/04/2011, 13h03

Je la rajoute ici:

Des contained/partially contained schema.

**hmira** · 04/05/2011, 19h58

Moi, ce que je souhaiterais comme amélioration, c'est très simple, et très loin du moteur de la base etc..
Je voudrais que sous SSMS, dans la grille "Résultats", que l'on puisse, comme sous Excel, pouvoir "Figer les volets", généralement constitué des colonnes de la clé primaire qui resteraient figées à gauche et pouvoir ainsi défiler les autres colonnes horizontalement. Ce serrait très pratique pour consulter et vérifier le contenu d'une table ou d'une requête.

A+

**WOLO Laurent** · 06/05/2011, 15h16

Envoyé par 7gyY9w1ZY6ySRgPeaefZ

Je te rejoins.
Sans parler de la notion de package, inexistante sous SQL Server qui permettrait de mettre un peu d'ordre quand il y a beaucoup de code.

Les assemblies introduitent par .net ne sont elle pas suffisantes ?

Invité · 06/05/2011, 15h29

Envoyé par WOLO Laurent

Les assemblies introduitent par .net ne sont elle pas suffisantes ?

Je connais pas vraiment. Je vais regarder ça de plus près, merci.

**Sergejack** · 09/05/2011, 12h16

+ Support des expressions régulières.
+ INSERT .. FROM (et ainsi permettre des clause OUTPUT intéressantes)

Envoyé par SQLpro

100 ans, minimum... La gestion d'erreur dans une fonction est une abération !!!!
En effet ce n'est pas à la fonction de prévoir son plantage, c'est à la requête de le faire....

A +

Au nom de quoi, serait-ce une aberration ?

Je ne vois pas en quoi il est aberrant de souhaiter pouvoir par exemple faire une fonction qui converti une chaîne de caractère en date et renverrai NULL en cas d'erreur (plantage avec CONVERT) de conversion.

**iberserk** · 09/05/2011, 13h36

INSERT .. FROM (et ainsi permettre des clause OUTPUT intéressantes)

De quoi parlez vous?

**Sergejack** · 09/05/2011, 14h40

Envoyé par iberserk

De quoi parlez vous?

Il existe les clauses DELETE... FROM..., UPDATE... FROM... (qui permettent entre autres l'emploie de la clause OUTPUT pour récupérer des données supplémentaires à celles des tables inserted/deleted) mais pas INSERT... FROM...
Bien que depuis v2008 MERGE existe et l'abscence de INSERT... FROM... doit pouvoir s'en countourner plus simplement.

**alassanediakite** · 10/05/2011, 11h48

Envoyé par SQLpro

Pour ma part je souhaiterais :
2) les trigger before
...

Quelle différence avec INSTEAD OF?

**iberserk** · 10/05/2011, 11h49

Quelle différence entre INSTEAD OF?

Et bien il s'execute en amont et ne le remplace pas...

**alassanediakite** · 10/05/2011, 11h54

Before: avant= peut remplacer, accepter ou annuler les effets.
Instead of: remplace=peut remplacer, accepter ou annuler les effets
Je ne vois aucune différence!