SQLite vient d'être porté sous C# pour fonctionner avec .NET

Citation:

---

Envoyé par Emmanuel Lecoester

@smyley :
C'est une belle performance que ce portage mais est-il utile à la communauté et sera-t-il je ne sais pas :aie:

---

Perso j'ai quelque peu de mal à y croire, surtout si c'est un portage à coup de find-replace comme cela a été mentionné plus haut. C'est à dire qui ne tire pas du tout parti de la puissance objet et des types disponibles dans le framework.

peut être que le côté 100% managé du code lui donne un avantage sur sql server CE, il y a aussi une chance qu'on l'utilise comme BDD légère sur mobile.

Cependant il faut garder à l'esprit que... c'est SQLite! Donc des outils d'administrations assez bof (à ma connaissance du moins), pas de contraintes de clef étrangères, typage faible etc...

SQL server CE qui est un produit éprouvé, des kilomètres devant SQLite question fonctionnalité et qui dispose de la version gratuite de SQLSMS, c'est déjà une solution intéressante pour pas un rond (à mon avis).

Firebird a l'avantage de pouvoir être upgradé en version serveur très facilement sans toucher au code de l'application.

VistaDb, bien que payant, est une solution 100% managée très supportée qui a beaucoup à faire valoir...

A noter que ces 3 solutions disposent déjà de drivers ADO.net relativement au point (je dis relativement à cause de firebird mais faudrait que je me remette à jour). Donc quel place pour ce SQLite c# au final? Je suppose les petites applications qui veulent stocker quelques données dans un format un minimum structuré, sans trop d'exigences et avec plus de flexibilité que du XML ou des fichiers plats...
Par contre cette syntaxe dégueulasse mentionnée plus haut par Smyley m'inquiète un peu.

Personellement, pour avoir teste SQL Lite pour des benchmarks, mon avis rejoins celui de skip a savoir ce n'est pas une solution tres interessante en terme de performance.
De plus lorsqu'on utilise des solutions a faible ressource memoire, il ne faut pas s'etonner du fait qu'elles aient des fonctionalites reduites; c'est juste la contre partie :D.


_____________
Fast Embedded DB visit http://www.raima.com/

Citation:

---

Envoyé par Gooom

y a encore mieux : http://sqlite.phxsoftware.com/ :ccool:

---

+1

Cela fait longtemps que je l'utilise aussi.
A mon avis, la version développée dans cette news n'a pas grand intérêt.
Hormis l'intérêt pédagogique.

Je suis en train de migrer un gros front-office d'access vers sqlite avec http://sqlite.phxsoftware.com/ moi aussi.
Je rame quand même pas mal même si sqlite n'en finit pas de m'impressionner.

Il a fallu 'vendre' cette migration, ensuite, il faut tenir la distance. sqlite est très bien mais aussi assez rugueux par rapport à quelque chose d'aussi fini qu'access (et à fortiori sqlserver ..)

Ce portage en c# ne m'inspire rien de bon, défendre la perf du gars qui l'a fait est très bien mais je me demande si ce n'est pas simplement une fausse bonne idée.
Enlever les perfs de sqlite, ajouter des bugs, le déraciner de sa logique c pour faire un portage plus ou moins automatique.... Je pense que le gars a dû bosser dessus mais , je lui suggère d'arréter, laisser le bébé en cc avec son papa et faire quelque chose de plus rentable , désolé

C# n'est pas vraiment une flèche comme language, comparé au C embarqué, c'est comme revenir au 486 (avec un IDE génial il est vrai) ...

Mais ce n'est rien d'autre qu'un super-VB6 tout neuf, pourquoi vouloir lui demander de faire tourner des sous-copies bridées au lieu de lui confier ce qu'il fait de mieux : des IHM fluides, des graphismes super-beaux.

Si on lui connecte des bouts de soft spécialisés, c'est pas pour des prunes !

Le C est inégalable pour faire tourner un sql-engine.

Citation:

---

Envoyé par Gordon Fowler

Elle pourra à présent être utilisée dans des projets conçus avec les outils de Microsoft.NET sans utiliser P/Invoque ou des lignes de code peu sûres.

