Dans un environnement de production, vous devrez probablement migrer vos données vers la base de données Cúram.
La description d'une telle migration n'entre pas dans le cadre de ce document, car cette opération nécessite une connaissance approfondie des éléments suivants :
- Modèle de référence Cúram et personnalisations éventuelles
- Structure et intégrité des données existantes
- Toute exigence de synchronisation continue des données entre Cúram et vos autres systèmes
- Toute procédure de migration dont vous pouvez disposer
En plus des éléments ci-dessus, il convient de tenir compte des suggestions suivantes :
- Des données initiales d'exemple nécessaires au démarrage du serveur en ligne Cúram sont fournies. Ces données initiales contiennent notamment l'administrateur (admin). Elles peuvent être personnalisées avant leur chargement dans la base de données ou par le biais de l'application elle-même (avant la mise en ligne).
- Des données de démonstration sont fournies. Nous vous suggérons de ne pas les charger dans votre base de données de production.
- Vous pouvez pré-trier vos données conformément à votre stratégie de mise en cluster.
- Le modèle de référence Cúram inclut des contraintes de clé externe qui facilitent le maintien de l'intégrité des données Cúram. Lorsque ces contraintes sont appliquées avant le chargement des données migrées, des violations peuvent se produire si vos données ne sont pas chargées dans l'ordre "parent-enfant"1 Nous suggérons donc d'appliquer les contraintes de clé externe après le chargement de vos données migrées2 . Toute contrainte rejetée par la base de données indique un problème d'intégrité dans vos données migrées.
- Le modèle de référence Cúram inclut des index permettant la prise en charge de toutes les requêtes SQL utilisées depuis Cúram Server Application. Vous pouvez supprimer certains de ces index pour améliorer les performances d'écriture de la base de données, mais vous dégraderez alors les performances des requêtes peu souvent utilisées. Cette opération ne peut être effectuée que lorsque vous savez quelles transactions de l'application seront utilisées fréquemment en ligne dans votre installation et lesquelles seront rarement utilisées en ligne ou seulement utilisées par lots.
1 Dans une base de données relationnelle, une entité parent est souvent associée à zéro, une ou plusieurs entités "enfant". Chacune de ces entités porte la clé de ses parents, et le parent doit donc être créé en premier pour que la clé soit disponible (pour définir la clé du parent sur l'enfant) lorsque l'enfant est stocké par la suite.
2 Il est recommandé de créer de telles contraintes pour identifier les problèmes d'intégrité de vos données converties, puis, une fois que les problèmes sont résolus, de les supprimer, car elles ne sont pas prises en charge pour les bases de données de production.