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
Version imprimable
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
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 +
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...Citation:
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 !
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..
Leur côté féminin qui ressort :mrgreen:Citation:
les vues qui simule le tout
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 +
Je la rajoute ici:
Des contained/partially contained schema.
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+
+ Support des expressions régulières.
+ INSERT .. FROM (et ainsi permettre des clause OUTPUT intéressantes)
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.
De quoi parlez vous?Citation:
INSERT .. FROM (et ainsi permettre des clause OUTPUT intéressantes)
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.
Et bien il s'execute en amont et ne le remplace pas...Citation:
Quelle différence entre INSTEAD OF?
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!
instead of + accepter = coder soi-même un insert.
Instead of ne peut pas accépter justement...Citation:
Instead of: remplace=peut remplacer, accepter ou annuler les effets
Donc ce n'est pas lui qui le fait c'est bien vous de manière manuelle:ccool:Citation:
... si il peut bien le faire. Il suffit de reprendre les données de INSERTED et DELETED.
Une solution de Load Balancing sans passer par de la réplication de type MERGE.
Précisez un peu votre penséeCitation:
Une solution de Load Balancing sans passer par de la réplication de type MERGE.
++