Node.js + Nuxt.js + MongoDB > ALL

Le 08 mai 2022 à 10:35:58 :

Le 08 mai 2022 à 10:31:00 :

Le 08 mai 2022 à 10:30:06 :
"beaucoup plus flexible que SQL" t'es clairement not ready pour le moment où t'auras des soucis de schemas ou que tu devras faire de grosses requêtes relationnelleshttps://image.noelshack.com/fichiers/2021/43/4/1635454847-elton-john-tison-golem.png

Vazi, donne un exemple, il y a toujours des solutions
En attendant, les pirouettes c'est quasiment systématique avec MySQL

Un exemple: Tu as ton model utilisateur avec (mail, name), un jour tu veux rajouter un nouveau champ "address". En SQL, t'as la valeur par défaut qui s'ajoute (une string vide sûrement), en Mongo, tu dois set à la main les valeurs par défaut, ou gérer tes documents "legacy" qui auront un schema différent (source: https://www.mongodb.com/community/forums/t/setting-default-values-in-data-schema/8411 pas de default values).
Plus ton programme devient complexe, plus ça devient la merde. Tes anciens champs legacy seront une plaie à gérer, et tu vas devoir soit faire des vieux script de migration (alors que tout existe déjà en SQL), ou gérer les documents legacy.

Ensuite, y'a les requêtes relationnelles qui sont une plaie, et plus lentes qu'en SQL classique. Enfin bref en fait j'ai la flemme d'argumenter mais tu te rendras bien compte à un moment que la "flexibilité" est un cadeau empoisonné si tu sais pas pourquoi t'as pick cette SGBD

Facebook et d'innombrables grands sites, voir une majorité, utilisent du NoSQL et ils se portent très bien

La valeur par défaut c'est complètement bidon ce que tu me racontes, soit tu fais un script (si ton SGBD ne le prend pas en charge) pour simplement remplir les valeurs (un peu comme UPDATE en SQL), soit quand ça ne retourne rien à cet endroit dans la DB tu le retournes comme vide dans ton programme, tout simplement

T'as aussi la possibilité de faire en sorte que ça se mette à jour progressivement, à la prochaine connexion de l'utilisateur par exemple, mais en réalité ce n'est même pas nécessaire

Comme d'habitude tu t'inventes des faux problèmes éco+, c'est beaucoup plus emmerdant au quotidien la non-flexibilité de MySQL que ce soi-disant problème

MongoDB
Un client avait choisi mongodb mais a vite compris ses limitations donc ils sont passés à Postgresql

je peux faire des sites SPA (alors qu'avec PHP pour en faire c'est la merde)

aucun rapport, tu peux très bien avoir une api en phphttps://image.noelshack.com/fichiers/2017/13/1490886827-risibo.png

Le 08 mai 2022 à 10:41:07 :
MongoDB
Un client avait choisi mongodb mais a vite compris ses limitations donc ils sont passés à Postgresql

Vazi, raconte-moi les limitations
Postgresql c'est le moyen-âge

Le 08 mai 2022 à 10:41:50 :

je peux faire des sites SPA (alors qu'avec PHP pour en faire c'est la merde)

aucun rapport, tu peux très bien avoir une api en phphttps://image.noelshack.com/fichiers/2017/13/1490886827-risibo.png

Oui oui el famoso en PHP tout est plus merdique ce côté, avec nuxt.js ça prend deux secondes

Le 08 mai 2022 à 10:38:28 :

Le 08 mai 2022 à 10:35:58 :

Le 08 mai 2022 à 10:31:00 :

Le 08 mai 2022 à 10:30:06 :
"beaucoup plus flexible que SQL" t'es clairement not ready pour le moment où t'auras des soucis de schemas ou que tu devras faire de grosses requêtes relationnelleshttps://image.noelshack.com/fichiers/2021/43/4/1635454847-elton-john-tison-golem.png

Vazi, donne un exemple, il y a toujours des solutions
En attendant, les pirouettes c'est quasiment systématique avec MySQL

Un exemple: Tu as ton model utilisateur avec (mail, name), un jour tu veux rajouter un nouveau champ "address". En SQL, t'as la valeur par défaut qui s'ajoute (une string vide sûrement), en Mongo, tu dois set à la main les valeurs par défaut, ou gérer tes documents "legacy" qui auront un schema différent (source: https://www.mongodb.com/community/forums/t/setting-default-values-in-data-schema/8411 pas de default values).
Plus ton programme devient complexe, plus ça devient la merde. Tes anciens champs legacy seront une plaie à gérer, et tu vas devoir soit faire des vieux script de migration (alors que tout existe déjà en SQL), ou gérer les documents legacy.

Ensuite, y'a les requêtes relationnelles qui sont une plaie, et plus lentes qu'en SQL classique. Enfin bref en fait j'ai la flemme d'argumenter mais tu te rendras bien compte à un moment que la "flexibilité" est un cadeau empoisonné si tu sais pas pourquoi t'as pick cette SGBD

Facebook et d'innombrables grands sites, voir une majorité, utilisent du NoSQL et ils se portent très bien

La valeur par défaut c'est complètement bidon ce que tu me racontes, soit tu fais un script (si ton SGBD ne le prend pas en charge) pour simplement remplir les valeurs (un peu comme UPDATE en SQL), soit quand ça ne retourne rien à cet endroit dans la DB tu le retournes comme vide dans ton programme, tout simplement

T'as aussi la possibilité de faire en sorte que ça se mette à jour progressivement, à la prochaine connexion de l'utilisateur par exemple, mais en réalité ce n'est même pas nécessaire

Donc en gros ta solution à la gestion des champs legacy c'est:
- coder les exceptions pour quand les champs n'existaient pas avant
- coder les exceptions pour quand les champs ont été rename
- coder manuellement des outils de migration de schema pour recrééer ce qui est natif à la plupart des SGBD SQL
- coder manuellement les différents états de la data de l'utilisateur

Woaw trop bien la flexibilité

Le 08 mai 2022 à 10:38:28 :

Le 08 mai 2022 à 10:35:58 :

Le 08 mai 2022 à 10:31:00 :

Le 08 mai 2022 à 10:30:06 :
"beaucoup plus flexible que SQL" t'es clairement not ready pour le moment où t'auras des soucis de schemas ou que tu devras faire de grosses requêtes relationnelleshttps://image.noelshack.com/fichiers/2021/43/4/1635454847-elton-john-tison-golem.png

Vazi, donne un exemple, il y a toujours des solutions
En attendant, les pirouettes c'est quasiment systématique avec MySQL

Un exemple: Tu as ton model utilisateur avec (mail, name), un jour tu veux rajouter un nouveau champ "address". En SQL, t'as la valeur par défaut qui s'ajoute (une string vide sûrement), en Mongo, tu dois set à la main les valeurs par défaut, ou gérer tes documents "legacy" qui auront un schema différent (source: https://www.mongodb.com/community/forums/t/setting-default-values-in-data-schema/8411 pas de default values).
Plus ton programme devient complexe, plus ça devient la merde. Tes anciens champs legacy seront une plaie à gérer, et tu vas devoir soit faire des vieux script de migration (alors que tout existe déjà en SQL), ou gérer les documents legacy.

Ensuite, y'a les requêtes relationnelles qui sont une plaie, et plus lentes qu'en SQL classique. Enfin bref en fait j'ai la flemme d'argumenter mais tu te rendras bien compte à un moment que la "flexibilité" est un cadeau empoisonné si tu sais pas pourquoi t'as pick cette SGBD

Facebook et d'innombrables grands sites, voir une majorité, utilisent du NoSQL et ils se portent très bien

La valeur par défaut c'est complètement bidon ce que tu me racontes, soit tu fais un script (si ton SGBD ne le prend pas en charge) pour simplement remplir les valeurs (un peu comme UPDATE en SQL), soit quand ça ne retourne rien à cet endroit dans la DB tu le retournes comme vide dans ton programme, tout simplement

T'as aussi la possibilité de faire en sorte que ça se mette à jour progressivement, à la prochaine connexion de l'utilisateur par exemple, mais en réalité ce n'est même pas nécessaire

Facebook utilise Mysql comme base de données principale. Aprés ils ont du NoSQL par dessus.
Les deux ont leurs avantage et incovénients et pas mal de gros sites utilisent les deux maintenant.

Le 08 mai 2022 à 10:38:28 :

Le 08 mai 2022 à 10:35:58 :

Le 08 mai 2022 à 10:31:00 :

Le 08 mai 2022 à 10:30:06 :
"beaucoup plus flexible que SQL" t'es clairement not ready pour le moment où t'auras des soucis de schemas ou que tu devras faire de grosses requêtes relationnelleshttps://image.noelshack.com/fichiers/2021/43/4/1635454847-elton-john-tison-golem.png

Vazi, donne un exemple, il y a toujours des solutions
En attendant, les pirouettes c'est quasiment systématique avec MySQL

Un exemple: Tu as ton model utilisateur avec (mail, name), un jour tu veux rajouter un nouveau champ "address". En SQL, t'as la valeur par défaut qui s'ajoute (une string vide sûrement), en Mongo, tu dois set à la main les valeurs par défaut, ou gérer tes documents "legacy" qui auront un schema différent (source: https://www.mongodb.com/community/forums/t/setting-default-values-in-data-schema/8411 pas de default values).
Plus ton programme devient complexe, plus ça devient la merde. Tes anciens champs legacy seront une plaie à gérer, et tu vas devoir soit faire des vieux script de migration (alors que tout existe déjà en SQL), ou gérer les documents legacy.

Ensuite, y'a les requêtes relationnelles qui sont une plaie, et plus lentes qu'en SQL classique. Enfin bref en fait j'ai la flemme d'argumenter mais tu te rendras bien compte à un moment que la "flexibilité" est un cadeau empoisonné si tu sais pas pourquoi t'as pick cette SGBD

Facebook et d'innombrables grands sites, voir une majorité, utilisent du NoSQL et ils se portent très bien

La valeur par défaut c'est complètement bidon ce que tu me racontes, soit tu fais un script (si ton SGBD ne le prend pas en charge) pour simplement remplir les valeurs (un peu comme UPDATE en SQL), soit quand ça ne retourne rien à cet endroit dans la DB tu le retournes comme vide dans ton programme, tout simplement

T'as aussi la possibilité de faire en sorte que ça se mette à jour progressivement, à la prochaine connexion de l'utilisateur par exemple, mais en réalité ce n'est même pas nécessaire

Comme d'habitude tu t'inventes des faux problèmes éco+, c'est beaucoup plus emmerdant au quotidien la non-flexibilité de MySQL que ce soi-disant problème

De toute évidence, tu n'as jamais travaillé dans la moindre entreprise.

Tu fais pas des applis, tu fais des trucs de merde. Je te le dis, c'est un fait.

Aucun besoin de rajouter quoi que ce soit.

Il y a uniquement un débile mental ou un programmeur du dimanche pour penser que NoSQL est un remplaçant du SQL.

Le 08 mai 2022 à 10:41:52 :

Le 08 mai 2022 à 10:41:07 :
MongoDB
Un client avait choisi mongodb mais a vite compris ses limitations donc ils sont passés à Postgresql

Vazi, raconte-moi les limitations
Postgresql c'est le moyen-âge

Le moyen-âge Postgresql ? Ben voyons.

Edit : typo.

pourquoi tous les topics d'antoineforum constistent mécaniquement à créer l'illusion qu'il est intelligent ?

[10:41:52] <AntoineForum144>

Le 08 mai 2022 à 10:41:07 :
MongoDB
Un client avait choisi mongodb mais a vite compris ses limitations donc ils sont passés à Postgresql

Vazi, raconte-moi les limitations
Postgresql c'est le moyen-âge

Peut mieux faire dans le troll, mais jusque là ça à bien feed

Le 08 mai 2022 à 10:41:52 :

Le 08 mai 2022 à 10:41:07 :
MongoDB
Un client avait choisi mongodb mais a vite compris ses limitations donc ils sont passés à Postgresql

Vazi, raconte-moi les limitations
Postgresql c'est le moyen-âge

Pathétique de raconter autant de la merde.

Le 08 mai 2022 à 10:42:32 :

Le 08 mai 2022 à 10:38:28 :

Le 08 mai 2022 à 10:35:58 :

Le 08 mai 2022 à 10:31:00 :

Le 08 mai 2022 à 10:30:06 :
"beaucoup plus flexible que SQL" t'es clairement not ready pour le moment où t'auras des soucis de schemas ou que tu devras faire de grosses requêtes relationnelleshttps://image.noelshack.com/fichiers/2021/43/4/1635454847-elton-john-tison-golem.png

Vazi, donne un exemple, il y a toujours des solutions
En attendant, les pirouettes c'est quasiment systématique avec MySQL

Un exemple: Tu as ton model utilisateur avec (mail, name), un jour tu veux rajouter un nouveau champ "address". En SQL, t'as la valeur par défaut qui s'ajoute (une string vide sûrement), en Mongo, tu dois set à la main les valeurs par défaut, ou gérer tes documents "legacy" qui auront un schema différent (source: https://www.mongodb.com/community/forums/t/setting-default-values-in-data-schema/8411 pas de default values).
Plus ton programme devient complexe, plus ça devient la merde. Tes anciens champs legacy seront une plaie à gérer, et tu vas devoir soit faire des vieux script de migration (alors que tout existe déjà en SQL), ou gérer les documents legacy.

Ensuite, y'a les requêtes relationnelles qui sont une plaie, et plus lentes qu'en SQL classique. Enfin bref en fait j'ai la flemme d'argumenter mais tu te rendras bien compte à un moment que la "flexibilité" est un cadeau empoisonné si tu sais pas pourquoi t'as pick cette SGBD

Facebook et d'innombrables grands sites, voir une majorité, utilisent du NoSQL et ils se portent très bien

La valeur par défaut c'est complètement bidon ce que tu me racontes, soit tu fais un script (si ton SGBD ne le prend pas en charge) pour simplement remplir les valeurs (un peu comme UPDATE en SQL), soit quand ça ne retourne rien à cet endroit dans la DB tu le retournes comme vide dans ton programme, tout simplement

T'as aussi la possibilité de faire en sorte que ça se mette à jour progressivement, à la prochaine connexion de l'utilisateur par exemple, mais en réalité ce n'est même pas nécessaire

Donc en gros ta solution à la gestion des champs legacy c'est:
- coder les exceptions pour quand les champs n'existaient pas avant
- coder les exceptions pour quand les champs ont été rename
- coder manuellement des outils de migration de schema pour recrééer ce qui est natif à la plupart des SGBD SQL
- coder manuellement les différents états de la data de l'utilisateur

Woaw trop bien la flexibilité

Si le champ n'existe pas c'est qu'il n'y a rien, donc il est vide ou avec une valeur par défaut, qu'est-ce que tu ne comprends pas ?

Le 08 mai 2022 à 10:42:27 :

Le 08 mai 2022 à 10:41:50 :

je peux faire des sites SPA (alors qu'avec PHP pour en faire c'est la merde)

aucun rapport, tu peux très bien avoir une api en phphttps://image.noelshack.com/fichiers/2017/13/1490886827-risibo.png

Oui oui el famoso en PHP tout est plus merdique ce côté, avec nuxt.js ça prend deux secondes

PHP éclate tout ce qui est JS en terme de performances, faut le savoirhttps://image.noelshack.com/fichiers/2017/13/1490886827-risibo.png

le backend en JS c'est juste une mode, adulée par les pyjs qui veulent se sentir différents en criant sur tout les toits "agneugneu php dead langage"https://image.noelshack.com/fichiers/2017/13/1490886827-risibo.png

c'est pourquoi il y a un milliard de frameworks JShttps://image.noelshack.com/fichiers/2017/13/1490886827-risibo.png

Le 08 mai 2022 à 10:41:52 :

Le 08 mai 2022 à 10:41:07 :
MongoDB
Un client avait choisi mongodb mais a vite compris ses limitations donc ils sont passés à Postgresql

Vazi, raconte-moi les limitations
Postgresql c'est le moyen-âge

Aucune idée je suis pas dev back mais ça parlait surtout de relationnel

Antoine forum le grand génie du dev qui fait du PHP sans framework

Le 08 mai 2022 à 10:45:29 :
Antoine forum le grand génie du dev qui fait du PHP sans framework

J'ai toujours fait comme ça, peut-être qu'à l'époque où j'ai commencé c'était moins répandu
J'avais déjà mes propres fichiers pour la DB, certaines fonctions pour gérer les utilisateurs etc. et quand j'avais besoin de nouveaux trucs je codais de nouvelles fonctions que je pouvais réutiliser ensuite

Le 08 mai 2022 à 10:43:51 :

Le 08 mai 2022 à 10:42:32 :

Le 08 mai 2022 à 10:38:28 :

Le 08 mai 2022 à 10:35:58 :

Le 08 mai 2022 à 10:31:00 :

Le 08 mai 2022 à 10:30:06 :
"beaucoup plus flexible que SQL" t'es clairement not ready pour le moment où t'auras des soucis de schemas ou que tu devras faire de grosses requêtes relationnelleshttps://image.noelshack.com/fichiers/2021/43/4/1635454847-elton-john-tison-golem.png

Vazi, donne un exemple, il y a toujours des solutions
En attendant, les pirouettes c'est quasiment systématique avec MySQL

Un exemple: Tu as ton model utilisateur avec (mail, name), un jour tu veux rajouter un nouveau champ "address". En SQL, t'as la valeur par défaut qui s'ajoute (une string vide sûrement), en Mongo, tu dois set à la main les valeurs par défaut, ou gérer tes documents "legacy" qui auront un schema différent (source: https://www.mongodb.com/community/forums/t/setting-default-values-in-data-schema/8411 pas de default values).
Plus ton programme devient complexe, plus ça devient la merde. Tes anciens champs legacy seront une plaie à gérer, et tu vas devoir soit faire des vieux script de migration (alors que tout existe déjà en SQL), ou gérer les documents legacy.

Ensuite, y'a les requêtes relationnelles qui sont une plaie, et plus lentes qu'en SQL classique. Enfin bref en fait j'ai la flemme d'argumenter mais tu te rendras bien compte à un moment que la "flexibilité" est un cadeau empoisonné si tu sais pas pourquoi t'as pick cette SGBD

Facebook et d'innombrables grands sites, voir une majorité, utilisent du NoSQL et ils se portent très bien

La valeur par défaut c'est complètement bidon ce que tu me racontes, soit tu fais un script (si ton SGBD ne le prend pas en charge) pour simplement remplir les valeurs (un peu comme UPDATE en SQL), soit quand ça ne retourne rien à cet endroit dans la DB tu le retournes comme vide dans ton programme, tout simplement

T'as aussi la possibilité de faire en sorte que ça se mette à jour progressivement, à la prochaine connexion de l'utilisateur par exemple, mais en réalité ce n'est même pas nécessaire

Donc en gros ta solution à la gestion des champs legacy c'est:
- coder les exceptions pour quand les champs n'existaient pas avant
- coder les exceptions pour quand les champs ont été rename
- coder manuellement des outils de migration de schema pour recrééer ce qui est natif à la plupart des SGBD SQL
- coder manuellement les différents états de la data de l'utilisateur

Woaw trop bien la flexibilité

Si le champ n'existe pas c'est qu'il n'y a rien, donc il est vide, qu'est-ce que tu ne comprends pas ?

Je suis pas forcément d'accord avec sa problématique de base, mais toi tu es encore plus bas avec tes solutions de merde.

Une application n'a pas à palier aux insuffisances de gestion de base de données, on appelle ça un tour de passe-passe, ou déporter le problème.

C'est tellement évident que tu sais pas de quoi on parle quand on aborde le sujet de la maintenance ou de la dette technique, je sais même pas pourquoi je m'efforce.

Le mec parle de PostgreSQL la base de données "moyenâgeuse".

Je vais rien dire car c'est mon seul pseudo.

NoSQL à la rigueur c'est bien pour des logs, et y'a mieux que mongoDB, aka ElasticSearch.

Par contre pour des webapps classiques, comme ça a été dit, postgre est bien plus performant.