Bonjour à tous !
Tout d'abord, je tiens à formuler ici un GRAND merci à Radu - bon anniversaire ;-) - pour l'astuce que je vais vous présenter ci-dessous : Comment connecter SSIS à un classeur Excel 2007 via OLE DB.
En effet, le fournisseur OLE DB Microsoft Jet ne permet pas de se connecter à Excel 2007.
En revanche, il est possible de se connecter à un classeur Excel 2007 via le fournisseur Microsoft Office 12.0 Access Database Engine OLE DB Provider.
La première étape consiste à créer la connexion OLE DB et à en spécifier le fournisseur. Puis, la source de données, qui est évidemment le fichier que vous souhaitez utiliser.
Ce qui parait surprenant, c'est qu'à ce stade, la connexion ne fonctionne pas.
Il vous faut alors prendre vos petites mimines et dans l'onglet All des propriétés de votre connexion OLE DB taper la valeur "Excel 12.0" dans les propriétés étendues...
Oh, miracle de la technologie, la connexion devient alors opérationnelle...
jeudi 22 mars 2007
mardi 20 mars 2007
SQL Server 2005 plus strict que la norme XSD du W3C
Bonjour à tous !
Suite à une question pertinente d'un client, j'ai cherché à comprendre pour quelle raison un schéma XSD me semblant parfaitement valable me générait une erreur à l'insertion des données...
Une fois le problème isolé, j'ai pu effectuer le test suivant :
DROP TABLE TestXML
GO
DROP XML SCHEMA COLLECTION TestDateRestriction
GO
DROP XML SCHEMA COLLECTION TestDateRestrictionTimeZone
GO
CREATE XML SCHEMA COLLECTION TestDateRestriction
AS
'<?xml version="1.0" encoding="utf-8"?>
<xsd:schema targetNamespace="http://tempuri.org/TestDateRestriction.xsd" attributeFormDefault="unqualified" elementFormDefault="qualified" xmlns="http://tempuri.org/TestDateRestriction.xsd" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<xsd:element name="root">
<xsd:simpleType>
<xsd:restriction base="xsd:dateTime">
<xsd:pattern value=".+T[^Z+-\.]+" />
</xsd:restriction>
</xsd:simpleType>
</xsd:element>
</xsd:schema>'
GO
CREATE XML SCHEMA COLLECTION TestDateRestrictionTimeZone
AS
'<?xml version="1.0" encoding="utf-8"?>
<xsd:schema targetNamespace="http://tempuri.org/TestDateRestriction.xsd" attributeFormDefault="unqualified" elementFormDefault="qualified" xmlns="http://tempuri.org/TestDateRestriction.xsd" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<xsd:element name="root">
<xsd:simpleType>
<xsd:restriction base="xsd:dateTime">
<xsd:pattern value=".+T[^+-\.]+Z" />
</xsd:restriction>
</xsd:simpleType>
</xsd:element></xsd:schema>'
GO
CREATE TABLE TestXML
(
IdTB INT IDENTITY(1, 1) NOT NULL
CONSTRAINT PK_TestXML PRIMARY KEY CLUSTERED,
XMLTB XML (DOCUMENT TestDateRestriction) NULL,
XMLTBTimeZone XML (DOCUMENT TestDateRestrictionTimeZone) NULL
)
GO
INSERT INTO TestXML (XMLTB) VALUES (N'<r:root xmlns:r="http://tempuri.org/TestDateRestriction.xsd">2005-03-22T08:35:00</r:root>')
GO
INSERT INTO TestXML (XMLTBTimeZone) VALUES (N'<r:root xmlns:r="http://tempuri.org/TestDateRestriction.xsd">2005-03-22T08:35:00Z</r:root>')
GO
Le résultat est le suivant : SQL Server 2005 n'autorise pas les dates sans spécification du flag Time Zone.
Or, dans le cadre des types DateTime, la norme XSD n'impose nullement la présence de l'indication TimeZone spécifiée dans la norme ISO 8601 comme le spécifie le W3C dans les spécifications suivantes : http://www.w3.org/TR/2005/WD-xpath-datamodel-20050211/#storing-timezones...
En revanche, l'exemple précédent prouve définitivement le choix de SQL Server de se conformer à la norme ISO. Cette information est d'ailleurs confirmée par cet article de la MSDN : http://msdn2.microsoft.com/en-us/library/ms345115.aspx#sql25xmlbp_topic3 (section "Using xs:datetime, xs:date and xs:time").
La seule question qui me reste à élucider est la raison de ce choix exigeant qui pose un problème de compatibilité : le XSD dont je dispose est imposé et partagé par de nombreux utilisateurs et ne peut donc pas être modifié...
Bonne lecture !
Suite à une question pertinente d'un client, j'ai cherché à comprendre pour quelle raison un schéma XSD me semblant parfaitement valable me générait une erreur à l'insertion des données...
Une fois le problème isolé, j'ai pu effectuer le test suivant :
DROP TABLE TestXML
GO
DROP XML SCHEMA COLLECTION TestDateRestriction
GO
DROP XML SCHEMA COLLECTION TestDateRestrictionTimeZone
GO
CREATE XML SCHEMA COLLECTION TestDateRestriction
AS
'<?xml version="1.0" encoding="utf-8"?>
<xsd:schema targetNamespace="http://tempuri.org/TestDateRestriction.xsd" attributeFormDefault="unqualified" elementFormDefault="qualified" xmlns="http://tempuri.org/TestDateRestriction.xsd" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<xsd:element name="root">
<xsd:simpleType>
<xsd:restriction base="xsd:dateTime">
<xsd:pattern value=".+T[^Z+-\.]+" />
</xsd:restriction>
</xsd:simpleType>
</xsd:element>
</xsd:schema>'
GO
CREATE XML SCHEMA COLLECTION TestDateRestrictionTimeZone
AS
'<?xml version="1.0" encoding="utf-8"?>
<xsd:schema targetNamespace="http://tempuri.org/TestDateRestriction.xsd" attributeFormDefault="unqualified" elementFormDefault="qualified" xmlns="http://tempuri.org/TestDateRestriction.xsd" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<xsd:element name="root">
<xsd:simpleType>
<xsd:restriction base="xsd:dateTime">
<xsd:pattern value=".+T[^+-\.]+Z" />
</xsd:restriction>
</xsd:simpleType>
</xsd:element></xsd:schema>'
GO
CREATE TABLE TestXML
(
IdTB INT IDENTITY(1, 1) NOT NULL
CONSTRAINT PK_TestXML PRIMARY KEY CLUSTERED,
XMLTB XML (DOCUMENT TestDateRestriction) NULL,
XMLTBTimeZone XML (DOCUMENT TestDateRestrictionTimeZone) NULL
)
GO
INSERT INTO TestXML (XMLTB) VALUES (N'<r:root xmlns:r="http://tempuri.org/TestDateRestriction.xsd">2005-03-22T08:35:00</r:root>')
GO
INSERT INTO TestXML (XMLTBTimeZone) VALUES (N'<r:root xmlns:r="http://tempuri.org/TestDateRestriction.xsd">2005-03-22T08:35:00Z</r:root>')
GO
Le résultat est le suivant : SQL Server 2005 n'autorise pas les dates sans spécification du flag Time Zone.
Or, dans le cadre des types DateTime, la norme XSD n'impose nullement la présence de l'indication TimeZone spécifiée dans la norme ISO 8601 comme le spécifie le W3C dans les spécifications suivantes : http://www.w3.org/TR/2005/WD-xpath-datamodel-20050211/#storing-timezones...
En revanche, l'exemple précédent prouve définitivement le choix de SQL Server de se conformer à la norme ISO. Cette information est d'ailleurs confirmée par cet article de la MSDN : http://msdn2.microsoft.com/en-us/library/ms345115.aspx#sql25xmlbp_topic3 (section "Using xs:datetime, xs:date and xs:time").
La seule question qui me reste à élucider est la raison de ce choix exigeant qui pose un problème de compatibilité : le XSD dont je dispose est imposé et partagé par de nombreux utilisateurs et ne peut donc pas être modifié...
mardi 13 février 2007
Modification du blog !
Bonjour à tous !
Suite aux multiples avis des différentes personnes qui m'ont fait de nombreuses remarques, ce blog vient de subir un léger lifting...
Alors n'hésitez pas à poster vos commentaires et vos idées concernant la nouvelle mise en page !
Typiquement, je suis à la recherche d'une couleur et d'une police intéressantes pour les blocs de code... Avis bienvenus ;-)
Suite aux multiples avis des différentes personnes qui m'ont fait de nombreuses remarques, ce blog vient de subir un léger lifting...
Alors n'hésitez pas à poster vos commentaires et vos idées concernant la nouvelle mise en page !
Typiquement, je suis à la recherche d'une couleur et d'une police intéressantes pour les blocs de code... Avis bienvenus ;-)
vendredi 9 février 2007
Analysis Services 2000 Service Pack 4 - l'arme anti DSO distant !
Bonjour à tous !
Si le pilotage d'Analysis Services 2000 via le namespace DSO est extrêmement simple, comme nous l'avons vu précédemment, il n'en demeure pas moins surprenant que la connexion s'effectue correctement sans une chaîne de connexion bien formée.
En effet, seul le nom du serveur est fourni lors de la connexion avec les objets DSO. La chaîne de connexion est alors récupérée en base de registre, décryptée, et permet d'accéder au Repository d'Analysis Services.
En pratique, Analysis Services stocke deux chaînes de connexion encryptées dans la base de registre :
- une première chaîne pour les connexions locales :
Provider=Microsoft.Jet.OLEDB.4.0;Data Source=C:\Program Files\Microsoft Analysis Services\Bin\msmdrep.mdb
- une deuxième chaîne pour les connexions distantes :
Provider=Microsoft.Jet.OLEDB.4.0;Data Source=\\<NomDuServeur>\MsOLAPRepository$\msmdrep. mdb
Vous remarquerez ici que le Repository d'Analysis Services 2000 est stocké dans une base de données Access.
A partir du Service Pack 3, un bug est apparu concernant la connexion avec les objets DSO. Malheureusement, le HOTFIX réalisé à l'époque n'a pas été incorporé dans le Service Pack 4 d'Analysis Services 2000.
En effet, l'encryption de la chaîne de connexion distante est défaillante. Il en résulte que la chaîne de connexion décryptée par les objets DSO n'est pas valide.
Ainsi, lors d'une connexion distante via DSO, le message suivant peut-être obtenu :
Cannot connect to the repository. OLAP Server:Error: <NomDuServeur> [Microsoft][ODBC Driver Manager] Data source name too long
L'incompréhension vient souvent du fait que la même action effectuée avec une connexion locale ne pose aucun problème, brouillant un peu plus les pistes de correction.
Un bug incidieux donc, pour lequel vous trouverez un HOTFIX ici. La référence de la description du HOTFIX est KB907323.
Plus simplement, vous pouvez modifier la valeur de la clé contenant la chaîne de connexion distante en effectuant un click droit sur le nom de votre serveur dans Analysis Manager dans le menu "Edit Repository Connection String".
Bien entendu, il est totalement inutile de passer ce HOTFIX si vous ne rencontrez aucun problème ;-)
Si le pilotage d'Analysis Services 2000 via le namespace DSO est extrêmement simple, comme nous l'avons vu précédemment, il n'en demeure pas moins surprenant que la connexion s'effectue correctement sans une chaîne de connexion bien formée.
En effet, seul le nom du serveur est fourni lors de la connexion avec les objets DSO. La chaîne de connexion est alors récupérée en base de registre, décryptée, et permet d'accéder au Repository d'Analysis Services.
En pratique, Analysis Services stocke deux chaînes de connexion encryptées dans la base de registre :
- une première chaîne pour les connexions locales :
Provider=Microsoft.Jet.OLEDB.4.0;Data Source=C:\Program Files\Microsoft Analysis Services\Bin\msmdrep.mdb
- une deuxième chaîne pour les connexions distantes :
Provider=Microsoft.Jet.OLEDB.4.0;Data Source=\\<NomDuServeur>
Vous remarquerez ici que le Repository d'Analysis Services 2000 est stocké dans une base de données Access.
A partir du Service Pack 3, un bug est apparu concernant la connexion avec les objets DSO. Malheureusement, le HOTFIX réalisé à l'époque n'a pas été incorporé dans le Service Pack 4 d'Analysis Services 2000.
En effet, l'encryption de la chaîne de connexion distante est défaillante. Il en résulte que la chaîne de connexion décryptée par les objets DSO n'est pas valide.
Ainsi, lors d'une connexion distante via DSO, le message suivant peut-être obtenu :
Cannot connect to the repository. OLAP Server:
L'incompréhension vient souvent du fait que la même action effectuée avec une connexion locale ne pose aucun problème, brouillant un peu plus les pistes de correction.
Un bug incidieux donc, pour lequel vous trouverez un HOTFIX ici. La référence de la description du HOTFIX est KB907323.
Plus simplement, vous pouvez modifier la valeur de la clé contenant la chaîne de connexion distante en effectuant un click droit sur le nom de votre serveur dans Analysis Manager dans le menu "Edit Repository Connection String".
Bien entendu, il est totalement inutile de passer ce HOTFIX si vous ne rencontrez aucun problème ;-)
Effectuer un process de cube dynamiquement...
Bonjour à tous !
Bon nombre d'entre vous ont peut-être souhaité un jour pouvoir effectuer un process de cube Analyses Services dynamiquement dans une application.
Le namespace DSO (Decision Support Objects) permet de se connecter au serveur Analysis Services simplement et offre une API intuitive en s'appuyant sur des composants COM via interop.
Le namespace DSO est disponible dans le framework 1.1 et permet de piloter Analysis Services 2000 et 2005.
Le namespace AMO (Analysis Management Object - Microsoft.AnalysisServices) a remplacé avantageusement le namespace DSO dans le framework 2.0.
Voici quelques bases pour l'utilisation de DSO...
Le code suivant permet d'effectuer une connexion au serveur local :
DSO.ServerClass dsoServer = new DSO.ServerClass();
dsoServer.Connect("localhost");
Puis il est possible de se positionner sur la base "Test" de la façon suivante :
DSO.Database dsoDB = dsoServer.MDStores.Item("Test");
Enfin, un cube ou une dimension donnés peuvent être identifiés de la façon suivante :
DSO.Cube dsoCube = dsoDB.MDStores.Item("MonCube");
DSO.Dimension dsoDim = dsoDB.Dimensions.Item("MaDimension");
Le process du cube ou d'une dimension est alors très aisément exécuté :
dsoDim.Process(DSO.ProcessTypes.processFull);
dsoCube.Process(DSO.ProcessTypes.processFull);
Si vous modifiez le cube dynamiquement (ajout ou suppression de dimension, modification des clauses de jointure, ...), il est nécessaire de mettre à jour le cube avant d'en effectuer le process :
dsoCube.Update();
Pensez à toujours vous déconnecter - typiquement dans le finally de vos blocs try-catch :
dsoServer.Disconnect();
... Et pour l'utilisation de AMO...
Le code suivant permet d'effectuer une connexion au serveur local :
Microsoft.AnalysisServices.Server amoServer = new Microsoft.AnalysisServices.Server();
amoServer.Connect("Data Source=localhost");
Le process du cube est tout aussi simple :
amoServer.Databases["Test"].Cubes["MonCube"].Process();
On notera les noms des collections beaucoup plus propres (Databases au lieu de MDStores).
Un pilotage simple pour des applications d'administration interactives ! Attention toutefois à ne pas oublier qu'un process de cube peut être une action coûteuse, et qu'il n'est souvent pas de très bon ton de rendre les données indisponibles pendant la journée ;-)
Bon nombre d'entre vous ont peut-être souhaité un jour pouvoir effectuer un process de cube Analyses Services dynamiquement dans une application.
Le namespace DSO (Decision Support Objects) permet de se connecter au serveur Analysis Services simplement et offre une API intuitive en s'appuyant sur des composants COM via interop.
Le namespace DSO est disponible dans le framework 1.1 et permet de piloter Analysis Services 2000 et 2005.
Le namespace AMO (Analysis Management Object - Microsoft.AnalysisServices) a remplacé avantageusement le namespace DSO dans le framework 2.0.
Voici quelques bases pour l'utilisation de DSO...
Le code suivant permet d'effectuer une connexion au serveur local :
DSO.ServerClass dsoServer = new DSO.ServerClass();
dsoServer.Connect("localhost");
Puis il est possible de se positionner sur la base "Test" de la façon suivante :
DSO.Database dsoDB = dsoServer.MDStores.Item("Test");
Enfin, un cube ou une dimension donnés peuvent être identifiés de la façon suivante :
DSO.Cube dsoCube = dsoDB.MDStores.Item("MonCube");
DSO.Dimension dsoDim = dsoDB.Dimensions.Item("MaDimension");
Le process du cube ou d'une dimension est alors très aisément exécuté :
dsoDim.Process(DSO.ProcessTypes.processFull);
dsoCube.Process(DSO.ProcessTypes.processFull);
Si vous modifiez le cube dynamiquement (ajout ou suppression de dimension, modification des clauses de jointure, ...), il est nécessaire de mettre à jour le cube avant d'en effectuer le process :
dsoCube.Update();
Pensez à toujours vous déconnecter - typiquement dans le finally de vos blocs try-catch :
dsoServer.Disconnect();
... Et pour l'utilisation de AMO...
Le code suivant permet d'effectuer une connexion au serveur local :
Microsoft.AnalysisServices.Server amoServer = new Microsoft.AnalysisServices.Server();
amoServer.Connect("Data Source=localhost");
Le process du cube est tout aussi simple :
amoServer.Databases["Test"].Cubes["MonCube"].Process();
On notera les noms des collections beaucoup plus propres (Databases au lieu de MDStores).
Un pilotage simple pour des applications d'administration interactives ! Attention toutefois à ne pas oublier qu'un process de cube peut être une action coûteuse, et qu'il n'est souvent pas de très bon ton de rendre les données indisponibles pendant la journée ;-)
vendredi 26 janvier 2007
Un nouveau Bloggeur chez Winwise !!!
Bonjour à tous !
Je viens vous présenter un nouveau bloggeur de chez nous... Alors gare aux blagues carambar - il est expert en la matière - et bonne lecture à tous !!!
Au fait, il est fan de DELEGATE anonymes... Surtout quand ça ne sert à rien ;-)
Vous trouverez donc le blog de Matthieu Mezil en cliquant ici... Ou dans le bandeau sur la droite ;-)
Je viens vous présenter un nouveau bloggeur de chez nous... Alors gare aux blagues carambar - il est expert en la matière - et bonne lecture à tous !!!
Au fait, il est fan de DELEGATE anonymes... Surtout quand ça ne sert à rien ;-)
Vous trouverez donc le blog de Matthieu Mezil en cliquant ici... Ou dans le bandeau sur la droite ;-)
mercredi 17 janvier 2007
Les colonnes calculées persistantes... Une bonne idée ?
Bonsoir !
Les colonnes calculées sont supportées par SQL Server depuis la version 7... En revanche, SQL Server 2005 permet désormais de rendre ces colonnes persistantes.
En effet, jusque là, les colonnes calculées étaient des colonnes virtuelles, c'est à dire que ces colonnes n'étaient pas écrites sur le disque. Le fait de pouvoir rendre une colonne calculée persistante, c'est le fait de rendre cette colonne physique, et donc de stocker les données inhérentes à cette colonne sur le disque de données.
SQL Server 2000 avait déjà apporté la possibilité de créer des index sur les colonnes calculées, permettant ainsi d'améliorer grandement les performances de certaines applications, en particulier dans le domaine de la consolidation de données. L'exemple type qui reste gravé dans la mémoire collective est la consolidation du chiffre d'affaire mois par mois.
En effet, examinons la table suivante :
CREATE TABLE dbo.Vente
(
VenteID INT IDENTITY (1, 1) NOT NULL
CONSTRAINT PK_Vente PRIMARY KEY CLUSTERED,
DateVente SMALLDATETIME NOT NULL,
MontantVente MONEY NOT NULL
)
Une requête pour consolider ces résultats sur le mois de janvier serait :
SELECT
SUM(MontantVente)
FROM
dbo.Vente
WHERE
DATEPART(MONTH, DateVente) = 1
Cependant, si la volumétrie est importante, cette requête peut rapidement s'avérer très coûteuse. Si la solution d'indexer la colonne DateVente n'apporte rien dans notre cas, il peut être très utile d'employer une colonne calculée :
ALTER TABLE dbo.Vente
ADD MoisVente AS DATEPART(MONTH, DateVente)
Cette colonne n'utilisant qu'une fonction déterministe, il est possible d'y ajouter un index. A cet effet, un certain nombre d'options doivent être correctement positionnées :
SET ANSI_NULL ON
SET ANSI_PADDING ON
SET ANSI_WARNINGS ON
SET ARITHABORT ON
SET CONCAT_NULL_YIELDS_NULL ON
SET QUOTED_IDENTIFIER ON
SET NUMERIC_ROUNDABORT OFF
Puis, il est possible de créer l'index :
CREATE NONCLUSTERED INDEX IX_MoisVente ON dbo.Vente
(
MoisVente
)
Avant d'effectuer notre requête optimisée :
SELECT
SUM(MontantVente)
FROM
dbo.Vente
WHERE
MoisVente = 1
Le résultat est assez probant, et peut s'avérer extrêmement intéressant.
La question qui se pose donc est ce que peut bien apporter la persistance d'une telle colonne calculée. En effet, l'argument régulièrement évoqué de l'indexation de la colonne semble bien tomber à l'eau... Quant aux conditions d'utilisation des index sur les colonnes calculées, elles s'avèrent identiques que la valeur soit persistée ou non, à l'exception du déterminisme de la fonction employée...
Pourquoi donc encombrer les disques de données visiblement inutiles ?
La première piste serait donc l'utilisation de fonctions non déterministes, ou dont il serait difficile de savoir si elles le sont, en particulier en ce qui concerne les fonctions CLR.
Mais il faut également se tourner vers des cas plus gourmands en calculs : la persistance prend tout son intérêt lors de calculs complexes nécessitant des ressources CPU importantes, en particulier lorsque la volumétrie de modifications est faible.
Dans ces cas là, le calcul à la volée de notre colonne entraine nécessairement un ralentissement du système, et justifie la persistance de ce calcul.
Soit, voici donc les applications de ces colonnes calculées persistantes...
Les colonnes calculées sont supportées par SQL Server depuis la version 7... En revanche, SQL Server 2005 permet désormais de rendre ces colonnes persistantes.
En effet, jusque là, les colonnes calculées étaient des colonnes virtuelles, c'est à dire que ces colonnes n'étaient pas écrites sur le disque. Le fait de pouvoir rendre une colonne calculée persistante, c'est le fait de rendre cette colonne physique, et donc de stocker les données inhérentes à cette colonne sur le disque de données.
SQL Server 2000 avait déjà apporté la possibilité de créer des index sur les colonnes calculées, permettant ainsi d'améliorer grandement les performances de certaines applications, en particulier dans le domaine de la consolidation de données. L'exemple type qui reste gravé dans la mémoire collective est la consolidation du chiffre d'affaire mois par mois.
En effet, examinons la table suivante :
CREATE TABLE dbo.Vente
(
VenteID INT IDENTITY (1, 1) NOT NULL
CONSTRAINT PK_Vente PRIMARY KEY CLUSTERED,
DateVente SMALLDATETIME NOT NULL,
MontantVente MONEY NOT NULL
)
Une requête pour consolider ces résultats sur le mois de janvier serait :
SELECT
SUM(MontantVente)
FROM
dbo.Vente
WHERE
DATEPART(MONTH, DateVente) = 1
Cependant, si la volumétrie est importante, cette requête peut rapidement s'avérer très coûteuse. Si la solution d'indexer la colonne DateVente n'apporte rien dans notre cas, il peut être très utile d'employer une colonne calculée :
ALTER TABLE dbo.Vente
ADD MoisVente AS DATEPART(MONTH, DateVente)
Cette colonne n'utilisant qu'une fonction déterministe, il est possible d'y ajouter un index. A cet effet, un certain nombre d'options doivent être correctement positionnées :
SET ANSI_NULL ON
SET ANSI_PADDING ON
SET ANSI_WARNINGS ON
SET ARITHABORT ON
SET CONCAT_NULL_YIELDS_NULL ON
SET QUOTED_IDENTIFIER ON
SET NUMERIC_ROUNDABORT OFF
Puis, il est possible de créer l'index :
CREATE NONCLUSTERED INDEX IX_MoisVente ON dbo.Vente
(
MoisVente
)
Avant d'effectuer notre requête optimisée :
SELECT
SUM(MontantVente)
FROM
dbo.Vente
WHERE
MoisVente = 1
Le résultat est assez probant, et peut s'avérer extrêmement intéressant.
La question qui se pose donc est ce que peut bien apporter la persistance d'une telle colonne calculée. En effet, l'argument régulièrement évoqué de l'indexation de la colonne semble bien tomber à l'eau... Quant aux conditions d'utilisation des index sur les colonnes calculées, elles s'avèrent identiques que la valeur soit persistée ou non, à l'exception du déterminisme de la fonction employée...
Pourquoi donc encombrer les disques de données visiblement inutiles ?
La première piste serait donc l'utilisation de fonctions non déterministes, ou dont il serait difficile de savoir si elles le sont, en particulier en ce qui concerne les fonctions CLR.
Mais il faut également se tourner vers des cas plus gourmands en calculs : la persistance prend tout son intérêt lors de calculs complexes nécessitant des ressources CPU importantes, en particulier lorsque la volumétrie de modifications est faible.
Dans ces cas là, le calcul à la volée de notre colonne entraine nécessairement un ralentissement du système, et justifie la persistance de ce calcul.
Soit, voici donc les applications de ces colonnes calculées persistantes...
Inscription à :
Articles (Atom)
