J’ai regardé le mouvement NoSQL évoluer au fil des années. On y retrouve à peu près tout ce qui fait l’informatique depuis que le monde IT est monde : brillance et troll, hype et génie, utile et gadget, buzz et fact, sam et max, etc.
De plus on peut mettre n’importe quoi sous le label NoSQL, et du coup ça a été fait. En fait un fichier est déjà une base de données NoSQL :)
Mais rant mise à part, des projets comme redis, riak, elastic search ou mongodb changent vraiment la donne.
Malheureusement, tout comme d’autres technos du moment (prog asychrone, tout-http, pre-processeurs, generateurs…), les gens ont tendance à l’utiliser comme la barre de fer, la silver bullet, le passe-partout, le tournevis sonique, bref, le truc à tout faire.
L’adage populaire dit “quand on a un bon marteau, tous les problèmes ressemblent à des clous”. Or, je constate qu’au dessus de ça, les dev appliquent aussi souvent le dicton préféré d’un de mes colocs : “arrête de taper si fort, prend un plus gros marteau”.
Ca donne du NoSQL utilisé partout, pour tout, brandi comme LA solution, vendu à des débutants comme une panacée de traitement d’informations. Zob, vous vous doutez bien que ça pose problème, non ?
Anti-fact 1 : NoSql, c’est plus facile pour démarrer
Il n’existe pas à l’heure actuelle de base NoSQL embarquée qui arrive à la cheville de SQLite : ça marche partout, dans tous les langages, sans rien à avoir installer ou configurer pour la plupart des langages.
Dès que vous demandez à un débutant d’installer un truc, vous rajoutez une barrière d’entrée énorme.
De plus, il y a beaucoup, beaucoup, beaucoup plus d’hébergeurs qui fournissent du SQL que du NoSQL en solution par défaut. Et comme toute les technos legacy, il y a 100 fois plus de doc.
Enfin, il y a la fameuse question du “quoi” ? Quel système allez-vous installer ? Couch ? Casssandra ? Mongo ? On parle de NoSQL, ou de schemaless ? C’est pas la même chose ? Memcache et Redis, c’est que pour le cache ? Elastic Search, c’est que pour la recherche de texte ? Les données géographiques, je les mets dans quoi, mongo ou un GIS spécialisé ? Attends, j’ai entendu parler d’une super bdd de graph…
L’abondance de solutions, le manque de recul et les informations contradictoires disponibles rendent non seulement le choix difficile, mais en plus hasardeux. Car contrairement au monde du SQL, se gourrer en NoSQL peut vous pourir toute votre archi.
Souvenez-vous qu’il est beaucoup plus difficile de migrer son système de base de données NoSQL d’une solution à une autre car il n’y a pas ce petit détail en commun entre les produits : le SQL justement.
Anti-fact 2 : Avec NoSql, pas besoin de réfléchir à son modèle de données
Je crois que c’est ce qui me fait le plus grincer des dents. Les gens qui disent qu’on peut tout mettre dedans, hop, et on verra plus tard. J’ai vu les pires modèles de données possibles stockés en MongoDb ou Redis, parceque les gars qui avaient travaillé dessus avait juste dumpé leurs données sans réfléchir.
Une base NoSQL ne vous oblige pas à formaliser votre schéma, mais ça ne veut CERTAINEMENT PAS dire qu’il ne faut pas le faire. L’auteur de Redis a très bien expliqué le problème (je graisse pour donner une effet dramatique et puissant au message) :
Redis is not the kind of system where you can insert data and then argue about how to fetch those data in creative ways. Not at all, the whole idea of its data model, and part of the fact that it will be so fast to retrieve your data, is that you need to think in terms of organising your data for fetching. You need to design with the query patterns in mind.
C’est vrai pour tout système dans lequel on met ses données, SQL, NoSQL, fichier, mémoire, le tiroir de votre bureau…
Il faut penser au type des données, leurs formats, les relations entre les éléments, comment et à quelle fréquence vous allez les écrire, les lire, garantir la consistence de leurs relations et leur fraicheur (ou pas d’ailleurs, mais il faut en faire le choix). Les bases SQL sont contraignantes parce qu’elles vous obligent à penser, dès le début, en ces termes.
C’est vrai, vous êtes de grandes personnes, a priori vous savez ce que vous faites, vous n’avez pas besoin qu’on vous FORCE à le faire. C’est pour ça que j’aime le typage dynamique. Je ne veux pas que tu me demandes mes papiers pour déclarer une variable, je sais ce que je fais.
Seulement il faut le faire, et ce n’est souvent pas fait. Pire, le modèle n’est généralement jamais formalisé NULLE PART. Un schéma, c’est une doc. Sans doc, le coût d’entrée dans votre projet est élevé, sa maintenance est galère, le potentiel de bug lors de l’évolution est plus grand. Mais une doc c’est chiant à écrire et à tenir à jour.
C’est un des intéressants effets secondaires des ORMs : les classes de définition sont le modèle documenté dans sa structure, ses relations, ses limites, ses contraintes, ses tests et vérifications, etc. La doc par le code, j’adore.
Anti-fact 3 : NoSql, c’est plus performant
A chaque fois qu’on lit “x est plus performant que z”, il faut faire une pause et réfléchir deux minutes. Généralement il y a un piège.
Les performances, ça dépend toujours du contexte. Par exemple, Redis est plus performant à la lecture et l’écriture, mais les données doivent tenir en RAM, sinon ça bouffe sur la mémoire virtuelle. Autre chose, Redis est très lent à démarrer sur des gros jeux de données (ça peut aller à plusieurs minutes si vous avez des Go). MongoDB doit normalement pouvoir tenir une augmentation de charge de manière prédictive en rajoutant des noeuds. Mais sur un seul noeud, c’est toujours moins performant qu’un PostGres. Et 0.01 % des sites ont besoin de plus d’un serveur.
Par ailleurs, les performances sont très dépendantes de l’anti-fact 2. Il faut créer les bons index, avoir un cache correctement ajusté, faire des requêtes intelligentes. Pour tous les systèmes.
Bref, encore une fois, NoSQL n’est pas une techno magique. Il est contre-productif, et j’ai envie de dire même irrespectueux envers ses collègues, de la vendre comme telle.
Anti-fact 4 : NoSQL remplace le SQL
Tweeter tourne sur MySQL ET Memcache.
Stackoverflow utiliser SQL Server 2008 ET Redis.
Il y a carrément des sites qui utilisent PostGres et MongoDb en parallèle. En fait, il y a des outils pour les faire collaborer.
Nous sur notre plus gros site on utilise Redis pour les sessions, les compteurs, les crawlers, les queues et passer des données entre process. Pas juste pour le cache. On utilise PostGres pour les données complexes avec des queries lourdes. Et on utilise Solr pour le moteur de recherche.
Les bases NoSQL sont des nouveaux outils, qui sont mieux adaptés à CERTAINS usages ou à CERTAINS contextes. Pas tout, tout le temps, partout. C’est un outil en plus, pas un obligatoire remplaçant.
Par ailleurs, on peut utiliser PostGres comme une base de données clé-valeur ou JSON, on peut mettre SQLite complètement en mémoire vive, on peut utiliser MySQL comme un moteur de recherche de texte… Multiplier les points of failures dans une archi n’est pas toujours une bonne idée. Ces outils qu’on considère comme de l’histoire ancienne ont beaucoup plus de ressource que vous ne l’imaginez. Ils sont ultra performants. Des années et des années d’optimisation.
Le monde de la tech n’est jamais lisse. Jamais.
Je connaissais l’expression “Quand on n’a qu’un marteau pour outil, tous les problèmes ressemblent à des clous”, mais j’aime bien ta version aussi. :)
Sinon je suis une buse en BDD, je saurais pas choisir l’une par rapport à l’autre en fonction des besoins. Une référence pour comparer où il faut éplucher la doc de chaque ?
Il faut surtout les utiliser toutes pour voir les bons côtés et les inconvénients malheureusement, surtout que ça évolue d’un contexte à l’autre.
@Vivien: j’avoue mon biais en faveur de Postgres, mais voilà ma vision des choses :
– Oracle est la Lamborghini des BDD.
– MySQL est une R4.
– PostgreSQL est un moteur de Lamborghini avec une carosserie de R4.
– Et NoSQL, c’est juste un dessin de n’importe quel voiture de ton choix : y’a plus qu’à concevoir, construire et assembler chaque pièce en partant de zéro.
L’informatique est un éternel recommencement.
En gestion de données, on a passé 30 ans à normaliser, puis on nous a loué la dénormalisation avec le NoSQL, puis maintenat on réinvente des schémas pour le NOSQL, donc on va finir par renormaliser ;)
En réseau, on a passé 30 ans à décentraliser vers le client / serveur, puis on nous a loué la centralisation avec la virtualisation, puis maintenant on réinvente la virtualisation décentralisée avec le cloud.
En développement, on a passé 30 ans à migrer du fonctionnel vers de l’objet, maintenant on nous loue la programmation fonctionnelle (go routine, co routine, programmation asynchrone par événement).
Bref, nous les informaticiens, on aime bien perdre du temps et se toucher le zizi et cela montre que finalement, les problèmes ne sont pas résolus.
Il y a quasiment autant de sql différents que de bases sur le marché, utiliser l’argument du langage commun entre bases revient à ignorer la réalité, sans compter les procédures stockées…
@openhoat D’un côté, il s’agit plus de dialectes différents, que d’API complètement différentes et de fonctionnalités qui n’ont rien à voir entre elles. Mais je suis d’accord sur les procédures stockées.
Bon résumé sur les “pièges” du NoSQL, je rajouterai qu’il ne faut pas oublier qu’une des définitions du NoSQL signifie “Not only SQL”, chez nous on utilise plusieurs BDD NoSQL et c’est pas pour autant qu’on utilise pas encore un bon vieux SDGBDR tels que MySQL. Le NoSQL n’est donc pas la réponse absolu à tout nos problèmes. J’invite les gens à lire cette article sur la Polyglot Persistence: https://www.altamiracorp.com/blog/employee-posts/polyglot-persistence
Il n’existe pas à l’heure actuelle de base NoSQL embarquée.
Sérieusement ? Berkley DB, LMDB, Tokyo et Kyoto Cabinet, LevelDB / RockDB ?
J’adore parce que j’ai un chef débile qui ne jure que par le NoSQL (bien entendu c’est pas pour ça qu’il est débile, il y a bien d’autres raisons mais celle-ci fait partie du lot).
Et donc je me suis empressé de faire passer cette pertinente réflexion à toute l’équipe afin que (ce qui finira bien par arriver) ça lui parvienne…
Je voudrais rajouter une citation de Herbert Mayer: Aucun langage de programmation n’est parfait. Il n’existe même pas un langage meilleur que d’autres ; il n’y a que des langages en adéquation ou peu conseillés pour des buts particuliers.
Cette citation peut tout à fait être étendue aux technologies telles que NoSQL (ou que Postgres si on ne veut pas paraître partial)…
Dans la majorité des cas, ne pas avoir une bdd ACID dont la propriété ACID peux s’appliquer sur des opérations affectant plusieurs documents (un document dans un RDBMS c’est une ligne, dans une base de donnée clef/valeur c’est une association clef/valeur), c’est se tirer une balle dans le pied. Autrement dit si vous ne pouvez pas garantir la coherence des données, je sais pas où vous allez (et la persistence, etc…). Il y a des cas où ACID cross-document n’est pas utiles. Garantir la cohérence des données sans ACID ou implementer ACID dans une base non ACID ou entre base c’est pas trivial.
«Premature optimization is the root of all evil.»
A chaque fois que j’ai entendu parler de problème d’ACID dans postgresql, c’est des gens qui voulez faire des optim. Et je n’ai jamais entendu parler de gens qui faisait du NoSQL pour autre chose que les perfs (sauf ZODB). Un autre argument souvent avancé c’est dev-friendly car schemaless genre MongoDB. NB: la db est schemaless, vos données ont un schema, c’est obligé sinon vous pouvez rien faire dessus. Mise à part les données issues du projet SETI, je connais pas de données sans schema. Usuellement quand on dit schemaless ça veux dire qu’on peux changer la nature ou le nombre de sous-propriétés d’un document sans avoir à alterer les propriétés du super-ensemble. Typiquement dans un RDBMS ça voudrais dire qu’il y a pas besoin de faire d’ALTER sur une table, pour changer le type d’une colonne pour une ligne ou ajouter une colonne à une ligne. Genre dans mongodb le super-ensemble c’est la collection et elle à aucune propriété mise à part un nom. Les documents contenu dans la collection ne sont pas contraint par un schema, et le schema *de chaque document* n’est connu par la base qu’au runtime.
Pour moi, pensé en production NoSQL quand on peux avoir des perf convenable avec un RDBMS c’est pas un débat. Exemple: suggestion par rapprochement phonetique de mot. Peut être qu’il existe un plugins postgresql pour le faire je sais pas.
graphdb4ever & graphdb4all.
Ah enfin un article sur les BDD! Un thème à développer sur le blog!
@openhoat : bien sur que si SQL est le même partout, il est normalisé. Ce qui est différent ce sont les langages procéduraux créés par les différents SGBDR:
– PL/SQL pour Oracle;
– Transact sql pour sqlserver;
– pl/pgsql pour postgre…
– …
Et c’est justement là où beaucoup de gens font l’erreur car il ne profitent pas de la puissance de sql qui lui permet de traiter l’information de façon ensembliste.
Le choix du SGBD se fait en fonction des besoins du client et sur le marché ce sont Oracle et SqlServer les leaders.
Pour un projet perso/libre, Postgre.
@Giggs c’est faux. Order by n’est pas interprété de manière uniforme, les jointures non plus, offset non plus, oracle a des spécificités concernant insert, le type boolean n’est pas uniformement supporté, etc etc…
Regarde les normes sql, puis les sgbdr du marché, il y a de quoi s’arracher les cheveux.
J’ai galéré quelques années en codant un orm avec l’ambition de supporter les solutions les plus connues du marché.
Pas d’avis tranché sur ce mouvement Nosql, je constate juste que je suis satisfait de ce que je peux faire avec mongodb par exemple.
Ces nouvelles approches permettent de repositionner la fonction primaire qu’on attend d’une solution de persistance, en mettant la priorité sur ce qu’on fait des data plutôt que savoir comment elles sont structurées, ce qui je pense va dans le sens de l’histoire.
Ce que je voulais dire c’est que la base est censé être la même. Et elle est normalisée(sur plusieurs versions certes..)
Après on est tout à fait d’accord que ça n’est pas implémenté de la même façon chez tout le monde il n’y a qu’à voir le group by de Mysql…
Mais une bonne connaissance de sql est “transposable”.
Tout le sucre ajouté à gauche à droite c’est ça qui créer beaucoup de différences.
Et souvent le choix du sgbd se fait aussi avec l’écosystem offert par ailleurs (solutions middleware,haute dispo, clustering, sauvegarde… )
@Fred : j’espère que ton chef débile ne lit pas les commentaires :)
Pour ce qui est des différences entre SGBDR dans l’implémentation du SQL, ça vient aussi dans le fait qu’à l’époque où les “gros” du marché se sont posés autour d’une table pour définir la norme SQL, chacun y est allé de ses spécificités, et par un “UNION” ont sorti celles qu’ils avaient en commun/proche. Les autres moteurs créés ultérieurement ont repris cette norme, mais en y ajoutant leurs propres conceptions/visions, ce qui fait aussi la richesse de l’écosystème. Après la norme définit les commandes, par l’implémentation de ces commandes.
Pour en revenir au NoSQL que je n’ai pas encore touché mais qui m’intrigue, j’aurai voulu savoir laquelle était la plus proche disons du couple PostgreSQL/PostGIS pour les traitements géospatiaux?
@Pierre Chapuis : aucune d’entre elles ne sont accessibles sans compiler et accessible depuis plein de langages comme sqlite. Et aucunes n’ont la maturité. C’est comme dire “bien sur qu’il y a des voiture à 3 roues”. Il y a quelques modèles, ce n’est juste pas comparable.
@joshuafr mongodb. Dans le doute, si on veut un truc hyper rapide, prendre redis. Si on veut stocker des schémas complexes, prendre mongo. Pas qu’ils soient parfait, mais ça permet de se faire une idée, et parti de là, de comparer les autres produits quand on rencontre leurs limites.
@openhoat : les procédures stockées sont un problème en NoSQL aussi. Disons que l’existence des ORMs permettent de migrer beaucoup plus facilement une bdd SQL à l’autre que l’on ne peut le faire d’un NoSQL à l’autre pour le moment, car la similitude du SQL à permet de créer facilement un outil fédérateur. C’est beaucoup plus dur avec NoSQL car parfois, les philosophies des APIs sont complètement différentes.
Il faut dire qu’il est un peu injuste de comparer du NoSQL avec des SGBD, car certains sont des systèmes qui n’ont rien à voir finalement. Une base de données clé/valeur n’a pas grand chose en commun avec une base de données orientée document.
@Clem : il les lira sûrement mais que pourra-t-il faire ???
Au pire il fera semblant de ne pas savoir que c’est moi qui l’ai écrit et que c’est à lui que ça s’adresse… ;)
Again and again: the right tool for the right job.
Tu lances juste une pique sur les graph db, tu en penses quoi en vrai ?
Perso j’ai des vues sur neo4j depuis un moment et je cherche encore un bon petit projet pour jouer avec, même si je sais que je le pousserai pas dans ses retranchements et qu’il n’y aura aucun bénéfice par rapport à du sqlite (Et puis surtout la dépendance Java me pète les couilles).
Merci pour cet article de spécialiste.
Mais le non informaticien que je suis, aurait préféré un article qui explique ligne par ligne, mot par mot ce qu’est le NoSQL, la différence avec un SGBD “classique” ou avec un stockage “structuré” de la donnée, des exemples simples (mais non simplistes)…
Sans une explication claire (Si vous ne pouvez expliquer un concept à un enfant de six ans, c’est que vous ne le comprenez pas complètement. – Albert Einstein) beaucoup d’erreurs de compréhension risquent d’avoir la vie longue.
Oui en fait c’est un outil, il faut apprendre à l’utiliser à bon escient.
Très bon résumé, merci :)
@Olivier : je comprends mais ce n’est pas le but de l’article. Je vise ici les spécialistes, et mélanger les deux ne satisferait aucun publique. Donc je fais soit l’un, soit l’autre.
Pour expliquer à un enfant de 6 ans je me servirai d’un frigo et d’une boite d’œufs.
Les œufs sont les données, tu peux les ranger dans la porte du frigo dans le petit support à œufs fait pour ça (même si mettre des œufs dans la portière est une mauvaise idée), ce serait un SGBD “classique”, c’est fait pour, c’est là que “doivent aller les œufs”.
Le NOSQL ce serait de le mettre n’importe où ailleurs dans le frigo, avec ou sans la boite qui a servi a les transporter. L’emplacement et la disposition (avec/sans boite) permettent de les trouver plus ou moins vite.
Le fait qu’ils soient dans la boite permet de tous les attraper plus vite ou de faciliter leur identification (genre on cherche le plus vieux pour le consommer en premier, c’est plus rapide si on vois les dates tout de suite) ou a optimiser la place restante dans le frigo.
Tout ça pour dire que la distinction SQL / NOSQL est plutôt SQL / NOSQLs.
Et aussi, que c’est important d’avoir un frigo bien rangé.
@Olivier: Je viens de lire ça : http://www.drgoulu.com/2008/11/26/ce-queinstein-na-jamais-dit/
Einstein à beau dos…
C’est excellent pour le travail solo. C’est une chose bien plus néfaste pour travailler en équipe. Et si je commence à parler “travail avec des débutants”, c’est tout simplement la chose la pire possible, parce qu’il peuvent faire n’importe quoi et devine quoi ? La maintenabilité d’un système en prend une gifle. Et on en arrive à des aberrations où le chef de projet essaie en balbutiant d’expliquer pourquoi le déplacement de 4 objets sur deux pages Web prend une semaine – c’est du vécu.
J’oubliais :
MariaDB dernière version implémente en son coeur la possiblité de renvoyer des requêtes directement au format JSON. Si si. Ici.
Le standard WAMP introduit ça un peut partout maintenant. Checkez crossbar.io, c’est super intéressant.
http://www.phoronix.com/scan.php?page=news_item&px=MTY0MTU
Oui, je lis Phoronix, j’assume.
Mais là, ça dit que postgresql va supporter le jsonb (JSON binaire, sans interprétation), et que c’est vachement plus rapide.
NoSQL RUL35 !
OUI
Du SQL et du NoSQL là où on sent que les bases SQL vont peiner. J’ai pas mal travaillé sur des séries-temporelles et cassandra m’a beaucoup simplifié la tâche.
Cela veut dire qu’il faut aller dans les détails techniques de chaque base qui semble adaptée et faire plein de tests (grande quantités de données, fort traffic, nettoyage de données, récupération après maltraitance, création et restauration des backups, etc.).
Complément: Dans les bases embarquées nous avons aussi: couchbase mobile. Je ne l’ai jamais testé mais sur le papier l’offre a l’air intéressante.
Le premier projet web “sérieux” que j’ai développé a été fait en mongodb. Je considère pour ma part que son développement et son déploiement a été considérablement amélioré par l’utilisation de cette base de donné, et outre le plaisir que j’ai pris à coder avec ça, je n’arrive pas à voir l’avantage d’utiliser une base de donnée sql au jour d’aujourd’hui quand on a la possibilité de construire son application avec un outil comme mongodb.
Très bel article, il faut mettre en garde les plus jeunes développeurs pour qu’ils ne tombent pas dans l’amalgame lors du choix du moteur de persistance des données.
Je reviendrais juste sur un point de l’anti-fact 1, qui est que SQLite serait la plus performante (rapide, efficace ?) ; si on parle de rapidité et d’efficacité il faut regarder le projet LMDB on peut très vite changer d’avis. Si on entend aussi la productivité, je te rejoins parfaitement.
Pareil pour moi, MongoDb c’est du plaisir tout simplement !
Merci!
J’ai adoré cet article qui remet les choses à leurs places.
Je ne suis pas contre l’évolution du dev, bien au contraire ça me passionne. Mais que ça soit utilisé à bon escient !!
Il suffit qu’une nouvelle techno soit adoptée par un ou 2 hipster de dev pour que tout le monde souhaite l’utiliser partout et que ces mêmes personnes évangélisent le reste de la planète avec celle-ci…
En date, Grunt et Gulp (même si le dernier à ma préférence). Ces 2 technos sont même demandée comme étant capitale dans un c.v.
Utilisateurs de ces technos, vous n’êtes pas sans savoir que celles-ci utilise nodejs et que nodejs en natif sait faire exactement les mêmes choses. Alors pourquoi remplacer un truc natif par des surcouches, hein ??!!
http://blog.keithcirkel.co.uk/how-to-use-npm-as-a-build-tool/
Non, non et non !
Nico :)
Ta prose fait du bien à mes yeux : )
Bonjour,
Je recherche une personne qui fait du code REDIS, pour la création d’un site.
Je n’y connais Rien en informatique, pouvez vous svp me donner les coordonnées d’une personne?
Mon mail: <retiré>
Je vous remercie beaucoup.
Bonjour Godel : annoncer qu’on y connait rien et mettre son email en ligne est le plus sûr moyen de faire se faire arnarque. Je vais donc masquer ton email et laisser je t’invite à aller plutôt sur un site spécialisé dans le recrutement freelance ou à l’université d’informatique la plus proche.
Merci Sam pour ce billet. Même s’il date un peu je check !
J’ai un cas concret pour toi : je veux mettre en place un moteur de commissionnement sans passer par des progiciels SAP/Oracle/IBM coûteux et contraignants.
En entrée des actes de natures diverses (de formats différents et évolutifs), en sortie des commissions pour chaque acte (pour faire simple), au milieu un moteur de calcul qui analyse les actes au fil de l’eau ou en masse, selon leur nature et cré les commissions. Les règles de calculs sont du style “si acte Vente, si des patates, si par paquet de 10-10-1000 alors comm de 1-10-100 euros”. Côté volume c’est qq millions d’actes par mois.
Que me proposerais-tu ?
Merci SAM ;)
Rien de particulier, les règles sont très simples, n’importe quel langage peut le faire en back. Pour les requêtes, à 5 millions d’actes pour 30 jours à raison de 8 h par jours, ça fait 5 par seconde ce que n’importe quelle base de données supporte les doigts dans le nez.
Pour faire sérieux, tu peux partir sur un site django avec du postgres comme ça si le nombre de requêtes augmente tu es calé. En prime tu as un système de transaction robuste. Mais honnêtement, je suis presque sûr que flask + sqlite pourrait tenir la charge.
Si un jour du commence à avoir beaucoup de charge, ou alors que tu t’aperçois que tu as des heures de pointe, tu peux rajouter des files d’attente. Mais pour le moment, c’est tranquille.
Une API REST, et zou. Ou si tu as envie de t’amuser avec le temps réel, tu pars sur crossbar, c’est un bon candidat et autant s’amuser.
Salut
J adore cet article…
Pour ma part je ferai simple, je pense que ce lancer dans du nosql lorsque l on sait que le modele doit etre relationnel avec des contraintes d integrite c est ce tirer une balle dans le pied.
Apres un dev de 2 mois, avec des technos imposé tel que loopback et mongodb et un code en js imbuvable au quotidien j en revien a l histoire du marteau pour dire que j ai du enfoncer des clous avec une cuillère a café.
Bon c est quand même cool je met ce que je veux quand je veux dans mes collections mongo, j imagine dejas le bordel la dedans dans 6 mois :D
Il n y a pas de solutions COOL, mais une solution pour chaque cas.
Postgres tu me manques, Django dis a mon chef que t es le meilleur, nodejs explique lui que l asynchrone c est bien mais pas pour tout et que c est pas parceque l on fait autre choses que du js que c est compliqué.
A plus ;)