Discussion :

[xercasy]

Bonjour,

je débute dans la programmation et la manière d'enregistrer dans une base de données est flou dans ma tête...
En effet, je ne vois pas "comment" enregistrer un objet quelconque (contenant des pointeurs, collections ...) dans la bdd.

Actuellement je sais sérialiser mes objets avec boost et les enregistrer dans un fichier.

Dois-je également sérialiser mon objet pour pouvoir l'enregistrer dans la bdd? Dois-je enregistrer tous ses attributs (= tous les objets de la collection) un par un ? et lors de la récupération refaire une instance de l'objet avec les mêmes valeurs?

Merci

[Bousk]

Salut,

selon la complexité de l'objet, ça va dépendre.
Si c'est pour stocker des variables simples (string, int, ...), mieux vaut faire une vraie structure de tables.
Si c'est plus complexe, tu serialises avec boost comme actuellement et.. au lieu d'enregistrer dans un fichier, tu enregistres dans ta DB.

[bacelar]

La programmation objet et les bases de données ne sont pas vraiment solubles l'une dans l'autre.

C'est des manières de fonctionner assez différentes, et encore plus en base de données relationnelles.

On ne peut pas vraiment répondre précisément à votre question temps que vous nous indiquez pas plus précisément à quel type de base de données vous faites allusion.

Une base de données relationnelle, NoSql ou Objet ne se comportent pas du tout de la même manière et ne servent pas à la même chose.

Si vous ne voyez pas quel type de base de données vous devez utiliser, il faut que vous nous indiquiez quel est votre objectif.

Sachez qu'il existe toute une panoplie d'outils pour servir de bon entre les langages object et les bases de données.

[xercasy]

Bonsoir,

Salut,
selon la complexité de l'objet, ça va dépendre.
Si c'est pour stocker des variables simples (string, int, ...), mieux vaut faire une vraie structure de tables.
Si c'est plus complexe, tu serialises avec boost comme actuellement et.. au lieu d'enregistrer dans un fichier, tu enregistres dans ta DB.

Je compte en effet utiliser des objets assez complexes ... m'enfin si nous avons la même définition d'un objet complexe
Je n'ai pas encore assez de recul mais ça me parait étrange de sérialiser des objets pour les enregistrer dans une base de données dans la mesure ou je pense qu'il sera impossible de faire des des requêtes SQL pour interroger la base ... Il faudra donc que mon programme récupère tous les objets et qu'il fasse des recherches par lui-même sans passer par le SQL.

La programmation objet et les bases de données ne sont pas vraiment solubles l'une dans l'autre.
C'est des manières de fonctionner assez différentes, et encore plus en base de données relationnelles.

On ne peut pas vraiment répondre précisément à votre question temps que vous nous indiquez pas plus précisément à quel type de base de données vous faites allusion.

Une base de données relationnelle, NoSql ou Objet ne se comportent pas du tout de la même manière et ne servent pas à la même chose.

Si vous ne voyez pas quel type de base de données vous devez utiliser, il faut que vous nous indiquiez quel est votre objectif.

Sachez qu'il existe toute une panoplie d'outils pour servir de bon entre les langages object et les bases de données.

Je pensais utiliser le SQLite puisque mon application n'aura pas besoin d'avoir une base de données sur un serveur distante. Ensuite comme nous avons vu (ou plutôt seulement commencé) le SQL je ne me vois pas donc pas faire du NoSql.
Je viens de voir en effet qu'il existe des bases de données orienté objet, je vais donc essayer de comprendre ce soir comment elles fonctionnent. Bien qu'il me semble bisard qu'on puisse faire des requêtes "select" afin de récupérer seulement les objets qui nous conviennent.

[Bousk]

Tu parles déjà pas de la même chose. Maintenant tu veux faire des requêtes de recherche dans ta DB... on ne parle donc plus de simple stockage.
Si ton but c'est de manipuler une DB, alors tu fais une vraie DB correctement architecturé.
En gros, chaque classe correspond à une table. Chaque variable membre à un champ.
Tu utilises des clés étrangères pour les relier. Etc...
Bref du DBA, et pas du C++ en fait. Parce que ton C++ ça se limite à faire du CRUD.

