Messages de AntoineForum144

Le 08 mai 2022 à 10:49:13 :

Le 08 mai 2022 à 10:48:07 :

Le 08 mai 2022 à 10:46:07 :

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.

Pas d'argument de ta part

Oui oui allez, va faire tes "applis" de merde

T'es quand même au courant que même si tu voulais ajouter de nouveaux champs vides ou avec une valeur bidon par défaut, tu me passes la DB en 15 min c'est fait...

El famoso limitation

Le 08 mai 2022 à 10:46:07 :

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.

Pas d'argument de ta part, la vraie insuffisance c'est les DB relationnelles

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: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: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: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: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

Le 08 mai 2022 à 10:32:49 :

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

Je suis mort de rire.

Tu es vraiment un bricoleur du dimanche, Antoine.

T'as jamais travaillé sur une vraie base ou sur une vraie application, ça se voit. Tu t'es arrêté à SELECT *.

Aucun exemple comme d'habitude
Pourtant t'avais l'air si convaincu

Le 08 mai 2022 à 10:31:22 :

Le 08 mai 2022 à 10:29:32 :
Un coup le NoSQL c'est bien
Un coup c'est pas bien

Quand ça l'arrange

Il change encore plus souvent d'avis qu'Olivier Variant

Je t'ai expliqué précisément dans quel genre de cas technique le NoSQL a clairement des avantages.

Ce n'est ni performant et ni fiable pour gérer des données multiples qui ont des relations entre elles.

C'est très fiable et MongoDB prend en charge les transactions ACID
Et c'est aussi très pratique, même quand il y a beaucoup de relations

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 a toujours des solutions
Les pirouettes c'est quasiment systématique avec MySQL

Un coup le NoSQL c'est bien
Un coup c'est pas bien

Quand ça l'arrange

Il change encore plus souvent d'avis qu'Olivier Variant

En racontant n'importe quoi à la clé

Le 08 mai 2022 à 10:28:01 :
Tu mérites des vraiment des grandes claques.

Le mec me balance des articles sur le stockage clé/valeur sans rien comprendre à la problématique.

Va faire ton appli web avec uniquement du stockage clé/valeur et tue toi à la tâche, c'est tout ce que je te souhaite.

C'est fou de se comporter comme un golem pareil
Tu n'assumes même pas tes PLS

Le 08 mai 2022 à 10:25:54 :
Tu comprends rien aux avantages d'un modèle non relationnel en fait.

Tu penses que c'est quoi la problématique de Facebook ou Netflix ?

C'est la quantité de données.

Si tu t'intéressais un minimum aux différences entre les deux modèles, tu saurais que NoSQL est scalable sur des amas de données de très grande taille.

99.9% des entreprises dans le monde n'ont pas ce problème. Et toi encore moins.

Tu redemandes encore des PLS ?

Le 08 mai 2022 à 10:21:53 :

Le 08 mai 2022 à 10:19:56 :

Le 08 mai 2022 à 10:18:49 :
t'as raison, ça fait longtemps que j'ai abandonné PHP

Nonobstant tu peux quand même utiliser MySQL avec NodeJS

Oui mais en même temps autant abandonner MySQL, c'est en train de vieillir comme PHP et NoSQL se généralise car c'est moins merdique et en général plus rapide
Et franchement c'est mieux comme ça

"en général plus rapide"

Arrête de raconter n'importe quoi, s'il te plaît, Antoine.

Tiens le golem

As for speed, NoSQL is generally faster than SQL, especially for key-value storage in our experiment;

https://www.cs.rochester.edu/courses/261/fall2017/termpaper/submissions/06/Paper.pdf

Le 08 mai 2022 à 10:18:49 :
t'as raison, ça fait longtemps que j'ai abandonné PHP

Nonobstant tu peux quand même utiliser MySQL avec NodeJS

Oui mais en même temps autant abandonner MySQL, c'est en train de vieillir comme PHP et NoSQL se généralise car c'est moins merdique et en général plus rapide
Et franchement c'est mieux comme ça

Le 08 mai 2022 à 10:18:11 :
Si tu savais à quel point j'ai envi de te frapper Antoine, avec tes topic de merde pour faire style je sais faire ça je vais m'en vanter

On s'en Balékouil

GOLEM !

Le 08 mai 2022 à 10:15:26 :

Le 08 mai 2022 à 10:13:00 :

Le 08 mai 2022 à 10:11:15 :
AntoineForum qui a 15 ans de retard.

On savait très bien que tu étais un programmeur médiocre, mais de là à utiliser MongolDB...

Et bien sûr que tu peux faire des SPA avec un backend en PHP, c'est juste que t'as jamais creusé sur le comment.

En quoi MongoDB est mal le golem ?
Plein de grandes entreprises l'utilisent et quand ce n'est pas MongoDB c'est généralement des DB NoSQL similaires

Pour faire des applications web ?

C'est juste de la grosse merde.

Pas de modèle relationnel donc absolument pas performant, pas de structure donc absolument pas sûr, pas de transactions donc absolument pas fiable.

Les entreprises qui l'utilisent pour des vrais applis s'en mordent les doigts, je peux te le dire.

C'est bien à la limite si tu veux mettre en place un système de cache ou stocker des données en masse quand t'as une seule table dans ta base.

Bullshit
Le NoSQL n'est justement pas relationnel, d'où sa flexibilité
Et tu vas me dire que le NoSQL c'est de la merde ?