Limites bases SqlCe vs Access [Résolu]

[KaloOopS]

Bonsoir,

j'avais déjà fait un post sur les bases de données, mais à présent j'ai un peu plus d'éléments, d'où de nouvelles interrogations

1 : j'ai fait un chrono (avec stopwatch) pour comparer les 2 bases
lorsque je fais 100 INSERT via une boucle, la base Access est 3 fois plus rapide !! mais lorsque je fais des SELECT, SqlCe est plus rapide d'environ 15%

2 : y a-t-il un nombre maxi de lignes (avec environ 12 colonnes de int et varchar(10) par exemple) pour les bases sous SqlCe ou Access ?

3 : quelle base choisir si j'ai 40000 enregistrements (INSERT) / jour, mais que je dois pouvoir aussi consulter dans la journée (SELECT) ? est-ce que c'est beaucoup pour ces bases "simples"

4 : si je dois vendre mon application (ou l’intégrer dans le prix d'un équipement), dois-je payer (ou indirectement faire payer) une éventuelle licence ?

5 : dois-je prévoir d'utiliser une autre base ? SQL, Oracle, ...

merci

@+

KaloOopS

[StringBuilder]

Bonjour,

Alors voici mes réponses par rapport à mon vécu :

1/ Cela ne m'étonne pas. Access possède un moteur un peu plus "évolué" que SQL Server CE, et se comportera davantage comme un réel SGBD : performances inférieures en INSERT/UPDATE, mais meilleures en SELECT contraitement à SQL Server CE qui se comporte plus comme une base fichier (excellentes performances en INSERT/UPDATE, mais lent pour les SELECT).

2/ Il n'y a pas de limite "logicielle". En revanche, les performances ont tendance à s'effondrer passé une certaine taille. Access, c'est autour de 100 Mo, surtout si la plupart des données sont dans la même table. Cela dépend aussi de la machine et de la mémoire dispo. Sur SQL Server CE, je pense que la limite est bien plus haute (toujours parcequ'il s'apparente à une base fichier)

3/ Il faut que tu vérifies sur les UPDATE et SELECT sont complexe ou non (jointures, sous-requêtes, etc.) Access sera meilleurs dans ce cas. Si les SELECT sont "unitaires", alors SQL Server CE devrait s'imposer comme choix.

4/ Non, les deux bases sont gratuites et distribuables librement.

5/ SQL Server Express offrirait de meilleures possibilités. Si tu veux conserver la simplicité et la possibilité d'"embarquer" la base, alors SQL Lite sera un très bon choix.

[tomlev]

Envoyé par KaloOopS

1 : j'ai fait un chrono (avec stopwatch) pour comparer les 2 bases
lorsque je fais 100 INSERT via une boucle, la base Access est 3 fois plus rapide !! mais lorsque je fais des SELECT, SqlCe est plus rapide d'environ 15%

Et si tu fais tes inserts dans une transaction ? Dans ce cas je parie que SQL CE sera plus rapide

Envoyé par KaloOopS

2 : y a-t-il un nombre maxi de lignes (avec environ 12 colonnes de int et varchar(10) par exemple) pour les bases sous SqlCe ou Access ?

Peut-être, mais à mon avis la limite est suffisamment élevée pour que tu n'aies pas à t'en préoccuper. De toutes façons, si ta base grossit beaucoup, tu auras besoin d'un SGBD plus évolué bien avant d'atteindre cette limite (si elle existe)...

Envoyé par KaloOopS

3 : quelle base choisir si j'ai 40000 enregistrements (INSERT) / jour, mais que je dois pouvoir aussi consulter dans la journée (SELECT) ? est-ce que c'est beaucoup pour ces bases "simples"

4000 lignes c'est rien du tout, c'est une toute petite base. Moi je choisirais de toutes façons SQL CE (n'importe quoi plutôt qu'Access !). Access est un outil bureautique, pas un vrai SGBD ; on peut l'utiliser comme SGBD pour une application, mais c'est pas vraiment pour ça qu'il est conçu.

Envoyé par KaloOopS

4 : si je dois vendre mon application (ou l’intégrer dans le prix d'un équipement), dois-je payer (ou indirectement faire payer) une éventuelle licence ?

Pour Access je sais pas. Pour SQL CE, c'est gratuit, pas besoin de licence particulière. Tu as juste une DLL à inclure avec ton exécutable (pour Access, rien à installer a priori, le moteur Jet est inclus dans Windows)

Envoyé par KaloOopS

5 : dois-je prévoir d'utiliser une autre base ? SQL, Oracle, ...

Ca dépend de ton besoin... L'avantage de bases comme SQL CE, Access ou SQLite, c'est qu'elles sont basées sur des fichiers, il n'y a pas besoin de serveur. Ca fait que c'est nettement plus simple à déployer et à configurer.

Après, des bases comme SQL Server, Oracle ou MySQL sont mieux adaptées pour la montée en charge (nombre d'utilisateurs simultanés, volume de données, etc), mais si c'est juste une application pour un utilisateur en local ça ne vaut probablement pas le coup.

Envoyé par StringBuilder

Access possède un moteur un peu plus "évolué" que SQL Server CE, et se comportera davantage comme un réel SGBD

Euh... j'aimerais bien savoir sur quoi tu te bases pour dire ça

[tomlev]

Envoyé par KaloOopS

1 : j'ai fait un chrono (avec stopwatch) pour comparer les 2 bases
lorsque je fais 100 INSERT via une boucle, la base Access est 3 fois plus rapide !! mais lorsque je fais des SELECT, SqlCe est plus rapide d'environ 15%

Bon, je trouvais ça un peu bizarre ton histoire, alors j'ai testé...

A mon avis, le test sur l'insertion de 100 lignes ne veut pas dire grand chose, parce que c'est trop rapide pour que les différences observées soit significatives. Il y a trop de choses qui peuvent interférer sur une opération aussi courte. En plus, tout dépend de comment tu as codé ton test ; pour que ce soit significatif, il faut que les conditions soient exactement les mêmes pour les 2 SGBD.

J'ai refait le test avec un code exactement équivalent pour 4 SGBD différents, en insérant 100000 lignes avec ou sans transaction :

System.Data.OleDb (with transaction) - 00:00:18.8895313
System.Data.OleDb (no transaction) - 00:00:27.7392630
System.Data.SqlServerCe.3.5 (with transaction) - 00:00:03.3294750
System.Data.SqlServerCe.3.5 (no transaction) - 00:00:03.5793892
System.Data.SqlServerCe.4.0 (with transaction) - 00:00:03.5593406
System.Data.SqlServerCe.4.0 (no transaction) - 00:00:04.0767597
System.Data.SQLite (with transaction) - 00:00:00.4991759
System.Data.SQLite (no transaction) - J'attends encore

Donc clairement, Access est BEAUCOUP plus lent que SQL CE, ce qui ne me surprend pas vraiment ; et SQLite bat SQL CE à plate couture quand il y a une transaction... mais est complètement dans les choux si on ne met pas une transaction explicite (c'est parce qu'il crée implicitement une transaction pour chaque commande s'il n'y en a pas une explicitement définie)

Le code du test :
http://pastebin.com/6EwVBNTe
(exécuté dans LinqPad)

[StringBuilder]

Envoyé par tomlev

Euh... j'aimerais bien savoir sur quoi tu te bases pour dire ça

Il supporte bien plus de fonctionnalités SQL que SQL Server CE (sous-requêtes notamment). Pour cette raison, il me fait bien plus penser à un SGBD "classique", alors que SQL Server CE me fait fortement penser au drivers JET qui joue avec des fichiers dBase, qui possède les mêmes limitations (mais aussi moins d'avantages, SQL Server CE c'est pas pourri non plus )

Après, niveau performances, ok, le test démontre que finalement, Access est bien plus lent.

[tomlev]

Envoyé par StringBuilder

Il supporte bien plus de fonctionnalités SQL que SQL Server CE (sous-requêtes notamment).

Effectivement, je ne savais pas que les sous-requêtes n'étaient pas supportées dans SQL CE... c'est bien dommage

Envoyé par StringBuilder

Pour cette raison, il me fait bien plus penser à un SGBD "classique", alors que SQL Server CE me fait fortement penser au drivers JET qui joue avec des fichiers dBase, qui possède les mêmes limitations (mais aussi moins d'avantages, SQL Server CE c'est pas pourri non plus )

Bah justement, c'est Access qui utilise le moteur JET, pas SQL CE...

[StringBuilder]

Envoyé par tomlev

Effectivement, je ne savais pas que les sous-requêtes n'étaient pas supportées dans SQL CE... c'est bien dommage

Ben pas la version 4 pour Windows Phone, ou alors il faudra qu'on m'explique la syntaxe.

Envoyé par tomlev

Bah justement, c'est Access qui utilise le moteur JET, pas SQL CE...

Je parle du support des fichiers dBase, qui est extrêment limité (mais pour de l'embarqué, tout à fait raisonnable).

[tomlev]

Envoyé par StringBuilder

Ben pas la version 4 pour Windows Phone, ou alors il faudra qu'on m'explique la syntaxe.

Je confirme, j'ai testé en 3.5 et 4.0, et c'est visiblement pas supporté...

[StringBuilder]

Envoyé par tomlev

Je confirme, j'ai testé en 3.5 et 4.0, et c'est visiblement pas supporté...

Je suis désolé alors, méa culpa.

Soit je confond avec autrechose, soit je me suis arrêté trop tôt lorsque j'ai rencontré une erreur.
J'avais en mémoire d'avoir été très déçu par le non support d'une fonctionnalité qu'Access supportait. Peut-être autrechose, ou moi qui me suis planté lorsque j'ai voulu m'en servir.

[tomlev]

Envoyé par StringBuilder

Je suis désolé alors, méa culpa.

Euh... pourquoi ? J'ai dit que j'avais testé, et que je confirmais ce que tu avais dit. Les sous-requêtes ne sont effectivement PAS supportées, donc on est d'accord

[Mat.M]

Envoyé par KaloOopS

3 : quelle base choisir si j'ai 40000 enregistrements (INSERT) / jour, mais que je dois pouvoir aussi consulter dans la journée (SELECT) ? est-ce que c'est beaucoup pour ces bases "simples"

mef Access ne supporte pas le multithreading, les autres BDD oui.
C'est vraiment bien si tu fais un SELECT une autre opération en même temps.
L'intérêt du multithreading c'est que tu peux faire plusieurs choses en même temps.
Access ne permet pas les accès concurrentiels la plupart des autres bases oui selon les modes optimistes, pessimistes etc...

[KaloOopS]

Bonsoir

merci pour vos réponses et vos tests (va falloir que j’étudie le code car c'est pas mal ce truc pour alterner entre différentes bases )

Envoyé par tomlev

4000 lignes c'est rien du tout, c'est une toute petite base.

c'était 40 000 et non 4 000 mais bon je pense que les réponses sont les mêmes

à partir de combien d'enregistrements par jour on peut considérer que c'est une "bonne" ou "grosse" base ??

Et si tu fais tes inserts dans une transaction ?

heu c'est quoi une transaction ??

autre question : est-ce que SQLite est libre de licence quelconque ??

merci

@++

KaloOopS

[StringBuilder]

Envoyé par tomlev

Euh... pourquoi ? J'ai dit que j'avais testé, et que je confirmais ce que tu avais dit. Les sous-requêtes ne sont effectivement PAS supportées, donc on est d'accord

Ah ok, je croyais que je devenais chèvre

[StringBuilder]

Envoyé par KaloOopS

Bonsoir

merci pour vos réponses et vos tests (va falloir que j’étudie le code car c'est pas mal ce truc pour alterner entre différentes bases )



c'était 40 000 et non 4 000 mais bon je pense que les réponses sont les mêmes

à partir de combien d'enregistrements par jour on peut considérer que c'est une "bonne" ou "grosse" base ??

heu c'est quoi une transaction ??

autre question : est-ce que SQLite est libre de licence quelconque ??

merci

@++

KaloOopS

Tout dépends de la durée de vie des enregistrements : 40 000 enregistrements par jour, s'ils ne sont stockés que 7 jours, c'est peanuts.
Si tu conserve 5 ans d'historique, ça va vite devenir considérable (73 000 000 enregistrements au bout de 5 ans), d'autant plus que j'imagine qu'il n'y a pas qu'une seule table qui grossisse.

Pour une telle volumétrie, ni Access, ni SQL Server CE ne tiendront la charge : tu pourras effectivement travailler avec un tel volume, mais les performances seront fortement dégradées (quoique Access, on arrive proche du point de non retour).

Une transaction, c'est la possibilité de garantir l'intégrité des données en associant plusieurs actions dans la base en une seule, et en séparant les données en cours de modifications (visibles par la seule personne qui les modifie) et les données intègres (visibles par tous).
Le meilleur exemple d'une transaction, c'est une opération de débit sur un compte comptable : un crédit doit obligatoirement être inscrit en même temps dans un autre.
Si l'une des deux écritures tombe en erreur, alors il faut qu'aucune des deux écritures ne soit passée. Idem, personne ne dois pouvoir lire les lignes de débit que tu as inserré avant que tu aies fini d'écrire les lignes en crédit.

Pour qu'un SGBD-R puisse porter le nom de "-R", il faut qu'il supporte un minimum les transactions. Access et SQL Server CE les supportent. Mais contrairement à SQL Server Express, Oracle, Postgre-SQL ou SQL Lite, ils les supportent que partiellement, et avec des performances catastrophiques (surtout Access).

SQL Lite, si je ne m'abuse, est distribué sous licence GNU/GPL. A vérifier sur leur site.

[KaloOopS]

Envoyé par StringBuilder

Tout dépends de la durée de vie des enregistrements : 40 000 enregistrements par jour, s'ils ne sont stockés que 7 jours, c'est peanuts.
Si tu conserve 5 ans d'historique...

Mes enregistrements sont pour faire un suivi de production

40000 est à mon avis le cas extrême, car même si nous faisons des machines capables de faire des cadences de 1 pièce toutes les 2 secondes, à mon avis avec de telle cadence, le client doit avoir sa propre traçabilité et non pas une solution indépendante vendue par son fournisseur (en l'occurence nous), malheureusement

pour la durée de vie, normalement on fait des machines solides dans le temps

donc a moyen terme vu qu'il y ait des fortes probabilités d'avoir de gros volumes je vais me diriger vers SQLite

merci pour vos réponses

@++

KaloOopS

[KaloOopS]

Tom,

Envoyé par tomlev

Le code du test :
http://pastebin.com/6EwVBNTe
(exécuté dans LinqPad)

je rebondis sur ton post quels seraient les using pour se servir de ton exemple si je devais l'integrer dans VSE ?
est-ce possible de jongler entre plusieurs types de SGBD ? sans changer/adapter le code en fonction de telle ou telle base

merci

@++

KaloOopS

[tomlev]

Envoyé par KaloOopS

heu c'est quoi une transaction ??

En gros, c'est un moyen de "grouper" plusieurs opérations pour garantir la cohérence des données. Soit toutes les opérations réussissent et sont "validées" (commit) de façon atomique (comme s'il n'y en avait qu'une), soit on annule tout (rollback). Comme ça on est sûr que les données ne se retrouvent jamais dans un état "bancal" et incohérent.

Wikipedia t'expliquera ça mieux que moi
http://fr.wikipedia.org/wiki/Transac...onn%C3%A9es%29

Envoyé par KaloOopS

autre question : est-ce que SQLite est libre de licence quelconque ??

C'est dans le domaine public, il n'y a aucune restriction d'utilisation.
http://www.sqlite.org/copyright.html

Envoyé par StringBuilder

Pour qu'un SGBD-R puisse porter le nom de "-R", il faut qu'il supporte un minimum les transactions.

Tu es sûr ? Il me semble que le "R" signifie seulement "relationnel", ce qui n'implique pas le support des transactions. Mais en pratique, je ne connais aucun SGBDR qui ne les supporte pas...

Envoyé par StringBuilder

SQL Lite, si je ne m'abuse, est distribué sous licence GNU/GPL. A vérifier sur leur site.

Non, et heureusement... la licence GPL est très restrictive, si c'était ça on ne pourrait pas utiliser SQLite dans des projets commerciaux par exemple.

Envoyé par KaloOopS

je rebondis sur ton post quels seraient les using pour se servir de ton exemple si je devais l'integrer dans VSE ?

Je sais plus exactement... a priori je dirais ceux là :

System.Data
System.Data.Common
System.Diagnostics (pour le Stopwatch)

De toutes façons Visual Studio peut ajouter automatiquement les using manquants (clique sur le Smart Tag sur les symboles qu'ils ne reconnait pas)

Envoyé par KaloOopS

est-ce possible de jongler entre plusieurs types de SGBD ? sans changer/adapter le code en fonction de telle ou telle base

C'est possible dans une certaine mesure... Le langage SQL n'est que partiellement standardisé, chaque SGBD a ses propres spécificités. Il y a donc des instructions qui seront supportées par certains SGBD et pas par d'autres. Dans la pratique, on peut donc rarement être vraiment indépendant du SGBD utilisé. Dans mon exemple c'est possible, parce que je n'ai utilisé que des instructions très basiques et complètement standard, mais dans une "vraie" appli on est souvent obligé d'avoir au moins un peu de code spécifique à un SGBD.

Cela dit, le fait de pouvoir faire abstraction du SGBD reste intéressant et utile : si tu isoles bien le code spécifique du code générique, ça fait quand même nettement moins de travail le jour où tu veux changer de SGBD...

[KaloOopS]

Merci pour encore pour toutes ces réponses

@++

KaloOopS