Reprise du message précédent :

T'es souvent confronté aux à-côté ?
T'es vieux comme Harko ?

ou ça, " a côté"  ?  avec des tables d'attributs entier/double/texte/date ?

et galérer ensuite pour reconstruire des objets corrects dans les jointures  ?
c'est sur que c'est tellement pratique à utiliser, et tellement performant

Je te parles de compromis, tu me réponds avec un raisonnement poussé à l'absurde. Comme je l'ai dis plus haut, s'il s'agit d'une colonne avec des requêtes régulières, ou un type précis, il vaux mieux que ce soit une vrai colonne , par exemple le json ne gère pas le format date.

Je ne vois pas en quoi avoir des dizaines de colonnes améliore le schéma de la base de données, et je ne vois pas en quoi mon approche contredis ton principe de base.
le schéma est plus lisible, plus souple, et même quand ça se passe mal, la pénalité est faible.

 
voilà. Le bon outil pour le bon usage. Les collègues qui veulent faire du mongo pour des applis de gestion ça me fait bien marrer...et alors quand les collègues coté exploitation vont récupérer le merdier alors qu'ils ont jamais vu une base noSQL de leur vie...

 
dans des tables spécifiques à chaque type de jeu ou je ne sais plus comment t'appelais tes trucs?
 

 
M'enfin où est la galère si tu décris entièrement ton objet en le modélisant en base avec les champs et la sémantique appropriés?
 

 
Pourquoi des dizaines de colonnes? Qu'est-ce qui t'empêche de créer des tables et des relations dédiées à chaque type de bidule, dans ton appli?
Si la seule alternative que tu vois au fichier json dans un blob c'est de rajouter autant de champs que ce qui peut apparaitre dans ton json dans une seule et unique table, effectivement c'est stupide.
Prenons un exemple simple : dans mon appli j'ai des utilisateurs qui sont des étudiants, d'autres qui sont des profs, et potentiellement plus de cas à venir, ayant chacun des propriétés spécifiques. ben je vais pas faire une table utilisateur avec tous les brols communs et un json pour le reste. Je vais certes avoir utilisateur pour tout le commun, mais aussi etudiant pour les etudiants et prof pour les profs. etudiant et prof auront probablement comme id celui d'utilisateur, mais ils auront chacun leur propriétés spécifiques. Et - magie! - si jamais un prof est finalement aussi étudiant ça marche aussi...

Le fais pas.

Je fais exactement le chemin inverse, ie perdre en responsabilité (et donc surement pognon a la longue) pour retrouver exactement ce que tu décris : job intéressant, où ce que je fais sert a quelque chose...
Au final même 25% ça achète pas la perte d'intérêt du job

+25% ça se refuse si tu as les moyens oui

perso, j'aurai bien besoin d'un doublement de salaire là
 
ma femme a fait les comptes, et globalement on est à 2 doigts du gofundme.

donc 32 tables  ? + 4 a 5 par an ?  
Si c'est ça une bonne modélisation, je passe mon tour
 
 

cf le point au dessus  
 

et donc si tu devais modéliser leur profession, tu créerais une table par profession pour avoir les champs spécifiques à chacune ?  
Ca ne me fais pas réver  
 
En fait, on ne parle pas de la même échelle : tu me parles 2 ou 3 objets différents mais stables dans le temps, et je te parle de chose qu'on construit au fur et à mesure. Forcement, on n'a pas les mêmes contraintes . Je reste sur ma vision : les champs connus et communs ont de vraies colonnes, le reste est dans des blob

 
Effectivement si t'as peur de 32 tables je comprends mieux tes réticences...le principal outil sur lequel je bosse est à >500.
Mais oui, c'est ça une bonne modélisation, je ne comprends même pas en quoi un nombre de tables de cet ordre peut être un facteur de décision.
 

 
S'il existe des champs spécifiques et pertinents à chaque profession, oui.
 

 
4 ou 5 tables de plus par an c'est peanuts, vu d'ici...ça ou rien c'est la même chose, la seule différence c'est que dans certaines MAJ de ton soft tu vas avoir des create table. Et en échange tu as des données propres, structurées, exploitables sans avoir à connaitre le format magique de ton json spécifique à chaque déclinaison de ton objet.
Ce qui me fait bien rigoler dans cette histoire, c'est que dans l'ensemble ça c'est vu comme le mal absolu :

