Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
La sérialisation : une alternative ?
Bonjour,
Je suis actuellement en train de développer un petit logiciel de gestion (personnel) et je m'intèroge quant à la possibiltié de substituer ma base de donnée SQL par un mécanisme de sérialisation / désérialisation.
J'aimerais tout simplement savoir si l'utilisation de la sérialisation et de la désérialisation est chose courante et surtout avantageuse.
En vous remerciant d'avance,
Nadd.
siii
salut,
Bien sur c très util, surtout au niveau des WebServices puisque ça facilite le transfer d'objets(BD) en la convertissant en fichiers XML.
D'accord
Mais dans le cas d'une simple application qui n'a pas vraiment grand chose à partager (même si l'idée des WebServices me parait interessante), la sérialisation comporte-t-elle plus d'avantage que l'utilisation d'une base de donnée ?
Cordialement,
Nadd.
mm...
dans une simple application de gestion je ne vois pas vraimnt en quoi ça va t'aider !!!
mais en tt cas c très interessant
bonne chance.
Les performances d'accès, le caching de données, la magie des bindings et la simplicité du SQL te manqueront.
En même temps si sa base de données n'est pas trés complexe ni trés volumineuse, que son application est mono utilisateur (au moins en écriture) alors stocker ses données dans un fichier lui permettrait de se passer de base de données. Je te conseille dans ce cas de sérialiser / désérialiser un DataSet , qui t'offre qques fonctionnalités de requêtage.
Bien, merci beaucoup pour vos réponses. Après avoir bien réfléchit (aux avantages de MSSQL et aux besoins de mon application) j'en ai conclu que MSSQL était indispensable et que la sérialisation / désérialisation ne convenait pas. Toutefois, je ne pense pas que je vais mettre ce procédé, très intèressant, de côté
Cordialement,
Nadd.
A mon sens, ca restera quand meme plus lourd. De plus, si ton application se plante, tu perd ton dataset qui était en mémoire. Sauf si à chaque modification tu le reserialize, ce qui est une sacré perte de temps.Envoyé par Sphax
Je rappelle les propos de Nadd:
Dans ces conditions on peut légitimement se demander l'intérêt d'un gros serveur de base de données, même s'il existe des solutions gratuites. C'est prendre un marteau pour écraser une mouche.Je suis actuellement en train de développer un petit logiciel de gestion (personnel)
Ensuite effectivement si l'appli se plante tu peux perdre des données, mais le but c'est d'écrire une aplli qui ne plante pas (et d'ailleur ça peut arriver aussi avec une base de données, surtout si c'est mal codé), et l'argument de la perte de temps en cas de multiplication des sérialisation/désérialisation peut ne pas compter, vu que c'est un petit projet encore une fois. Bref l'important est d'utiliser des outils adaptés aux problèmes, et un simple DataSet sérialisé comme base de données peut trés bien faire l'affaire dans certains cas.
Comme outil de mor, EUSS (je sais pas pour nHibernate) permet d'enregistrer ses données sous fichier xml (il gere ca tout seul comme un grand)...
Evidemment pour un gros projet tu laisses tomber, mais pour un petit truc perso cela reste suffisant...
Avec leur systeme de requetes, rechercher et mettre à jour la base n'est pas compliqué (transparent pour toi : c'est des requetes opath)
Effectivement, ensuite, intégrer un un gros truc (et se former) pour une petite appli...
Enfin bon, quand j'ai dit petite application, je parlais plus du nombre d'enregistrements qui seront inscrits dans la base de donnée.
L'application que je développe est une application de gestion (qui ne respecte pas vraiment les normes de comptabilité, mais peu importe) qui devra comporter au "finish" tout une serie de trucs : Fiches clients/fournisseurs, devises, opérations d'encodages (financiers, d'achats, de ventes), multi-utilisateur (même si je serai le seul à utiliser l'application) avec mise en place d'un système de niveaux d'accès, ect...
J'ai facilement mis en place le système multi-utilisateur (formulaire login en début d'execution, ...) et j'ai crée mes propres classes "conteneurs" afin de répondre à mes besoins. J'ai décidé de charger en début d'application toutes les données présentes dans la base de donnée et de les stocker dans des collections afin de pouvoir travailler en mode déconnecté (ou presque).
Enfin soit,
Cette application est plus destiné à me faire faire un tour d'horizon du langage et de ses possibilités tout en poussant à fouiner partout lorsque je suis bloqué. C'est plus un apprentissage par la pratique que le développement d'une application utile.
Cordialement,
Nadd.
Le critere de choix est assez simple en fait, ceux qui choisissent la serialisation ou l'xml le decouvrent sur le tard:
Si tu dois, trier, chercher ou regrouper logiquement (JOIN en SQL) ya pas photo c'est la base de donnees
Je rajoute un peu d'informations sur ce thread, j'ai utilisé récement Sqlite sous Linux. J'ai vu qu'une Dll était disponible pour windows. C'est une piste intéressante à suivre.
Tu écrit un couche d'accès au donnée et une couche d'accès à Sqlite. Ton application reste de petite taille pour le moment, tu accèdes facilement à une DB dans un fichier. Demain, ton application grossit, tu devra juste écrire la couche d'accès msSQL, ou autre et ca continuera de fonctioner :-)
Salut,
pour completer les dires de Neptunes, SQLite est vraiment une BDD assez robuste tant qu'on reste dans des optiques personnelles. Pour l'avoir pas mal utilisé, c'est vraiment sympa (Mono fichier pour la base, 1 seule Dll). J'ajouterai qu'il existe un provider pour travailler avec ADO.Net avec SQLite, ici, maintenu (dernier update au 21/07) et bien foutu (une seule DLL à fournir la aussi, englobant le natif Sqlite et le provider).
Enfin pour elargir un peu le champ, je teste depuis quelque temps, une "BDD objet", DB4O, l'avantage est que ta couche d'accès est vraiment reduite (par exemple, une des formes de requetes se fait grace à des predicates<T> et comparer<T>, et tu recuperes en sortie un type implementant IList<T> (que tu peux reinjecter dans un datasource de controles sans plus de fioritures)). Bref, je ne suis qu'au debut des tests, mais pour le moment c'est vraiment sympa, et le fait de ne pas avoir avoir de transition Table <=> objet à faire simplifie grandement les choses (tu stockes un objet, tu recuperes un objet, le tout par serialisation). Pour un usage intensif, je ne sais ce que ca peut valoir, mais pour une appli mono poste avec des besoins reduits, ca peut etre pas mal.
Répondre avec citation
Partager