Migration : choix technique - SQL/NoSQL - Programmation
Marsh Posté le 22-08-2007 à 15:13:24
Il n'y a pas de meilleure solution.
Les fichiers "à plat", déjà, ça regroupe plusieurs types de fichiers.
1/ On va trouver les fichiers "record". Ces fichiers stockent les informations sous forme de chaînes de caractères de tailles fixes, collées les unes à la suite des autres.
Ce type de fichiers à pour avantages :
- Très facile à créer avec VB ou en Pascal par exemple
- Extrêment rapide à lire et écrire (y'a rien de plus rapide en fait, mise à part des données binaires brutes).
- Beaucoup d'outils savent les relire (Excel par exemple propose un assistant pour lire de tels fichiers).
Mais un gros inconvénient :
- Ils n'ont pas de structure annoncée. Ainsi, impossible de détecter automatiquement ce qu'il contient.
2/ Le CSV. C'est le type de fichiers plat le plus courant. Il s'agit de stocker les valeurs de chaque ligne de ta base de donnés dans une ligne du fichier CSV, les valeurs étant séparées par des virgules (ou autre séparateur) et les chaînes de caractères entre guillements (ou autre caractère d'échappement).
Ce type de fichiers a des avantages :
- Très facile à générer avec n'importe quel langage
- Il peut contenir une ligne d'entête qui permet de retrouver plus ou moins ce qu'il contient en lisant cette ligne (on a du moins le nom des colonnes)
Mais aussi des inconvénients :
- Assez lent
- Pose des problèmes avec les nombres et les chaînes de caractères, en fonction des caractères de séparations et d'échappement retenus
3/ Fichiers excel, ou autres logiciels tiers.
Quelques avantages certains :
- On peut très aisément automatiser leur création et injection dans un SGBD via des macros
- Ils sont directement lisibles
- Les données conservent leur type durant le transport
Mais des inconvénients :
- Très lents
- Il faut avoir le logiciel sur les deux machines
4/ Fichiers SQL
Avantages :
- La plupart des SGDB permettent de les générer automatiquement
- On peut les intégrer dans la destination sans le moindre développement
- On peut aisément modifier directement le code pour l'adapter à la destination
Inconvénients :
- Problèmes éventuels de charset
- Problèmes de non conformité des instructions et des séquences d'échappement entre les différents SBDG
- Fichier très volumineux
- Obligé de découper les fichiers en rondelles si on ne veut pas faire exploser le rollback segment
Reste le XML : Il est à la base prévu pour faire justement ce genre de choses : démartérialiser une base de données afin de transférer ses informations sous forme de fichiers de données.
Il a de gros avantages :
- Hiérachique et données typées : on retrouve donc immédiatement ce qu'on a dedans en relisant le fichier
- Aucun problème de jeu de caractères car il contient les informations d'encodage
- De nombreux outils permettent de travailler avec
- De nombreux SGBD savent les lire et écrire nativement (depuis quelques temps seulement)
Mais aussi des inconvénients :
- Perte immense de taille
- Malheureusement, obligé de faire du dev spécifique (y'a pas ou peu de formats prédéfinis... le plus générique serait de faire des DataSet avec .NET et les sérialiser en XML avec la méthode par défaut. Mais ça implique de travailler en .NET sous Linux, donc avec Mono et tout n'est pas porté...
En tout cas, le XML n'est pas à déconseiller. C'est par contre une solution aussi lourde que les autres, ce qui est bien domage.
Marsh Posté le 22-08-2007 à 15:53:52
Merci pour la réponse MagicBuzz,
je récapitule :
1°/ Le fichier record : le fait qu'il ne soit pas structuré ne me pose pas de problème particulier dans la mesure où je compte stocker le schéma de la base dans le fichier. Donc potentiellement c'est une solution viable.
2°/ Le CSV : même optique, la classe que j'utilise pour gérer les données contenues dans les fichiers tiendra compte de ces caractères (mais je dois effectivement y faire attention).
3°/ Les fichiers Excel ne me semblent pas être une bonne solution dans la mesure où je dois prévoire les environnements de type UNIX et autres, de plus je ne me vois pas trop demander l'installation d'Excel sur un serveur pour les besoins de la migration.
4°/ Les fichiers SQL : il faudrait que je me renseigne pour générer ce fichier avec la console d'administration de sqlserver 2005. Et aussi pour m'assurer que le code est conforme à la fois de SQL server et de Mysql.
En ce qui concerne mes interrogations sur le XML tu viens de m'éclairer nettement et je t'en remercie, cependant je ne comprend pas bien ce que tu entends par "Perte immense de taille " et "y'a pas ou peu de formats prédéfinis". Pourrais tu m'éclairer sur ces deux points ?
Marsh Posté le 22-08-2007 à 16:52:09
frere tuck a écrit : En ce qui concerne mes interrogations sur le XML tu viens de m'éclairer nettement et je t'en remercie, cependant je ne comprend pas bien ce que tu entends par "Perte immense de taille " et "y'a pas ou peu de formats prédéfinis". Pourrais tu m'éclairer sur ces deux points ? |
Exemple :
Tu peux avoir un fichier XML de ce genre :
Code :
|
Mais pour les mêmes infos, tu peux avoir :
Code :
|
Les deux contiennent les mêmes données, mais n'ont absolument pas la même structure.
Le premier ressemble à ce qu'on obtient en .NET lorsqu'on fait un .WriteXml() sur un objet DataTable, tandis que le second ressemble à ce qu'on obtient quand on lance la même méthode sur un objet DataSet.
Et ceci c'est que deux exemple. Il y a une infinité de possibilités pour un même énoncé et un même problème.
C'est pourquoi je dis que c'est pas trop standardisé.
Il existe des DTD permettant d'uniformiser les choses, mais elles sont rarement connues, et trop souvent trop spécialisées et complexes, ce qui les rend inaccessible pour une one shot.
Pour ce qui est de la volumétrie, tu remarqueras comparé à un simple fichier CSV :
|
Le XML rajoute un peu beaucoup de bordel autour...
Marsh Posté le 22-08-2007 à 17:40:03
c'est pas vraiment de la migration mais de la réplication que tu veux faire nan?
Si je demande, c'est juste que recopier les données c'est pas potentiellement suffisant...
Je pense par exemple à des objets sequences qui pourraient être utilisées sur ta base ou ce genre de chose et qu'il conviendrait de "mettre à jour"...
Marsh Posté le 23-08-2007 à 09:36:28
Je veux simplement pouvoir transférer mes données d'une base "test" sur un serveur sql server, vers une base "test" de schéma en tous points identiques.
Apres pour les objets sequences, il faut que je refasse des recherches je ne connais pas ou alors pas dans ces termes mais je te remercie de la suggestion.
Marsh Posté le 23-08-2007 à 09:46:02
MagicBuzz a écrit :
|
Donc en fait le problème avec le XML viendrai de la standardisation, ou plutôt de la non-standardisation d'une DTD commune à toutes les méthodes d'export si je ccomprends bien... la volumétrie est un autre problème mais si ça peut garantir l'utilisation d'un parseur ça se justifie non ?
Dans tous les cas, je trouve assez remarquable le fait que cette méthode ne soit que rarement conseillée. En réalité ce qui me met la puce à l'oreille c'est que l'export des données au format XML n'est pas possible par l'assistant dans sql server et que tous les autre formats d'export sont prise en charge.
Marsh Posté le 23-08-2007 à 09:46:32
Oui ça j'ai bien compris que tu as besoin de recopier... Je vais reformuler la question, ta base de recopie a-t-elle pour but :
- de contenir une sauvegarde de la BDD,
- d'être utilisable par une application.
C'est pas du tout la même problèmatique car dans le 1er cas, il suffit de s'attacher à bien recopier les données alors que dans le deuxième il faut également les informations de structure de ta base (PK, FK, sequences, proc. stockées) et d'une base à une autre, attention les surprises
Marsh Posté le 23-08-2007 à 10:15:09
anapajari a écrit : Oui ça j'ai bien compris que tu as besoin de recopier... Je vais reformuler la question, ta base de recopie a-t-elle pour but : |
Justement nous sommes dans le cas ou une application va devoir se servir de cette base de données.
En fait j'ai une application qui se sert d'une base de données sur un serveur sql server, et cette même application va devoir se servir de la base migrée sous un serveur mysql, par exemple.
Marsh Posté le 23-08-2007 à 10:28:52
D'un autre côté, tu peux extraire les données en XML directement en faisant une requête, donc ça sert pas à grand chose de faire un assistant pour ça...
Marsh Posté le 23-08-2007 à 12:17:22
Effectivement, mais les utilisateurs de l'application n'ont pas les connaissances pour effectuer ce genre de manipulation, d'ou le fait que je sois obligé de les guider dans cette démarche.
Marsh Posté le 25-08-2007 à 00:03:38
Au final je pense que je vais passer par des fichiers à plat (csv) :
les + pour moi :
- c'est suffisamment souple pour couvrir l'ensemble de ce que je vais rencontrer comme environnement de migration
- techniquement c'est simple à générer et je peux stocker le schéma dans le fichier
- je peux gérer les caractères d'échappement moi même
Au niveau des inconvénient la lenteur n'est pas un problème dans la mesure où ça sera une opération ponctuelle.
Donc faute de certitudes je vais prendre cette solution, mais je reste dubitatif sur le cas du XML : c'est un format fait pour ce genre d'opération et pourtant la seule chose que l'on peut me dire sur les migrations de bases de données, c'est que toutes les applications utilisent les fichiers à plat.
Par contre pas moyen d'en trouver la raison pour le moment.
En tout cas merci pour les réponses, je vais poursuivre mes recherches et je posterai la finalité de la chose dans ce topic.
Marsh Posté le 25-08-2007 à 00:49:14
(ceci dit, un fichier XML est un fichier plat comme un autre...)
Marsh Posté le 27-08-2007 à 09:48:12
Ce que je voulais dire par là, c'est que le XML était rarement utilisé.
Je continue à faire quelques recherches quand même pour assurer le coup.
Marsh Posté le 28-08-2007 à 14:31:45
Plop.
Voici un petit exemple, puisque je suis actuellement en train de travailler sur une appli qui fait elle aussi de la réplication de données.
En fait, dans mon cas il s'agit d'extraire des données quotidiennement depuis une base centrale, puis les envoyer à des clients par serveur FTP interposé afin de maintenir des bases locales à jour.
Histoire de ne pas me faire chier, j'utilise tout bêtement les fonctionnalités de sérialisation des DataSet de .NET (comment c'est de la balle )
Extraction : (extrait, la classe qui nous intéresse : extraction des données, mise sous forme de dataset, sérialisation dans un flux mémoire, puis compression)
Code :
|
Ensuite, la récupération :
Code :
|
Ca me permet ici de lire des données depuis une base Oracle, et les intégrer dans une base SQL Server sans me soucier des problèmes de conversion de type notamment.
DataSet.WriteXml() génère un fichier XML contenant une XSD embarquée. Ce qui fait qu'on peut le relire automatiquement depuis un DataSet.ReadXml() sans se soucier de sa structure. Ici, je stocke plusieurs DataTable dans le même fichier, ce qui me permet de n'avoir qu'un seul gros fichier à me trimballer plutôt qu'une chiée qu'il me serait très chiant de gérer.
Marsh Posté le 22-08-2007 à 10:59:10
Bonjour,
je dois réaliser un utilitaire permettant de migrer les données d'une base de vers une autre.
Jusque là c'est un cas de migration simple, sauf que je dois tenir compte des cas suivants :
1°/ Les deux bases de données (source et destination) peuvent ne pas être disponible en même temps. En effet les données
peuvent aller d'un serveur vers un autre, le serveur n'étant pas encore disponible. On doit pouvoir migrer les données
depuis un serveur qui est sous windows 2003 server vers le même serveur qui sera formatté sous linux, par exemple.
2°/ La migration de ces données doit également prévoir la migration sqlserver <-> mysql
Mon problème ne concerne pas la réalisation de cet utilitaire en soit, mais plutôt un cchoix technique, explications :
- Les deux contraintes ci-dessus imposent d'office le fait de passer par des fichiers contenant les données, puisque les
serveurs de base de données peuvent ne pas être disponibles simultanément, ou envore géographiquement, ce qui exclu
l'utilisation de connecteur (odbc, etc...).
- Le choix de passer par ces fichiers semblent donc offrir la souplesse dont j'ai besoin pour la réalisation de ce petit
outil et permet de couvrir toutes les contraintes fonctionnelles qui me sont imposées.
=> Deux solutions sont possibles :
a) passer par des fichiers à plat.
b) passer par des fichiers XML
La question du choix se pose : j'ai remarqué que beaucoup recommandent de passer par des fichiers à plat (type texte) pour
contenir les données à migrer, l'outil de migration de SQLServer 2005 propose lui même de passer par des fichiers a plat,
des fichiers excel et d'autre formats mais en aucun cas par des fichiers XML.
Premiere question : quel est, selon vous la meilleure solution et pourquoi ?
Deuxième question : pourquoi le XML n'est il jamais retenu dans les solutions de migration ?
Merci d'avance.