$toto = new Pomme();
$toto = 2;

 
...mais par contre tu me dis que ça c'est un bon design :

Jte trouve un peu psychorigide skeye, vraiment.

 
Surement un peu, sur ce sujet.
Peut-être un effet de bord d'avoir dû faire de l'exploitation sur des produits externes aux bases mal branlées pendant des années...

moi vos problèmes d'exploitation, c'est pas mon problème, je suis développeur.

Moué le JSON en postgresql en tout cas c'est pas si mauvais, et en terme de performance ca se tient bien (sans etre au meme niveau qu'une table ofc)...
 
Apres faut pas tout y mettre, mais il y a pas mal de cas que je peux voir ou tout balancer en JSON et ne pas s'en occuper n'est pas un soucis. D'ailleurs je trouve que c'est une tres bonne integration au modele classique, et fait bien le lien vers la demande "nosql" qui était la il y a quelques années et dont les BDD SQL pouvaient etre vraiment merdique avec ce type de données "imprecise"...
 
Quand au modele: si un champ dans ce JSON devient important, ALTER TABLE ca existe hein et ca se fait tres bien de sortir la prop du JSON et de creer la colonne qui va bien.
Idem pour indexer ca, ca se fait bien.

500 tables, du bon design ?  
sérieux, il n'y a que celui qui a créé les tables qui sait vaguement à quoi ça correspond. Je ne parle même pas des problèmes de nommage / traduction
 
donc j'ai ma table "game" qui contient systématiquement les colonnes id/title/type/timer/score/background/... + un champ attributes en json
 
Ensuite, j'ai deux façon de pouvoir l'utiliser dans mon code. Mon premier est des passer par une factory, qui va regarder le champ type et instancier un quizz, un drag and drop, ou une course poursuite. Ainsi j'ai un objet bien défini côté applicatif
Autre approche : (duck typing) , si il y a un attributes->backgroundMusic , alors je la joue. si il y a un objet carto , je l'affiche
 
Dans les deux cas, je trouve ça propre, le schéma de la BDD reste lisible, et l'exploitation en prod est facile.  
 
Le seul scenario un peu chiant est celui ci : si je m'aperçois qu'une propriété est finalement partagée entre la majorité des mes modules ( par exemple : maintenant ils ont tous une musique de fond). J'ajoute la colonne backgroundMusic, Je fais un update à partir de la colonne attributs et je repasse sur ma factory.

 
...et au bout de 5 ans d'usage tu as 8 colonnes optionnelles ressorties de ton JSON et n'ayant pas de sens pour une partie des lignes de la table, en plus de ta colonne JSON, pour obtenir dans ta table un immonde amalgame de données cousines au lieu de regrouper de manière logique dans des tables dédiées ce qui est spécifique. Ou pire (?), des tables dédiées où tu ne mets que les colonnes extraites du JSON, et le reste des données spécifiques toujours dans le JSON de la table initiale...

skeye c'est pas le type qui apprend aux DBA de sa boite comment optimiser les requêtes ?

 
Tain mais
En gros t'es en train de comparer d'un côté des gens qui vont faire très attention à faire un beau schéma SQL et à le maintenir avec soin et de l'autre, miraculeusement, les utilisateurs de JSON qui feront évidemment n'importe quoi et ça sera de la merde.
 
Forcément vu comme ça...

 
Jolie remarque sans chercher à connaitre le périmètre fonctionnel traité.
Et j'aime beaucoup le concept de ne pas avoir non plus de documentation décrivant le modèle de données, pour le coup.  
...et la structure de ton json, il est documenté où? Quelqu'un qui regarde le schéma de ta base il va en deviner le contenu? Tu peux y mettre des contraintes d'intégrité?
 

 
La façon de l'utiliser dans le code applicatif n'est pas franchement pertinente, quelle que soit la solution choisie on trouvera toujours un moyen de s'en servir...
Au final vous me faites penser au mec super fier de lui sur blabla@php qui passait ses paramètres de fonction dans une chaîne de caractères avec séparateurs et qui trouvait ça magnifique parce-que c'était lisible et puis explode() ça marche très bien et puis on en rajoute autant qu'on veut ça change rien. Ma conclusion est finalement la même : vous êtes en train d'utiliser un outil qui dispose de notions natives pour stocker de la donnée structurée, si vous le faites à la main au lieu d'utiliser ce qui est fourni c'est probablement pas une bonne idée.

