Discussion :

[free07]

Bonjour,

Je ne sais pas si je suis dans le bon forum mais je me pose une question existentielle sur les modifications en BD.
Voila, je bosse sur un projet qui ne contient qu'une dizaines de tables avec peut être pour une ou deux d'entre elles, plusieurs milliers d'enregistrements.

Lorsque j'ouvre la BD, je charge toutes les informations en mémoire.

Ensuite, lorsque l'utilisateur fait des modifications, je me demande quel est le meilleur moyen pour gérer ces modifs, par exemple :

1 - Je conserve ses modifs en mémoire et lorsque l'utilisateur quitte le programme, je fais une demande de confirmation pour sauver toutes ces modifs dans la BD
ou
2 - Dès que l'utilisateur fait une modif, j'applique cette modif aussi dans la BD
ou alors
3 - un mixte des deux, cad que pour certaines modifs je le fais qu'en mémoire et pour d'autres, je fais la modif aussi dans la BD mais je crains que cela soit déroutant dans la bonne utilisation du programme.

Comment faites vous pour gérer cela lorsque vous devez gérer une BD de petite taille ?
Tout en préservant l'intégrité des données.
Merci pour vos avis

[punkoff]

Tout en préservant l'intégrité des données.

Bonjour,

Le seul moyen de préserver l’intégrité des données c'est de les stocker sur un support physique.

A partir de là, vous n'avez plus de question à vous poser...

[free07]

Je crois que je vais mettre à jour la BD lorsque l'utilisateur le souhaite et lui laisser cette possibilité lorsqu'il fermera l'appli.
Cela lui permettra d'annuler ses modifs en cas d'erreur de sa part.

En mémoire, je vais indiquer l'état des enregistrements : inchangé, modifier ou supprimer

Ceci me permettra de faire les changement en BD en une seule fois.

[SQLpro]

Votre pratique est stupide. Vous réinventez la roue. Ce que vous voulez faire un SGBDR de type C/S le fait de manière native et surtout optimisé !

Bref, formez-vous !

A +

[free07]

C'est toujours agréable d'avoir une réponse aussi constructive...

Je travaille avec une BD local et SQlite, merci de m'orienter vers une solution plus constructive ou de m'apporter une précision qui me permettrait d'avancer, sinon, c'est même pas la peine...

[SQLpro]

Hé bien plutôt que de travailler avec SQL Lite utilisez par exemple PostGreSQL qui fait tout ce que vous voulez faire sans vous le dire et de manière optimisé;

La vocation de SQL LIte est de l'embarqué mono processus... Pas du multiutilisateur !!!

En général il faut utiliser un outil adapté et non pas adapté l'utilisateur à l'outil...

A +

[free07]

La vocation de SQL LIte est de l'embarqué mono processus... Pas du multiutilisateur !!!

Oui je sais et c'est pour cela que je l'utilise, l'application n'est pas multi-utilisateurs et doit fonctionner sur de l'embarqué aussi.

Je viens de voir que SQLite a maintenant un méchanisme de SAVEPOINT/RELEASE pour la gestion imbriquées des transactions, je vais faire des tests mais il se peut fort bien que cela puisse résoudre mon problème

Est ce que vous pensez à ce méchanisme aussi ou bien faites vous allusion à autre chose ?

[SQLpro]

Les transactions imbriquées, cela n'existe pas. Votre session est en état transactionnelle ou ne l'est pas. Les SAVEPOINT servent à faire du ROLLBACK partiel.

Quand vous dite embarqué vous visez quoi au juste ? Tablette ? Smartphone ?? Ou missile ???

A +

[pacmann]

Salut,

Tout le monde sur ce forum te donnera le même conseil que SQLPro, les insultes en moins : adopte si tu le peux un SGBD "normal" qui gère les transactions. Ne rajoute pas une couche pour gérer la persistance des données : code des transactions qui correspondent à des blocs de modifications cohérentes de ton système, rollback ou commit en fonction de ce que tu veux en faire.

Faire les modifs en BDD "une seule fois" n'a pas en soi de plus value (ni de sens).

Si tu veux des conseils en usine à gaz pour gérer manuellement ce niveau de fonctionnement qui est pris en charge par le SGBD, tu n'es effectivement pas sur le bon forum... (je suppose qu'il doit y avoir une foule de mordus de code brutal qui n'aiment pas les SGBD qui s'amusent à faire ce genre de choses)

[free07]

Les transactions imbriquées, cela n'existe pas. Votre session est en état transactionnelle ou ne l'est pas. Les SAVEPOINT servent à faire du ROLLBACK partiel.

Quand vous dite embarqué vous visez quoi au juste ? Tablette ? Smartphone ?? Ou missile ???

A +

Tablette et smartphone sous IOS dans un 1er temps puis android ensuite.

Et sinon, vous avez une suggestion pour mon problème ?

Merci

[free07]

Salut,

Tout le monde sur ce forum te donnera le même conseil que SQLPro, les insultes en moins : adopte si tu le peux un SGBD "normal" qui gère les transactions.

SQLite gère les transactions.

Faire les modifs en BDD "une seule fois" n'a pas en soi de plus value (ni de sens).

Ok, je vois que je dois abandonner cette idée.

Si tu veux des conseils en usine à gaz pour gérer manuellement ce niveau de fonctionnement qui est pris en charge par le SGBD, tu n'es effectivement pas sur le bon forum... (je suppose qu'il doit y avoir une foule de mordus de code brutal qui n'aiment pas les SGBD qui s'amusent à faire ce genre de choses)

Loin de moi cette idée, je ne cherche pas à faire une usine à gaz et c'est pour cela que j'ai posté içi, n'étant pas un spécialiste SGBD, je cherche à me renseigner avant de me lancer dans cette fonctionnalité et je m'aperçois qu'elle est un peu farfelue.

Merci pour ton aide

[pacmann]

Cela dit, il faut peut être consulter le forum qui correspond à de l'embarqué smartphone et tout ça (j'avais pas vu, désolé).

En fait, quand je te disais que ça n'a pas de sens de vouloir gérer manuellement en cache les transactions, c'était par rapport à un SGBD normal qui gère lui-même très bien son cache.

Pour aller plus loin, sous Oracle par exemple, les commit ne génèrent quasi aucune contention (la gestion physique / cache étant par ailleurs partiellement décorrelée du commit / rollback).

Donc en gros je n'oserais pas affirmer des trucs pour ton cas

[pacmann]

Bonjour,

Le seul moyen de préserver l’intégrité des données c'est de les stocker sur un support physique.

A partir de là, vous n'avez plus de question à vous poser...

Désolé, je ne suis pas d'accord.
L'intégrité des données, ce sont les transactions et l'implémentation du SGBD de l'intégrité des données.
Si le système crash pendant l'écriture, c'est l'implémentation de la procédure de reprise qui garantit l'intégrité des données.

Sous Oracle par exemple, tu peux écrire sur le disque des données non commitées, et tu peux ne pas écrire sur le disque des données commitées.

Après le crash, le tout est de faire le tri entre ce qui est écrit sur le disque, ce qui est validé par des checkpoints, ce qui est dans la redo log, ce qui est commité où non...