Results of 0 - 1 of about 0 (0.000 sec.)
- RFC - Persistance: Type de stockage
- @digest: e6f22263c086b491a451f09d0b6d0c4e
- @id: 140339
- @mdate: 2002-08-26T23:15:57Z
- @size: 6216
- @type: text/html
- generator: SGML-Tools 1.0.9
- #keywords: serialisation (16864), sauvegardes (12481), bdd (12233), quantites (11194), stockage (10280), inconvenients (10140), profondeur (8131), entendons (8039), transfert (7666), binaire (7558), chargement (5576), sauvegardant (5156), objets (5030), coherence (5005), avantages (4883), emplacements (4706), recursivement (4449), attributs (4170), manipuler (4074), necessite (4037), sauvegarder (3963), neanmoins (3734), adapte (3632), existants (3547), independant (3511), plateforme (3501), preferons (3453), persistance (3431), concernes (3324), donnees (3279), passons (3237), varient (3157)
- Page suivante Page précédente Table des matières 4. Type de stockage Nous passons ici en revue les différentes méthodes de stockage. 4.1 Format binaire Par format binaire, nous entendons ici le format binaire du JDK utilisé pour la sérialisation des objets. Il n'y a aucun intérêt à en utiliser un autre, nous préférons utiliser ce qui existe déjà et qui marche (à l'exception du bogue sur la sérialisation des chaînes de caractères de plus de 65535 caractères dans le JDK 1.2). La sérialisation permet de sauvegarder un objet dans un flux ou de charger un objet à partir d'un flux. Seuls les attributs sont concernés. Le format décrit quels sont les champs, quel est leur type et quelle est leur valeur. Par défaut, la sérialisation opère en profondeur récursivement, donc sur les attributs objets. En sauvegardant puis en restaurant, un objet identique au précédent est obtenu (seuls les emplacements en mémoire varient). Il est néanmoins possible de définir ses propres méthodes de chargement/sauvegarde. Ex.~: limitation de la profondeur de descente, contrôle des données chargées Les champs 'static' ou 'transient' ne sont pas sauvegardés par la sérialisation. Avantages~: déjà écrit et testé indépendant de la plateforme ou du système de fichiers standard transfert des données via le réseau extrêment facile ne nécessite rien de supplémentaire format concis Inconvénients~: binaire difficile à lire/éditer à la main changement de version du code à gérer manuellement 4.2 Format texte Par format texte, nous entendons ici format XML. Il n'y a aucun intérêt à utiliser à l'heure actuelle un format ASCII simple. De plus en plus d'outils permettent de manipuler de l'XML et les avantages de l'XML par rapport à l'ASCII simple sont nombreux. Avantages~: lisibilité, facilité d'édition peu sensible aux changements du code indépendant de la plateforme ou du système de fichiers outils existants pour lire/écrire l'XML validation Inconvénients~: entièrement à définir et à mettre en place format verbeux, donc long à manipuler 4.3 Base de données (BDD) Il faut séparer les deux types de SGBD que nous sommes susceptibles d'utiliser~: les SGDB relationnels (SGBDR) et les SGBD objets (SGBDO). Les SGBDR ne sont pas adaptés pour sauvegarder directement des objets. Il faut recourir à des identifiants pour lire/écrire les objets. Le schéma de la base n'est pas évident à déduire de la hiérarchie des objets. Les SGBDO s'adaptent plus facilement à la POO. La persistence des objets est beaucoup plus facile à gérer. Avantages~: requêtes sur de grosses quantités de données outils existants cohérence assurée à l'intérieur de la BDD adapté aux très grandes quantités de données scalable Inconvénients~: peu portable lenteur/lourdeur nécessite une BDD administration de la BDD indépendance limitée cohérence mémoire/BDD difficile à gérer, à écrire transfert via le réseau pénible (nécessite une forme intermédiaire) 4.4 Conclusion Le nombre de sauvegardes est très supérieur au nombre de chargements. Typiquement il y a un chargement au démarrage et des sauvegardes régulières jusqu'à l'arrêt ou au plantage. L'utilisation d'une BDD est un gros désavantage pour une implantation chez les joueurs. Autant lors de l'utilisation d'un serveur sur Internet, l'utilisateur n'a rien à faire, autant s'il souhaite avoir son propre serveur sur sa machine cela l'oblige à installer et à administrer une BDD, ce qui n'est pas à la portée de tout le monde. Néanmoins la BDD est le seul système 'scalable'. Dans le cas d'une grande quantité de données, seule la BDD (qui est fait pour ça...) est capable de gérer le volume et d'offrir des performances acceptables. Le fait de cumuler le stockage tout en permettant l'accès est clairement un avantage. La séparation des deux fonctions coûte trop cher pour les gros volumes. Le format XML n'est pas adapté à des sauvegardes fréquentes et rapides en raison de sa verbosité. Par contre il est pratique pour le stockage ou le transfert. Le format binaire est adapté à des sauvegardes pour de petites quantités de données. En particulier, il convient à nos premiers essais et au prototypage. Page suivante Page précédente Table des matières
...
-
http://www.gnu.org/savannah-checkouts/non-gnu/metacosm/fr/RFC/html/Persistence-RFC/Persistence-RFC-4.html
- [detail]
- [similar]
PREV
NEXT