sqlite

Le
Mihamina Rakotomandimby (R12y)
Bonjour,
Pour rapidifier certains projets orientés web, nous avons décidé
d'écrire un squelette de backoffice avec des menus pret et qu'il suffit
d'éditer et de coller aux projets qui s'y prettent.

Pour gérer les entrées du menu du backoffice, nous sommes en train
d'évaluer sqlite.

Il s'agirait pour moi de faire une table dont les enregistrements
seraient des listes chainées.

Le contenu de cette table sera les menus et sous menus du backoffice.

Compte tenu de la simplicité de la structure et des caractéristiques de
sqlite, nous nous sommes orienté vers lui:
- Léger
- supporte ce dont nous avons besoin du SQL
- permet une _lecture_ concurrente

J'ai lu que seul les ecritures concurrentes n'étaient pas supportées,
mais ce n'est vraiment pas un problème: on ne va pas modifier les menus
si souvent que cela.

Est-ce que vous connaitriez des inconvénients de sqlite qui se
mettraient en travers d'un tel choix?

Merci.
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Francois G
Le #21912971
Mihamina Rakotomandimby (R12y) a écrit :
Bonjour,



Bonjour,

Pour rapidifier certains projets orientés web, nous avons décidé
d'écrire un squelette de backoffice avec des menus pret et qu'il suffit
d'éditer et de coller aux projets qui s'y prettent.
[snip]
J'ai lu que seul les ecritures concurrentes n'étaient pas supportées,
mais ce n'est vraiment pas un problème: on ne va pas modifier les menus
si souvent que cela.



Je réponds HS, mais si le but est la rapiditude, je ferai générer un
fichier statique dans un coin qui contiendrait la structure de données
dans le langage choisi. Une inclusion bien placée, et les performances
seront au delà de l'ouverture de la base et du requêtage.

Est-ce que vous connaitriez des inconvénients de sqlite qui se
mettraient en travers d'un tel choix?



Aucun si ce n'est l'overhead cité ci dessus, et je ne pense pas que le
benchmark de la solution soit très couteux s'il s'agit de mettre des
chiffres sur les idées.

--
FG
SQLpro
Le #21912911
Effectivement et dans ce cas un simple fichier XML fera très bien
l'affaire !

A +


--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
Enseignant aux Arts & Métiers PACA et à L'ISEN Toulon - Var Technologies
*********************** http://www.sqlspot.com *************************

Francois G a écrit :
Mihamina Rakotomandimby (R12y) a écrit :
Bonjour,



Bonjour,

Pour rapidifier certains projets orientés web, nous avons décidé
d'écrire un squelette de backoffice avec des menus pret et qu'il
suffit d'éditer et de coller aux projets qui s'y prettent.
[snip]
J'ai lu que seul les ecritures concurrentes n'étaient pas supportées,
mais ce n'est vraiment pas un problème: on ne va pas modifier les
menus si souvent que cela.



Je réponds HS, mais si le but est la rapiditude, je ferai générer un
fichier statique dans un coin qui contiendrait la structure de données
dans le langage choisi. Une inclusion bien placée, et les performances
seront au delà de l'ouverture de la base et du requêtage.

Est-ce que vous connaitriez des inconvénients de sqlite qui se
mettraient en travers d'un tel choix?



Aucun si ce n'est l'overhead cité ci dessus, et je ne pense pas que le
benchmark de la solution soit très couteux s'il s'agit de mettre des
chiffres sur les idées.

Publicité
Poster une réponse
Anonyme