Question

Nous recevons plusieurs milliers de fichiers plats actuellement par semaine, et j'ai un système qui exécute des rapports sur ces questions et les exporte au format PDF pour notre peuple pour traiter et de référence.

Je charge actuellement en vrac ceux-ci dans une base de données, vérifiez que tous les champs / formatage est valide, les exporter et tronquer les tables sur la prochaine course.

Ce que je me demande est ce que tout le monde pense être le plus d'espace moyen efficace de stocker peut-être 6 mois de cette charge en vrac données texte brut?

Soit sous la forme de sauvegardes quotidiennes SQL, ou des archives zip, ou autre chose, donc j'ai toujours eu la possibilité de recharger les anciennes données pour dépannages.

Toutes les idées sont les bienvenues, je suis ouvert à toute suggestion.

Était-ce utile?

La solution

Alors, vous les fichiers plats en vrac charge des données brutes, vous utilisez SQL Server 2005 pour les traiter et obtenir un groupe distinct de fichiers plats transformés, puis vider les données?

Eh bien, si cela est correct, les sauvegardes SQL ne sera pas utile puisque vous semblez dire que les données ne reste pas dans le DB. Votre seule option est une compression efficace des entrées et / ou les fichiers de sortie couplés avec une bonne organisation des lots dans les répertoires.

Je recommande un programme de compression agressive, qui a prévu une fonctionnalité de traitement par lots, mais attention à ne pas se rendre à ésotérique avec le programme que vous utilisez pour le bien d'éviter d'être enfermé dans un programme à ...

Autres conseils

Utilisez un utilitaire de compression récent de génération (7z et compression rar sont grandes) et la compression en paquets après avoir organisé tout il est donc facile à trouver.

Il y a SDK pour 7zip qui travaillent avec .net pour vous faciliter la tâche.

-Adam

Il existe deux types de post-analyse des données:

  • les données d'origine (généralement très grand)
  • données dérivées (généralement plus petites)

Dans votre cas, les données dérivées pourraient être les données qui va dans vos rapports. Pour vos données d'origine que je venais de faire un énorme fichier d'archive compressée avec un nom systématique en fonction de la date et le type de données. La valeur de ce que si un internaute novice de votre équipe en quelque sorte oblitère totalement le code qui importe vos données d'origine dans la base de données, vous pouvez récupérer. Si les données dérivées est faible, vous pourriez penser à la copie qui pourrait être résolu soit une autre table de base de données, ou le garder dans un fichier plat séparé parce que certains de vos problèmes simplement en obtenir des données dérivées.

Sauvegarde de vos données en général est un problème délicat, car cela dépend des choses comme:

  • Montant de débit de données
  • L'espace disponible pour les sauvegardes hors site
  • Valeur de la mise à niveau de votre système de sauvegarde contre seulement vous résignant à régénérer les données en cas de problèmes se produisent.

Quelle est votre configuration comme? Est-ce que les disques durs croître assez vite pour maintenir la version compressée de vos données? Avez-vous pensé à des sauvegardes hors site?

Construire une hiérarchie de fichiers qui organise les fichiers correctement, zip tout le répertoire et utilisez le drapeau sur zip -u pour ajouter de nouvelles files.after vous les archives, vous pouvez supprimer les fichiers, mais conserver la structure de répertoire pour le lot suivant à ajouter.

Si les noms de fichiers encodent la version en quelque sorte (dates ou autre) ou sont par ailleurs unique, il n'a pas besoin d'être quelque chose colombophile qu'un répertoire signle. Sinon, vous devez configurer vos répertoires pour vous permettre de récupérer les versions.

les compacter et les enregistrer dans un champ binaire dans la base de données. Ensuite, vous pouvez construire un bouton « jeu de données reload » pour faire venir dans votre ensemble de données (je suppose que vous garder une trace de chaque ensemble de données que vous importez pour le remplacer, etc.)

De cette façon, tout est stocké dans la base de données, et sauvegardé avec la base de données, indexé et correctement défini, et comprimé en même temps.

Vous avez indiqué que vous souhaitez éviter SDKs et l'installation de logiciels sur des systèmes distants.

Vos options sont assez limitées.

Puisque vous utilisez des ordinateurs Windows, pourquoi ne pas utiliser un script simple?

Cette question propose plusieurs suggestions sur la façon d'utiliser des fenêtres VBscript pour compresser et décompresser des fichiers:
peut la compression ZIP intégré Windows d'écrire des scripts

Rien à 'installer', pas SDKs. Il suffit de copier le script sur, appelez via le planificateur, et vous êtes tous ensemble.

-Adam

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top