web-dev-qa-db-fra.com

Meilleure pratique pour la validation des données SQL Server

J'ai des fichiers CSV que je souhaiterais importer dans SQL Server 2014. Chaque enregistrement dans les fichiers compte environ 20 colonnes, chacun d'entre eux doit être validé pour la conformité de type de données ainsi que d'autres contrôles par colonne (gammes min/max, null/pas null, etc.).

Je cherche des conseils concernant une architecture modèle pour le faire de manière efficace. L'utilisation des SSIS et des tables d'erreur me semble-t-il un peu inefficace car il semble que je ne puisse obtenir qu'une colonne vérifiée à la fois et que la manipulation des erreurs (en particulier le verrouillage de la colonne dans la SSIS est au mieux encombré).

Je préférerais que chaque enregistrement traité et tout de suite ait un aperçu de toutes les erreurs qui se trouvent dans cet enregistrement, afin que je puisse fournir une rétroaction de tous les problèmes à la fois à la personne fournissant les données à l'importation.

sql-serversql-server-2014ssisssis-2014data-validation
5
nojetlag

Le SSIS est en effet clunky lorsqu'il s'agit d'importer des données pour toutes les prouesses de traitement qu'il semble tout. L'un des commentateurs, Kin, je crois, a eu raison de créer une table temporaire. Voici le code que nous utilisons pour importer des données directement à partir d'Excel dans une table temporaire à analyser pour la conformité. Comme vous pouvez le constater dans l'exemple ci-dessous, à l'aide de T-SQL, OpenRowset lit l'onglet spécifique de la feuille de calcul Excel appelée SQL Server Détails d'instance Server et importe les données dans la table SQL Table TempserverMap.

Après, les données sont importées dans la table temporaire que vous avez un monde d'options. Vous pouvez insérer les données dans une autre table comportant toutes les règles commerciales SQL dont vous avez besoin sur chacune des colonnes - éliminant les données qui ne sont pas qualifiées - je dis ce pas comme nécessairement "meilleur moyen" mais pour utiliser le moins de code du code dans le début réglant votre processus de recherche d'erreurs. Vous auriez besoin de contrôler la manipulation des erreurs ici pour attraper les mauvaises pommes (rangées) afin que vous puissiez les examiner plus tard. Alternativement, vous pouvez créer des fonctions, des procédures ou des déclencheurs ou de tout ce qui précède, vérifiez les données à l'avance pour vous assurer que les exigences de fonctionnement sont conformes aux besoins professionnels.

Et si vous cherchez à communiquer ces erreurs à d'autres personnes, créez simplement un rapport SSRS (Services de rapport) qui interroge votre nouvelle table d'erreur et donnez-leur les autorisations appropriées pour afficher le rapport. Il est basé sur le Web et facilement accessible dans un environnement intranet. Si vous avez des associés externes, vous pouvez disposer de la SSRS, envoyez-leur le rapport comme facilement.

Le point principal ici est: obtenez vos données d'Excel et dans SQL Server afin qu'il puisse être manipulé efficacement.

Certains dBA peuvent être offensés au remplacement/exécuté du code ci-dessous. Si tel est le cas, il suffit de coder l'instruction SELECT avec des noms de fichiers Excel spécifiques.

declare  @cmdstring varchar(8000) ='select * into SQLSunSet.dbo.TempServerMap from OPENROWSET (''Microsoft.Ace.OLEDB.12.0'', ''Excel 12.0;Database=<MapsExcelFile_SQLServerUsageTracker>'', ''select * from [SQL Server Instance Details$]'')'
set @cmdstring = replace(@cmdstring,'<MapsExcelFile_SQLServerUsageTracker>',@MapsExcelFile_SQLServerUsageTracker)

if exists (select * from sysobjects where type ='u' and name ='TempServerMap') drop table TempServerMap

        --print (@cmdstring)
     exec (@cmdstring)

Beaucoup de gens semblent se tourner vers les SSIS dans l'espoir de ne pas coder T-SQL. Mais je trouve généralement que SSIS est comme une roue motrice défectueuse. Il suffit que vous soyez coincé plus que ce que vous auriez été beaucoup plus loin sur la route.

P.s. Pour utiliser efficacement OpenRowset, vous devrez peut-être installer le moteur de base de données Microsoft Access 2010 Redistributable (vraiment - un moteur Microsoft Office - non seulement pour l'accès MS). Cela peut être téléchargé ici:

https://www.microsoft.com/en-us/download/details.aspx?id=13255

De plus, vous devrez peut-être configurer SQL Server pour exécuter OpenRowset et utiliser également le moteur Office dans T-SQL à l'aide du code suivant après son installation:

exec sp_configure 'Show Advanced Options', 1;
RECONFIGURE;
GO

exec sp_configure 'Ad Hoc Distributed Queries', 1;
RECONFIGURE;
GO

EXEC master.dbo.sp_MSset_oledb_prop N'Microsoft.ACE.OLEDB.12.0', N'AllowInProcess', 1 
GO 

EXEC master.dbo.sp_MSset_oledb_prop N'Microsoft.ACE.OLEDB.12.0', N'DynamicParameters', 1 
GO
3
Sting