›

Stratégie de sauvegarde multi-documents pour database

muqaddarmuqaddar Administrateur
23:06 modifié dans Objective-C, Swift, C, C++ #1
Salut,

Actuellement, je gère les données mes applications avec une base SQLite et tous les fichiers dépendants à  côté. J'ai donc:
- 1 base SQLite
- quelques dossiers à  côté qui contiennent des tas de fichiers dépendants (images)

J'aimerais trouver une stratégie de sauvegarde qui ne nuit pas aux performances et qui permet de créer des packages:
- 1 package contient par exemple 1 ou plusieurs fichiers XML ou JSON + les images associées

Le problème, c'est de gérer les requêtes sur le relationnel avec tous ses packages et de bâtir une "base temporaire" à  partir de tous les packages.

Faudrait-il parser tous les fichiers des packages et gérer en corrélation ET la base SQLite temporaire ET les fichiers dépendants ?
Y-a-t-il d'autres approches ? A part le NoSQL que je vois tourner en serveur mais plus difficilement en local ?

L'approche des packages est intéressante:
- facile à  exporter
- facile à  consulter
- facile à  compresser
- plus facile pour iCloud
- plus facile pour n'importe quel système de synchronisation

Merci.

Réponses

  • zoczoc Membre
    octobre 2011 modifié #2
    Une "connexion" SQLite peut être rattachée à  plusieurs bases sqlite à  la fois... Voir la commande "ATTACH DATABASE". Donc au pire on peut imaginer avoir un fichier SQLite par table (et du coup iCloud backup ne sauvegarderait que les fichiers concernant les tables modifiées, et pas les autres).


    Evidemment, une fois les bases annexes rattachées à  la base principale, il devient possible d'exécuter des requêtes SQL entre les tables des bases (jointures entre autre).


    Je conseille fortement à  ceux qui utilisent intensivement SQLite de consulter la documentation officielle, pleine de détails et d'astuces pour tirer le maximum de cet outil.
  • muqaddarmuqaddar Administrateur
    23:06 modifié #3
    dans 1319642604:

    Une "connexion" SQLite peut être rattachée à  plusieurs bases sqlite à  la fois... Voir la commande "ATTACH DATABASE". Donc au pire on peut imaginer avoir un fichier SQLite par table.


    Je connais cette commande puisque je l'utilise déjà  dans mon application pour lier 2 bases : une base "crud" et une base "read".
    Simplement n'est-ce pas illusoire de vouloir attacher des centaines de databases entre-elles ?

    J'utilise effectivement intensivement SQLite. :)
Connectez-vous ou Inscrivez-vous pour répondre.