Salut :

je ne sais pas si Javascript est le forum adéquate, ou si il serait preferable de poster sur SQL :: je cherche un moteur SGB Javascript ::

je réfléchis à un produit devant utiliser des bdd locales en javascript ou du moins un moyens de parcourir de grosses chaines de caractères pour en extraire des lignes de résultats autrement qu'avec "bla-/-bla".split("-/-")._each()

Je sais que webkit et Opera mettent en place indexedDB qui permettra d'ici 1 ou 2 ans de faire du SQL en javascript sur tous les navigateurs,
mais en attendant, et vu le peux de fonctionnalité dont j'ai besoin (ou dont je pourrait me contenter) connaissez vous une/des solution ?
Meme si il faut traduire un mongo ... pas cool, mais ... pk pas ?

j'ai envisager de travailler sur les chaines au format JSON en tapant sur des regexp, je pense facilement pouvoir extraire des lignes contenant x clauses WHERE (sous reserve que les champs des clauses soient dans le meme ordre que dans la chaine de recherche).
Pour le LIMIT, le traitement se ferait post recherche (et là c'est pas cool)

ensuite pour ce qui est de l'update, ce serait aussi avec une regexp tout comme l'insert, je penses que ce serait pas mal ...

le fait de travailler avec des JSON, ça permet de s'appuyer sur un décriptage rapide des portions de chaines extrais (sous reserve de tests, mais tout du moins courant ^^ )


Maintenant, au niveau des pref, j'ai des doutes...

Qd pensez vous ?

thx !

Curieuse idée si on part du principe que la JavaScript est exécuté coté client, donc si la base est coté serveur, ça sous-entend de l'Ajax et un langage serveur en face... aurais-je loupé un chapitre en cours de route ?

non non cyrano, t'as rien loupé !... ...

j'ai 90 % de mon apli qui tourne avec 5 tables, il y a de constantes interventions sur ses tables, et je ne veux pas etre tributaires des 0.x secondes de latences de l'ajax !..; surtout que les gars qui tournent en 3G bataillent !

Autre avantage : en cas de perte de connexion, sans modifier la structure l'apli continue à tourner, il suffit de remplacer le comportement classique de l'ajax par une file d'attente de requetes serveur pour mise à jour des données l'apli coté client sera toujours stable, rapide et souple !?...

Actuellement, je travaille avec de gros Objets JS que je compresse et encrypt qd je veux les communiquer au serveur, je les stockes dans des cookies à chaque maj pour ne pas perdre les données, et lors de l'initialisation, je vérifie l'intégrité des données proposées par le serveur afin de lui proposer le cas échéant une mise à jour.
ça marche bien mais j'ai 100 lignes ... avec 2000 ce sera une autre histoire ^^

ha heuu ..; si p-e t'as loupé un truc :: ce que j'appel des bdd locales sont des bdd stockées dans le navigateur ^^ ....

Ben je n'ai jamais exploré cette idée, et il est vrai que les problèmes de connexion en 3G m'ont créé un petit soucis récemment, mais il faudrait peut-être regarder du coté de Sqlite qui existe peut-être avec une API JS, je n'en ai pas la moindre idée et ce serait tout de même surprenant parce qu'il me semble que ça se saurait, mais là aussi j'ai pu louper quelque chose au passage.

Parce qu'autrement, tu vas travailler en mémoire coté client, donc dépendant de l'architecture matérielle et de la configuration client, et sur un smartphone, ça sera peut-être un peu lourd, sinon tu as les cookies, mais ça reste également assez limité en taille.

Une autre idée à explorer, ce serait du coté de DART, il y a peut-être des projets dans ce sens ?

La cohérence des données a-t-elle sa place dans ton application ?
Si on parlait de synchronisation bdd locale <=> bdd serveur toutes les 20 minutes c'est un point assez lourd...
Car si deux utilisateurs utilisent l'application au même moment il faut bien que ça foute pas le tintouin lorsque tu fais la synchro. Et que se passerait-il si l'utilisateur alpha valide des données qui devraient invalider les actions que fait l'utilisateur bêta ? Entre deux synchro cela pose une certaine incertitude.

Si c'est ce que je crois, ça ne devrait pas être un soucis, mais c'est à Nours312 de confirmer : c'est pour LMB ?
Si c'est ça, il n'y a pas vraiment de concurrence sur les données et il suffirait de mettre un verrou sur certaines données lorsqu'elles sont envoyées vers le client, lequel client devra envoyer un code de déblocage pour mettre à jour les données et permettre l'accès à d'autres utilisateurs, et idéalement il faudrait pouvoir faire un verrou sur les lignes et non sur les tables, mais je ne suis pas certain que ça existe avec MySQL, à vérifier, mais sinon, ça veut dire un verrou par programmation et une table de stockage des verrous avec des timeout pour éviter un blocage trop long. Mais en fin de compte, ça risque de rapidement devenir une galère à gérer...

La cohérence des données a-t-elle sa place dans ton application ?

Je te remercie, mais c'est déja un point que j'ai écarté, il est logique que je ne peux permettre ce genre d'actions, et c'est à moi de veiller à ce que soit les actions demandant validation par le serveur ne puissent etre entreprises sans synchro, soit l'utilisateur soit conscient qu'il est possible qu'il effectue des actions qui ne porteront pas à termes !..

le but de l'apli est vraiment de permettre ce genre d'action, ex :

dans une apli servant à récolter les données pour charger un annuaire, tu as besoin d'avoir les listes des caractéristiques prédéfinies (villes en France, pays, départements, ...) mais pas nécessairement que ton formulaire soit enregistré en live !... tu t'en fout si ça met 2 jour à être posté, par contre pour parcourir les villes, tu apprécie d'avoir un moyens rapide de trier par département ...

@Cyrano :: actuellement mon formulaire tourne en HTML /JS depuis des fichiers locaux et j'arrive à faire des tris sur les villes françaises par département pour les placer dans une <datalist /> (html5) sans trop de latence sur mon smartphone (700mhz peut de RAM ^^ Firefox@android ) le soucy viendra qd je voudrait mettre beaucoup plus de données et que je ferait des recherches complexes et multi-critères ...

[edit] Non, c'est pas pour LMB ^^ .. je recommence à rêver par moi-même et ça fait du bien ^^ ...[/edit]

Alors il faudrait peut-être voir du coté des application Android pour trouver une base de données sur laquelle il serait possible de se connecter en JavaScript. L'idée à priori que je vois, ce serait de créer une appli Android en lien direct avec ton appli PHP. Ultérieurement, il te faudra la même appli fonctionnant sous d'autres OS de smarphone... bon courage.

Mais ça va quand même prendre une certaine place : si on se limite seulement au villes de France avec régions et départements, ça va occuper du terrain, il y a plus de 36000 communes métropole+DOM-TOM. Rajoute un carnet d'adresse là-dedans, et quelques données métier pour ton appli PHP... là, je suis incapable de te dire ce que peut supporter un smartphone en la matière, j'en suis resté au bon vieux téléphone à clapet sans internet et ça me sert ... à téléphoner

nan cyrano, tu fais fausse route :
je ne veux pas avoir un palliatif à un serveur php pour les autres plateformes, je veux créer un moteur BDD en javascript
Ou du moins avoir des pistes pour obtenir de meilleurs résultats que ceux que j'ai actuellement, je reprend ::

chaine : '[{"id":'1', "ville":"ici", "dep":"2"}, {"id":'1', "ville":"là", "dep":"2"}, {"id":'1', "ville":"parLà", "dep":"3"}]' ;
on a un tableau d'objet au format json qui peux facilement etre interprété/généré que ce soit en JS ou en php

on peux facilement récupérer avec une regex les objet "(\{(^\})?\"dep\":\"2\"(^\})?\}) donc contenant le masque ' \"dep\":\"2\" ' de ce faite, on peux faire des recherche et extraire / reconstruire des listes de résultats avec de meilleurs filtres (j’espère) qu'un parcours de toute la collection avec pour chaque objet des vérifications systématiques ... Donc, à ce niveau là, je penses déjà avoir fait un grand pas !...
Maintenant, ça ne résout pas tous les pb !.. dont celui des perfs, car il n'est pas dit que le requête ne retourne pas 1000 résultats, et dans ce cas, j'ai besoin de mettre des limites et mis à part retourner les x premiers éléments en débutant par le numéros y, je ne vois pas comment la regexp puisse améliorer ça ! elle me retournera toujours mes 1000 résultat ce qui me contraindra à utiliser un tableau monstre pour seulement 1 ou deux résultats !...
De plus, je n'ose imaginer les jointures dans un schéma tel que celui-ci


Tu vois le principe ? après, il me semble qu'il y a une version de mongo pour node.js, il va falloir que j'y jette un œil, ça pourrait être inspirant ^^

Merci en tout cas de ta persévérance

Mouais, alors j'ai mal exprimé ma pensée.

Ce que j'ai sommairement compris de ce que tu veux faire : lors d'une première connexion, tu récupères du serveur des collections de données vers le client : ensuite, le client travaille sur ces données et éventuellement lors d'une connexion ultérieure, les mises à jour sont retournées au serveur. Donc, la base que tu veux créer est coté client, et tu te connecterais dessus en JavaScript. C'est bien ça ? Mais ça ne résoud pas le problème de la base elle-même puisqu'actuellement je ne crois pas qu'il en existe qui soient intégrées dans les navigateurs. Un système MongoDb natif dans un Firefox ou un Opera voire même Safari serait la solution idéale, ne rêvons pas trop pour IE, mais en attendant une amélioration de cet ordre, tu n'auras pas un choix considérable et tu devras travailler sur des tableaux, même s'ils sont au format JSON, et donc tu travailleras en mémoire vive faute de pouvoir te connecter sur une base qui conserverait les modifications en attendant l'envoi des mises à jour vers le serveur. Ça t'interdit d'éteindre ton terminal sous peine de perdre tes modifications...

C'est pour ça que je parlais d'une application Android qui implémenterait une base NoSQL de type MongoDB, permettant de ce fait au code client JavaScript de se connecter sur localhost, donc ton smartphone lui-même. Du coup, tu te connectes, les données sont chargées, tu fais tes modifications et tu éteins ton appareil. S'il y a eu connexion à temps pour mettre à jour le serveur pas de soucis, mais sinon, ben pas de soucis non plus puisque les données sont conservées non plus en mémoire mais sur le disque dur. Enfin bon, je ne fais qu'émettre des hypothèses parce que je n'ai jamais eu à traiter ce type de problème et j'ai peut-être éventuellement dit des énormités... .

onc, la base que tu veux créer est coté client, et tu te connecterais dessus en JavaScript. C'est bien ça ? Mais ça ne résoud pas le problème de la base elle-même puisqu'actuellement je ne crois pas qu'il en existe qui soient intégrées dans les navigateurs. Un système MongoDb natif dans un Firefox ou un Opera voire même Safari serait la solution idéale, ne rêvons pas trop pour IE, mais en attendant une amélioration de cet ordre, tu n'auras pas un choix considérable et tu devras travailler sur des tableaux

Salut !... donc pour répondre point par point :
http://www.w3.org/TR/IndexedDB/
https://mikewest.org/2010/12/intro-to-indexeddb
https://developer.mozilla.org/en/Indexe ... dDB_primer

indexedDB est un futur proche, ça fait déja un moment qu'ils y songent, webkit et opéra l'ont mis en place, FF doit etre retardé de 2/3 maj, mais d'ici noel il les aura publier, donc ça va arriver !... quand à IE, http://msdn.microsoft.com/en-us/ie/hh440436 ça devrait arriver aussi

MAIS :: dans l'imédiat, je cherche pas un stockage de 10Go avec des jointures monstrueuses !... je cherche juste un moyen pour parcourir un tableau d'objet plus rapidement ::
en sérialisant la table et en le parcourant avec eds regexp, je penses gagner en temps, mais je ne voit pas comment limiter le nombres de résultats facilement ... en fait le fond de mon pb est là !...

si Quelqu'un à des idées, je vais envisager la phase des tests d'ici peu !..

Merci

La limitation doit se faire côté serveur, pas vraiment le choix.
Faut que ta requête au serveur spécifie l'attribut limit en gros, ainsi ton application ne recevra pas tous les n-uplets.

Ou bien côté client, tu dis avoir un tableau avec tous les résultats. Tu peux le sérialiser partiellement.
En gros faire la limit dessus. Mais niveau perf je doute que ça doit concluant...

Ça ne sera de toutes façons pas de la tarte à mettre au point.

Ce que tu veux faire correspond à une sorte de réplication circulaire partielle entre une base serveur MySQL (ou autre d'ailleurs, peu importe) et une sorte de base noSql coté client qui ne contiendrait que les données pertinentes pour l'utilisateur connecté. Donc le premier problème consiste à isoler ces données pertinentes afin de limiter le volume au maximum. Le problème suivant sera la synchronisation de tout ça après les modifications coté client en gérant les risques de conflit si différents utilisateurs distincts modifient les mêmes données. Mais bon, même en admettant que la question de conflits entre modifications concurrentes soit mise de coté, le problème reste le volume des données à transférer au client.

Tu peux peut-être partir du principe d'un premier chargement d'initialisation qui serait éventuellement long. L'idée générale, c'est que tu aurais au départ une base quasiment complète sur le terminal mobile. Le problème par la suite ne concernerait que les données modifiées d'un coté où de l'autre lors de la synchronisation : comment les identifier, d'un coté comme de l'autre, pour ne faire transiter que ce qui doit l'être ?