---

Euh... pourquoi faire du P/Invoke quand on à un provider ADO.NET qui marche super bien ? :koi:

Citation:

---

Envoyé par Gooom

y a encore mieux : http://sqlite.phxsoftware.com/ :ccool:

---

Il est 100% compatible ADO.NET 2.0, supporte l'Entity Framework, et fournit même une classe pour définir ses propres fonctions utilisables dans les requêtes.


En fait je ne vois pas du tout l'intérêt d'un tel portage en gardant la même API : le C# n'est pas du C, la logique n'est pas du tout la même. L'API qu'ils ont pondue est une aberration d'un point de vue POO 8O. En .NET il y a un modèle commun à tous les providers de base de données (ADO.NET) : cette implémentation SQLite ne s'y conforme pas du tout.

Ou alors il aurait fallu un wrapper ADO.NET pour masquer les méthodes de l'API de base, mais au final ce serait quand même plus lent que le provider mentionné plus haut (qui appelle la dll SQLite native, plus rapide)...

Je fais remonter le sujet un peu car j'ai une problématique :


Je cherche à faire une application client/serveur, qui puisse gérer le mode déconnecté.

A deployer sur des postes utilisateurs divers, sans installation.

Je comptais donc opter pour Silverlight 3.0 qui permet le mode hors connexion
et integrer directement une base coté client sans installation (pour lui permettre de bosser en hors connexion).

Donc plusieurs question :

_ Quelle techno de base de donné client utiliser pour le mode offline ?
http://sqlite.phxsoftware.com/ est il parfait pour cela ?
Est ce compatible avec SilverLight ? (jentendais dire que Silverlight ne supportait pas ADO.NET, choses comme ça)

_ Cette techno permet d'elle d'utiliser Sync for ADO.NET ? (afin de resyncrhoniser mes donnée avec ma VRAIE base SQL server 2005 coté serveur, lors de la reconnection au reseau).

Merci de votre réponse.

Citation:

---

Envoyé par Tgaud

_ Quelle techno de base de donné client utiliser pour le mode offline ?
http://sqlite.phxsoftware.com/ est il parfait pour cela ?
Est ce compatible avec SilverLight ? (jentendais dire que Silverlight ne supportait pas ADO.NET, choses comme ça)

---

Effectivement Silverlight ne supporte pas ADO.NET... pour accéder à une base de données, il faut le faire via un service implémenté côté serveur

Par contre, le portage de SQLite en C# pourrait convenir, vu que ça ne repose pas sur ADO.NET...

Citation:

---

Envoyé par Tgaud

_ Cette techno permet d'elle d'utiliser Sync for ADO.NET ? (afin de resyncrhoniser mes donnée avec ma VRAIE base SQL server 2005 coté serveur, lors de la reconnection au reseau).

---

Dans l'absolu, ce serait possible, mais il faudrait implémenter ton propre provider pour la synchro (de base, seuls SQL Server et SQL Server CE sont supportés). Mais vu que ce framework de synchro repose sur ADO.NET, ce n'est pas possible en Silverlight...

Pour le coup, je suis un peu perdu.

Comment sont censé fonctionner les application Silverlight 3.0 en mode déconnecté, si la gestion des bases de données ne se fait pas?

Si il faut installer un serveur SQL local, autant passer à du client lourd non?

Quelquechose m'échappe.


Au final, quelle solution / choix technologique me conseillerais tu pour répondre à ma problématique ?
(sachant que redevelopper un provider moi même est hors de mes compétences je pense).

Citation:

---

Envoyé par Tgaud

Si il faut installer un serveur SQL local, autant passer à du client lourd non?

---

Ca ne servirait à rien puisque Silverlight ne supporte pas ADO.NET

Je sais pas trop quelle est la bonne approche, j'ai pas beaucoup développé en Silverlight, et encore moins en mode déconnecté... Tu peux peut-être garder une copie locale de tes données en XML (ou sous une autre forme).

De toutes façons, ce n'est pas vraiment le bon endroit pour poser ce genre de question... Poste plutôt ta question dans le forum Silverlight