Non, je pose le problème évident que sa solution pose : si tu utilises un champ json dans ta table pour stocker des données non communes à tous les éléments de la table, inévitablement lorsque tu as besoin d'en ré-extraire du JSON la question de la façon de l'extraire et de ce que tu fais des autres données non communes se pose.
Et vu d'ici soit tu te retrouves avec des colonnes qui n'ont pas de sens pour tous les éléments de la table d'origine, soit tu éclates tes infos spécifiques dans des tables différentes (un bout dans des colonnes dédiées, un bout dans le JSON), soit tu dégages le JSON entièrement...mais du coup pourquoi ne pas avoir fait ça tout de suite?

Quel rapport avec la discussion?

Ce que tu dis n'a strictement aucun sens. On parle juste du cas qui peut émerger où tous les JSON se retrouvent avec un champ commun, qu'on peut alors extraire et faire exister dans la table d'origine comme colonne SQL basique. Y'a aucune difficulté particulière à faire ça.

Faut que tu retombes un peu en pression hein

Salut, je débarque
 
J'ai un problème de praticité niveau environnement de programmation.
Je développe un petit truc qui doit fonctionner sur un raspberry. Je viens de me mettre à git et je comptais utiliser l'éditeur de github (atom).
 
Problème, je développe sous windows et je ne peux tester que sous raspberry... je dois donc commit/push à chaque modif à la con avant de pull côté rapsberry (en ssh avec putty), puis tester. C'est lourd et sans doute ridicule comme démarche.
 
Il y a un moyen avec atom de faire une forme de ssh transparent vers le raspberry ?

 
Devil's Tiger parlait de "si un champ dans ce JSON devient important", je vois pas de mention de champ commun à toutes les lignes.
 
Ce serait d'ailleurs complètement hors de propos...on parle depuis le début d'utiliser du json pour modéliser ce qui est différent.

 
Sachant que les principaux utilisateurs du JSON sont les développeurs JS, ça se tient que ceux-là feront évidemment de la merde
 

 
QUE T'ES UN PUTAIN D'INTEGRISTE SQL VOILA LE RAPPORT!!!!!!  
 

 
Tu débarques au mauvais moment, reviens demain

genre tu t'emabarasse du contexte pour tes remarques ? genre je n'ai pas bossé sur de gros systèmes ?  
 
Mais tu as raison, tu sais, moi je ne suis qu'un débutant  
ET BORDEL : LE FORMAT JSON EST FOURNI ET SUPPORTE PAR POSTRESQL (et mariadb/mysql aussi , je crois) , on ne parle pas de champs séparés par des points virgules  

https://atom.io/packages/remote-atom ?  
sinon,un petit rsync pour pousser en direct et ne pas avoir à lancer des commandes depuis le pi  
ou un push directement vers le pi : https://www.instructables.com/id/Gi [...] pberry-Pi/

J'ai bien fait de parler de JSON dans une BDD.  

Ptin mais c'est vraiment de la merde Linux, c'est hallucinant comme ce truc n'a pas évolué depuis des années...

Juste pour donner quelques exemples (et encore, je ne suis repassé sous Linux que ce matin) :
 
- Les notifications qui s'ouvrent en haut de l'écran, centrées horizontalement... Clairement approprié comment positionnement.
 
- Les boutons d'action de ces notifs qui ne fonctionnent pas.
 
- Aucun réglage pour le touchpad, j'ai juste le scroll à deux doigts et rien d'autre. Donc 3 ou 4 doigts c'est mort, la navigation avant/arrière avec 2 doigts aussi...
 
- Aucune cohérence d'une app à l'autre dans le placement des menus etc.
 
- Le scroll pas fluide du tout.
 