[xercasy]

Donc si j'ai bien compris du coté de mon application je ne dois plus sérialiser mon objet?
Je dois donc lorsque je souhaite récupérer un objet prévis dans la bdd (ou plusieurs) le(s) reconstruire avec un new.
Et a chaque modification, par exemple j'ajoute un objet dans la collection contenu dans mon objet, j'ajoute directement cet nouvel élément dans la bdd?
Également c'est la première fois que je souhaite intégrer une base de données dans une petite application en C++. Pour moi comme je manipule des objets il faut obligatoirement prendre une base de données orientée objet comme PostgreSQL. Mais comme il me faut une base de données seulement local je vais utiliser SQlite qui est elle propose un moteur de bd relationnel : suffisant même si je fais de la programmation objet?

Ce que je faisais avant est d'enregistrer ma collection d'objet directement dans un fichier, en sérialisant le tout avec boost. Mais a moins que je me trompe, lorsque je voulais récupérer une partie de cette collection je dois absolument tout récupérer dans l'application et qu'ensuite faire la sélection !

En tout cas, merci pour les réponses.

[bacelar]

Vous n'êtes pas très précis sur vos objectifs, on ne peut donc pas être très précis sur les recommandations.

Je tiens juste à mentionner un type d'outils qui peut vous faire gagner beaucoup de temps dans le cas de l'utilisation d'un SGBD relationnel, un ORM (Object Relational Mapper).
Des Framework comme Qt ou .NET disposent directement de ce type d'outils.

[koala01]

Salut,

De manière générale, il faut veiller à séparer aussi clairement que possible les différents besoins auxquels on doit répondre. L'une des possibilités à envisager est le patron connu sous le nom de MVC (Model, View, Controler) qui nous incite à séparer clairement les données "métier" (tous les objets utilisés par ton application), les "contrôleurs" (des objets qui s'assurent que l'on ne modifie pas les données métiers de manière incorrecte) et les "vues" qui correspondent à une représentation, de toutes les données métier ou d'une partie de celles-ci à un instant T de l'exécution.

Les données qui sont sauvegardées (que ce soit dans une base de données ou dans un fichier, quel que soit le format) doivent (devraient ) être considérées comme des vues dans le sens où elle représentent "tout ou partie" des données telles qu'elles apparaissent au moment de l'enregistrement

Pour enregistrer ces données dans un fichier, on va utiliser des bibliothèque de sérialisation, et, pour les enregistrer dans une base de données relationnelle, on va utiliser des requètes SQL, mais, ce qui est particulièrement intéressant à remarquer, c'est que les données qui seront envoyées dans le fichier seront très vraisemblablement identiques à celles qui seront utilisées pour la génération de la requête SQL: ce seront des types simples (différents types primitifs, chaines de caractères, éventuellement données "raw" pour les images par exemple,...)

Dans l'autre sens, qu'il s'agisse d'un enregistrement issu d'une requete de sélection dans une base de données ou des données récupérées depuis un fichier, tu peux tout à fait considérer que tu disposes systématiquement de la même chose : un ensemble de données "simples" (types primitifs, chaines de caractères, données "raw") que tu devras utiliser pour "recréer" l'objet à l'identique de son état lors de l'enregistrement.

Tout cela pour dire que, bien qu'il y ait des différences importantes quant à la manière dont on va assurer la persistance des objets, il doit parfaitement être possible de créer des abstractions qui te permettent d'écrire dans un fichier ou de récupérer tes objets au départ d'un fichier que de le faire au travers d'une base de données. La seule différence entre les deux étant la forme prise par la sérialisation

[ternel]

Je t'invite à te renseigner sur la notion de DAO (data access object)
C'est une manière de créer une couche intermédiaire entre les données métiers et la base de données.
L'intérêt, c'est aussi de pouvoir changer la structure de la base pour l'optimiser sans casser la partie métier de l'application (normalement, seul le DAO change)

[xercasy]

Merci pour ces réponses, je vais en tenir compte et essayer d'appliquer vos conseils