- Le microphone qui n'est pas reconnu.
 
- Problèmes de HI-DPI.
 
- Nautilus qui crash quand je vais dans le dossier "Téléchargements"
 
Bref, quand on arrive de macOS, ça pique.
 
Par contre j'ai également installé Windows et pour l'instant j'ai zéro problème.

 
J'essaye de comprendre ce que tu expliques et je donne (pas forcément de la manière la plus diplomatique, soit) mon point de vue. Derrière mon insistance il ne faut pas voir un jugement de valeur ou quoi que ce soit...je n'ai juste vu à aucun moment dans les différentes réponses quoi que ce soit qui justifie l'usage d'un format json pour stocker des données.
Le seul cas d'usage d'un champ de type JSON que je vois pour l'instant serait la possibilité d'avoir un blob amélioré, contenant du json qui viendrait d'ailleurs (pas des données gérées par l'appli propriétaire de la base) et pour lequel on veut se donner la possibilité d'aller voir plus facilement ce qu'il y a dedans directement via le sgbd.  
 
Ce n'est manifestement pas ton cas, du coup je cherche à comprendre ce qu'apporte cette façon de faire par rapport à une modélisation que je considère correcte - et tout ce que je vois c'est (un peu) du confort coté applicatif. Ce n'est à mon avis pas suffisant pour contrebalancer les inconvénients.
 
Par ailleurs si tu as bossé sur de gros systèmes je comprends encore moins ton "500 tables, du bon design ?" et le non sens qui a suivi sur la compréhension du modèle...
 

Il y a une différence entre faciliter l'utilisation d'un format externe très répandu, et fournir l'ensemble des fonctionnalités natives du sgbd avec ce format. Pour le coup Postgres fournit aussi des chaines de caractères et le moyen de les splitter dans tous les sens, j'en suis sûr...je mets ça au même niveau. Le problème que j'y vois n'est pas le type de données, mais la façon de l'utiliser.

Je confirme.

Je bosse sous linux depuis X années, j'ai testé plein de distrib et DE, et j'ai toujours eu des soucis mais on s'y fait.

OSX est bien, mais mon macbook est beaucoup trop lent.. J'ai pas le fluidité de Windows. Tout est tellement plus fluide et sans bug, du coup j'ai hâte du nouveau terminal et de WSL2.

 
Tu devrais utiliser KDE tu aurais de meilleures finitions pour tout ça.
 
https://userbase.kde.org/System_Settings/Touchpad

 
Alors, pour préciser : ici le sens du job dépend fortement du client (demande à Gélatine : projet a priori super intéressant, mais stoppé du jour au lendemain par le client... Comment tu juges du sens dans un cas comme ça? )
Et ailleurs, ça serait probablement pareil.
 
Ce qui changerait sans aucun doute, c'est les contraintes liées au travail, plus que l'intérêt ou le sens du travail en lui même.
 
L'autre truc qui me titille (j'irai pas jusqu'à dire que ca me tente, mais pas loin), c'est que la population des mecs avec mon genre de poste ailleurs est nettement plus jeune (~de 10 ans) que moi.. Donc il y a une dimension de coaching/faire grandir les gens/peut être finir par les manager si j'y prend goût), que je n'ai pas ici.
 

 
aussi, oui.
ne serait-ce que 10% de plus et le CE, ça veut dire 2 semaines de colo / truc d'été pour les enfants, par exemple, l'accès aux stages dans le groupe, des jours de congé en plus (changement de convention collective), etc..
 
bref, échange de qualité de vie hors taf, contre de la qualité de vie au taf..  
 

 
De mon point de vue, si tu as un SGBD, le choix est assez simple : Si tu dois exploiter ta données dans des requêtes, c'est plus simple de les mettre dans des colonnes, pour le reste, un JSON va bien.
 
Après le JSON peut poser un problème de cohérence de la représentation : si une cardinalité change dans ta donnée représentée en JSON, la MaJ des données existantes peut devenir chiante (en SQL aussi, mais moins)
 
 
 

 
Dans un cas comme ça, si les attributs sont caractérisés par : nom / relation avec une colonne game / valeur (qui dépend du type), je pense que je partirai plutôt sur une table Attributes avec la valeur en JSON.

 
Je pense qu'il s'en fout.
 
A mon sens, le JSON dans un CLOB, c'est justement pour stocker de la donnée dont ton applicatif a besoin (en l'interprétant ou pas, on s'en fout), mais qui ne sera pas exploitée par le SGBD.
 
L'exemple de Flo me semble correspondre : si les attributs de ses jeux ne sont exploités que par l'appli, on s'en fout que ça soit lisible/exloitable/contraignable par le SGBD. Par contre, si l'appli les connaît sous forme de JSON, ça a plus de sens de les stocker comme ça que dans un modèle qu'il faudra mapper et qui finira pas manquer de souplesse.
 
 

pourtant, c'est supporté aussi par les SGBD  
 
 

Alors qu'une bonne petite doc merise imprimée dans un classeur, ça aide vachement à maintenir sa BDD, je dis ça je dis rien
 

ça dépend de ta base 100 de départ évidemment
 

quel desktop env ? et quel age du matos ? et quel distro ?
après oui Linux est pas encore au niveau de Windows ou MacOS, on va pas se mentir, encore que sous mac je m'arrache souvent les cheveux quand je veux faire qqc...quand je dois m'occuper du mac de ma femme je pète les plombs.
 

1/ pardon je savais pas que tu étais aussi dans une SSII...dans ce cas c'est différent (après faut savoir si tu seras plutot sur du forfait qui peut etre sympa, ou de la régie reloue dans un prestatorium dégueu pas refait depuis 20 ans parce que "bon ben c'est pour des prestas, alors on s'en branle"
2/ OK
3/ça si tu aimes faire c'est TRES intéressant le coaching. Ça reste un des trucs que j'ai préféré faire dans ma carrière
4/ +25% : mon propo ici c'est que le bonheur suit pas linéairement ta courbe de salaire, et que au final j'en viens à préférer un job moins bien payé mais où je m'amuserais (mon job actuel m'amuse pas vraiment, c'est relax mais j'apprend rien, mon seul moment qui m'intéresse c'est quand je bosse sur mon stage avec hepha). Et oui la convention métallo ça poutre, disons que c'est une vraie convention collective, pas un torche cul dont la moitié des "benefices" sont en dessous de la loi (j'exagère, mais la SYNTEC a été plusieurs fois reprises pour se realigner sur le minimum)
5/ ça c'est un trade-off difficile...parce que les 2 comptent

 
Moi je trouve qu'il a carrément raison et je pense que les champs json ne servent pas à cela. Ils sont utiles et d'ailleurs on les utilise parfois, mais pas pour ce genre de cas.

 
This
 

 
J'ai peut-être mal compris l'énoncé, mais pour moi les attributs sont susceptibles d'être exploités plus tard.
 
 
 

 
Quand je dis psychorigide, c'est que je trouve assez pété d'expliquer OKLM à quelqu'un que son implémentation c'est de la merde sans avoir travaillé dessus, sur un sujet où LA bonne solution n'existe pas.
On dirait des gens qui reprochent à quelqu'un d'aimer un film qu'ils trouvent mauvais.

 
C'est parce que tu as pas le bon DE.
 
Je suis sous Windows 10 en ce moment, mais je retourne régulièrement sous Mint avec Cinnamon et je n'ai absolument AUCUN de ces problèmes.
 
 

 
C'est à peu près ce que je dis plus bas, sauf que pour moi il n'est pas dans ce cas, justement.
 

 
Je dis que c'est a priori une mauvaise pratique. Il répond avec un bout d'exemple de son implémentation, je dis juste qu'avec les informations dont je dispose je ne trouve dans son exemple rien qui m'indique que ça peut être une bonne façon de faire.  
Je ne dis pas que c'est de la merde, et ça répond très probablement au cas spécifique de son appli. Je dis simplement que je ne le ferais pas comme ça sans des raisons autrement plus solides que "ça fait beaucoup de tables" et qu'en tant qu'exploitant d'une solution qui ferait comme ça je râlerais très probablement sur le casse-couilles qui met des données structurées dans une chaîne de caractères améliorée alors qu'il aurait très bien pu les mettre dans une table.