Discussion :

[StringBuilder]

Sinon, je viens de lire l'article Wikipedia sur NoSQL (histoire d'être un peu moins ignare).
https://fr.wikipedia.org/wiki/NoSQL

NoSQL orienté-agrégats
=> C'est typiquement un cas de dé-normalisation qu'on pourra mettre en place dans un datawarehouse : plutôt que d'avoir une base avec tout dedans, on va éclater la base avec des sous-ensembles répondants à un besoin précis

NoSQL orienté-graphes
=> Bon, ben là, je suis pas bien avancé, et j'ai pas le courage de lire l'article en anglais qui est certainement plus complet

NoSQL sans-schéma
=> On est dans la base poubelle, et je ne m'étalerai pas forcément sur ce que j'en pense

C'est certes, succin, mais y'a quand même un truc qui me met le doute...

Quand je lis le laïus à propos de l'abandon d'ACID, je suis en effet pris d'un doute affreux.

Ne serait-on pas face à des développeur qui ne sont pas développeur (stagiaire éboueurs à la limite) qui tente de modifier des données directement depuis un outil de BI, dans un datawarehouse ?

J'ai en effet l'impression qu'on prend le problème à l'envers.

Pour reprendre l'exemple du site e-commerce donné par l'article, afin de répondre plus rapidement à un besoin ponctuel (à savoir, en fonction de ce que j'ai commandé à quelles réductions j'ai droit), je fais chambouler complètement l'organisation de ma base, permettre la perte de données (je comprends mieux pourquoi quand je passe des commandes chez Amazon j'ai que la moitié des colis qui arrivent du premier coup), mais aussi toute la partie comptabilité, gestion des stocks, etc.

Personnellement, quand j'ai une base de données relationnelle d'un ERP (ou d'un site e-commerce, y'a pas de différence notable entre les deux), 99% du boulot de la base c'est quand même :
- de gérer correctement les stocks
- de gérer correctement les factures
- de gérer correctement les commandes (en tenant compte des deux premiers)

Et éventuellement, j'ai un petit "-20%" qui va apparaître à côté des chaussettes parce que le mois dernier j'ai acheté des chaussures...
=> Sauf que ce besoin, pas forcément vital, et qui va certainement évoluer énormément d'un mois à l'autre, si je dois mettre en place un DWH ou autre source de données (en lecture seule) pour le calculer, je ne vais certainement pas remettre en question toute la conception du bignou...

Quand je vois que "google, amazon, ebay, et autres cadors" sont les papas et mamans du NoSQL, vu ce que c'est, j'ai plus l'impression que c'est pour s'en servir de source de données "prémâchées" sur des frontaux fortement sollicités, que pour stocker et gérer à proprement parler la donnée vivante... Si ?

La gestion des stocks d'Amazon sont gérés dans une poubelle avec "p'têt bin que oui p'têt bin qu'non on verra bien si le magasinier trouve ton colis ou pas" ?
Que le truc qui me dit "il n'en reste plus en stock mais celui-là y'en a encore 2 et vu que je t'aime bien tu l'auras à moitié prix" soit géré en NoSQL, je veux bien le croire, mais au moment où je clique sur le bouton "commander", et qu'Amazon se connecte à ma banque pour me débiter, j'ai quelques doutes que ce soit confié à un système qui ne gère pas les règles ACID...

[sbeex]

Cette vidéo est pas mal je trouve :

Comme quoi y en a pour tous les gouts !

[StringBuilder]

Pas tout regardé d'un bout à l'autre, mais j'ai quand même bien l'impression que sans connaître NoSQL, j'ai tapé en plein dedans :
- Google propose Google Storage pour pallier aux lacunes de Google SQL, basé sur MySQL
- Le moindre travail critique sur un grand volume de données est impossible avec Google Storage (transactions très limitées)
- Google Storage tire son épingle du jeu principalement dans des cas précis où un DWH (ou même un partage de fichier) ferait la même chose

Pour moi, dans les projets qui me concernent tout du moins :
- SGBD classique (SQL Server) pour le coeur de l'application
- NoSQL éventuellement en lecture seule pour de l'analyse BI ou de la fourniture de données pré-mâchées

Après, reste à voir quelles sont les solutions de synchronisation de SQL vers NoSQL.
Mais pour moi, NoSQL n'a de réel avantage que pour la consultation (et encore, quand on prend un vrai SGBD, ça tombe un peu à l'eau), et si on doit écrire dedans, ça ne dois en aucun cas devenir le référentiel des données.
=> Je me vois mal dire au contrôleur du FISC "ah ben l'écriture comptable correspondant à cette facture n'a pas été enregistrée car y'a Régis qui avait lancé un calcul de la balance en parallèle et du coup ça a pas marché et on s'en est pas rendu compte".

En fait, je vois le NoSQL comme un complément aux SGBD, en remplacement des vues stockées.

[jpouly]

IL FAUT penser différemment en NoSQL qu'en SQL ! Et c'est à mon sens l'erreur la plus fréquente des dev de la vieille école SQL -> ils veulent retrouver les mêmes concepts ! Si je peux faire ça en SQL je veux pouvoir le faire en NoSQL ... c'est pas comme ça ^^ il faut structurer différemment il faut penser différemment.

Justement, le métier de l'informaticien c'est de structurer l'information. Donc la vielle école à raison de vouloir structurer le NO SQL.

Et au final NoSQL est vraiment bien dans des cas adaptés. le NoSQL offre une flexibilité que SQL NE PEUT PAS égaler. En sql on ajoute un champ ca implique des scripts de migrations, des problèmes car "Que fait-on avec les entrées déjà existantes ? on met à null ?"

c'est ce qu'on appel de la conception. Et de la gestion du changement. Bref il faut réfléchir à ce qu'on fait avant de la faire

En nosql on prend le problème différemment :
Ok on accepte un objet avec ce nouveau champ sans faire aucune modif dans notre bdd. Et simplement quand on le récupère on fait un petit test si ce champ est défini -> sinon ... et basta

Mouais, et avec 50 développeurs, ça va devenir un vrai bazar. D'où l'intérêt d'utiliser le SQL qui te force à avoir de la rigueur.

LE SQL c'est bien quand on a les idées bien claires de son schéma de données et qu'il ne bouge pas trop. Mais quand on a des données hétérogènes / qui évoluent beaucoup, Dieu que c'est lourd!

Ca veut dire que le bouleau de conception n'est pas fait!!! Et si le périmètre change trop, y faut taper sur les chefs / clients ... pour leur mettre les idées au clair.

Typiquement sur un projet où il faut indexer des centaines de milliers de fichiers afin de les classer (=> ajout progressif d'information au cas par cas) ben avec Go et MongoDB, je continue d'être enchanté par la productivité que j'ai face à une approche SQL. J'ajoute les infos que j'ai au moment où je les ai sans me préoccuper des données déjà existantes. Et tout ça est en place en 15 minutes sans même me prendre la tête avec un ORM où autre usine à gaz... du bonheur

C'est typiquement le cas ou le NOSQL est la meilleur solution, car il s'agit d'informations déstructurés.

Bon après pour ce qui est d'assurer des contraintes d'intégrité ou faire du relationnel, je crois que c'est enfoncer des portes ouvertes de dire que les SGBDR sont meilleurs !

D'où l'intérêt de mixer les deux .

[Aurelien.Regat-Barrel]

NoSQL orienté-graphes
=> Bon, ben là, je suis pas bien avancé, et j'ai pas le courage de lire l'article en anglais qui est certainement plus complet

Là par contre ça mérite le coup d'oeil, et je pense que c'est beaucoup moins polémique qu'un débat SQL vs Mongo. C'est typiquement destiné à un domaine du type réseau social, où on a tendance à effectuer des recherches en cascades sur les relations de relations de relations...

Ca veut dire que le bouleau de conception n'est pas fait!!! Et si le périmètre change trop, y faut taper sur les chefs / clients ... pour leur mettre les idées au clair.

Dans mon cas définir le périmètre est le but du projet ! A savoir l'entreprise a accumulé 200.000 documents dans de multiples endroit de différentes façon au cours des 15 dernières années. Le but est de normaliser tout cela. Une fois que ce sera fait, alors oui on basculera sur du SQL ou autre. En attendant, une base NoSQL est parfaite pour faire ce travail d'audit et de classification.

[kilroyFR]

Question de point de vue pour moi ce genre de remarque montre plutôt la fainéantise des gens qui ont appris le SQL et qui n'ont plus eu envie d'apprendre une autre façon de faire leur requêtes

Perso je connais très bien le SQL j'ai commencé par la et oui c'est très bien. Mais un ORM simplifie et structure la communication entre le monde de la prog et celui de la bdd et évite pas mal de désagréments, offre pas mal de souplesse. On peut très bien faire des requêtes très performantes via un ORM suffit de pas être trop c**. C'est clair que si on réfléchi pas à l'impact de faire des boucles de findById() ca va pas aller ! Mais c'est pareil avec du SQL natif... sans oublier les système de cache. J'entend a moins que vous fassiez des applications boursière bien souvent vous pouvez mettre en cache les données et réduire les requêtes !

C'est juste une question de maitrise et de préférence.

lol ! ca me fait penser aux nouveaux developpeurs qui ne pensent qu'agilité et dire aux dev seniors qu'ils ne sont pas agiles ... mais des que tu veux leur proposer quelque chose qui ne colle pas avec ce qu'ils veulent faire, d'un coup ils ne deviennent plus agiles et sont rigides et sa cachent derriere leurs outils qu'ils ne faut surtout pas remettre en cause ou changer.
Le SQL evolue en permanence donc aucun soucis il y a toujours quelque chose a apprendre pas la peine d'essayer de comprendre comment fonctionne un outil qui promet des miracles.
Quand on vient me demander de modeliser d'une certaine façon une BDD parce que ca colle mieux avec le le fonctionnement de tel ou tel ORM (vecu avec EF) ben j'envoie balader c'est evident.

Sans etre grossier et traiter les gens de c** toutes les personnes rencontrées (formations/boulot/autres SSII) sont souvent dans des situations critiques avec les ORM. Je crois que tu es bien la seule personne que j'entends avoir un retour positif sur des gros logiciels en PROD.
Ce que je reproche ce sont les devpt junior qui se jettent sur ces outils sans se poser de questions (ce que je vis dans ma boite; TOUS les prestas qui rentrent sont vendus comme experts C#/Microsoft - pour faire des applis de Gestion de BDD... et au final il faut systématiquement repasser derriere eux car leur appli fonctionne sur le LAN en local mais des que c'est en PROD avec du volume surviennent les problemes et situations de crises.

[kilroyFR]

Je ne peux que plussoyer à ton post. Tout ce que j'ai vu du nosql, c'est la gestion du bordel désorganisé. Une vision de l'avenir, des données bien organisées dans des champs bien définis, et même si on veut stocker du document, un fichier par document sur un stockage et une entrée dans une table pour garder la trace, c'est tout aussi performant que tout mettre en vrac dans un gros machin duquel on sera incapable de sortir le fichier voulu en cas de problème, alors qu'on pourra toujours réindexer une arborescence...

+1 le bordel desorganisé c'est ce qu'on appelle en 2017 l'agilité (pouvoir faire tout et son contraire au sprint suivant).
Ne jamais dire non, positive attitude (enfin surtout au debut du projet tout est beau/rose/motivation au taqué, phrases toutes faites "l'agilité c'est notre ADN' etc.) puis rapidement des qu'il faut sortir les premiers trucs + conflits ben ca bloque.
je le vis en ce moment. 3 seances avec animateur Agile; on a tout fait (speed boat, joué a la baballe etc.). on a passé notre temps a se motiver en groupe (on est les plus forts, on va y arriver, une seule team, fil yammer pour vivre le projet en live etc.)... ben des qu'on passe a la phase concrete... c'est beaucoup moins rose. Les gens savent pas t'exprimer les besoins. Alors on te dit, commencez a developpez (en bref, du vrac avec base nosql etc. on verra ce qu'on fait plus tard).
Tout ca pour cacher que le metier n'est pas maitrisé/connu. Donc on repousse plus loin et on se donne l'impression d'avance malgré tout en codant des choses (qui seront probablement jetées dans prochaine iteration).
D'ailleurs ils ne savent tellement pas ce qu'ils veulent c'est qu'on est deja dans la solution technique (ELK) sans meme savoir le besoin fonctionnel !!! (le comment avant le quoi). Si ca c'est le progres...
Quelle misere...

[StringBuilder]

C'est clair que "concevoir" AGILE, c'est un peu comme "concevoir" NoSQL.

Le problème est pris à l'envers : AGILE est un excellent outil (tout comme peut l'être NoSQL dans des situations et sur un périmètre précis) mais il ne faut en aucun cas partir de ça pour faire l'analyse et la conception.
1/ Cadrage
2/ Validation du périmètre par le client
3/ Analyse / Spécification
4/ Validation du dossier de spécifications détaillées par le client
5/ et seulement à partir de là, choix des outils et chiffrage (ce qui ne dispense pas d'avoir une vague idée ou un objectif dès le cadrage)

Donc méthode AGILE ou NoSQL, c'est qu'une fois que tout est bien cadré et qu'on sait exactement comment on va faire chaque chose qu'on peut s'y lancer.

En aucun cas commencer à remplir des post-it sur un mur et balourder chaque résultat d'un post-it dans une base NoSQL sans savoir où on va et comment on y va...

J'ai l'impression que la méthodologie est maintenant complètement passée sous silence dans la plupart des écoles.
Certainement à cause de vieux profs persuadés qu'on en est toujours aux années 80, où chaque société (de plus de 50 000 codeurs, les petites boîtes ça existait pas) a ses propres normes et méthodes de développement que le nouvel ingé apprendra au terme d'une formation interne de 9 mois en arrivant...

[SQLpro]

Là par contre ça mérite le coup d'oeil, et je pense que c'est beaucoup moins polémique qu'un débat SQL vs Mongo. C'est typiquement destiné à un domaine du type réseau social, où on a tendance à effectuer des recherches en cascades sur les relations de relations de relations...

D'abord il faudrait savoir de quoi l'on parle, car dans DGBD Relationnel le terme relation ne signifie pas du tout "lien", mais "table". En effet, les relations au sens de Codd, (père fondateur du relationnel) sont des objets mathématique porteurs de d'information, ce qui à conduit à l'algèbre relationnelle, c'est à dire à une algèbre manipulation des relations via des opérateurs, tout comme l'algèbre sur l'anneau N (nombres entiers) manipule les nombres entiers via des opérateurs... Ce qui donne de nouvelle relations (ou entier pour continuer le parallélisme).
Pour information, il existe des techniques assez simples afin de manipuler des données qui se chainent les unes au autres à la manière d'un graphe et toute ces données peuvent tenir dans une seule et même table (c'est même essentiel afin de maintenir la cohésion).

Dans mon cas définir le périmètre est le but du projet ! A savoir l'entreprise a accumulé 200.000 documents dans de multiples endroit de différentes façon au cours des 15 dernières années. Le but est de normaliser tout cela. Une fois que ce sera fait, alors oui on basculera sur du SQL ou autre. En attendant, une base NoSQL est parfaite pour faire ce travail d'audit et de classification.

Je parierais que vous n'avez jamais envisagé de faire cela avec un vrai SGBDR capable de faire du DATALINK sur des fichiers, comme c'est le cas de SQL Server via le FileStream !
M'est avis que si vous l'aviez fait, vous seriez resté en pure relationnel...

A +

[kilroyFR]

Totalement d'accord. Actuellement sur mon projet on nous demande de commencer a coder sans connaitre la finalité... partant du principe qu'on ajoutera au fur et a mesure (par contre on nous impose deja le COMMENT).
et on nous reproche deja "pourquoi ne commencons nous pas a developper"... (bon en face de nous on a une direction info (composée de prestas Athos/CAP etc. dont le but est principalement de jouer avec les technos et aligner quelques lignes dans leur CV) donc les moyens/outils sont les seules choses les interessants. Le metier n'etant pas quelque chose d'amusant/interessant pour eux).
Je pense que dans quelques semaines ca va clasher et qu'on va revenir a quelque chose de plus realiste/concret.

[al1_24]

Entendu sur un projet Agile :

On écrira les spécifications quand le développement sera terminé, comme cela on sera bien en phase.

[Aurelien.Regat-Barrel]

Entendu sur un projet Agile :

On écrira les spécifications quand le développement sera terminé, comme cela on sera bien en phase.

En même temps... j'ai déjà vécu ça sur des projets en cycle en V...

Pour information, il existe des techniques assez simples afin de manipuler des données qui se chainent les unes au autres à la manière d'un graphe et toute ces données peuvent tenir dans une seule et même table (c'est même essentiel afin de maintenir la cohésion).

Je veux bien quelques liens Je suis curieux de comparer la tête des requêtes face à un langage spécialisé comme CYPHER (Neo4j).

Je parierais que vous n'avez jamais envisagé de faire cela avec un vrai SGBDR capable de faire du DATALINK sur des fichiers, comme c'est le cas de SQL Server via le FileStream !
M'est avis que si vous l'aviez fait, vous seriez resté en pure relationnel...

Certainement, mais... quel intérêt? Dans la mesure où mes documents ne sont pas liés entre eux et que j'utilise la bdd pour leur associer des meta-données hétérogènes, je gagne quoi à utiliser SQL?

Exemple de ce que ça donne en Go:

Code go :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
type FileAttributes struct {
    FilePath   string `bson:"_id"`
    FileSize   int64
    ModTime    time.Time
    Tags       []string          ",omitempty"
    Attributes map[string]string ",omitempty"
}
 
func ScanDir(searchDir string, c *mgo.Collection) {
    filepath.Walk(searchDir, func(path string, f os.FileInfo, err error) error {
        attr := FileAttributes{
            FilePath: path,
            FileSize: f.Size(),
            ModTime:  f.ModTime(),
        }
        if err := c.Insert(&attr); err != nil {
            log.Fatal(err)
        }
        return nil
    })
}
 
func main() {
    session, err := mgo.Dial("localhost")
    if err != nil {
        panic(err)
    }
    defer session.Close()
 
    c := session.DB("test").C("files-metadata")
    ScanDir("E:/", c)
}

30 lignes de code pour:
- créer la bdd si elle n'existe pas
- créer la structure de données (avec liste et map) à insérer avec son mapping en bdd
- insérer la liste des fichiers contenus dans un répertoire en bdd

Et tu noteras que les champs vides ne sont pas injectés (via omitempty) donc pas de champs nullables inutiles

Et tout ça en une trentaine de minutes!

Autre point fort dans mon cas : le fait que dessous c'est du json. Ainsi, pour le serveur web qui affiche la vue, il suffit de renvoyer directement le résultat json d'une requête car c'est interprétable directement en javascript côté client. Il est là pour moi le gain de productivité : pas de mapping à faire / maintenir !

[StringBuilder]

Certainement, mais... quel intérêt? Dans la mesure où mes documents ne sont pas liés entre eux et que j'utilise la bdd pour leur associer des meta-données hétérogènes, je gagne quoi à utiliser SQL?

Intérêt... Humm...

Alors déjà, ton programme fait un instantané du dossier à un instant T.
Le dossier peut évoluer, la base aussi, chacun de leur côté, et ainsi les données de la base sont complètement caduques.

Ensuite, sauvegarde : le backup de la base et des fichiers sur le disque ne seront pas synchrones. Donc en cas de croûtage (destruction du disque par exemple), tu as de très grandes chances non seulement de perdre de l'information, mais d'avoir un déphasage des données lors de la restauration.

Impossible de requêter sur le contenu des fichiers (pas de recherche lexicale, pas d'interrogation XPath ou JSON du contenu des fichiers possible, etc.).

Pour en revenir à l'exemple de filtre d'image faisant de la reconnaissance OCR que j'avais codé pour SQL Server, l'avantage, c'est que l'insère ton petit million d'images dans la base de données. L'indexation fait son traitement d'OCR en asynchrone en tâche de fond.

Et ensuite tu peux faire une requête pour retrouver la liste de toutes les images contiennant le nom du ton produit le plus vendu, en une requête qui va durer environ 1ms, sans même avoir à accéder aux images elles-mêmes.
=> Je te souhaite bien du courage pour faire la même chose avec ta méthode. J'avoue, j'ai passé un peu plus d'une heure à coder le filtre OCR pour SQL Server (plus quelques heures à me documenter et trouver un moteur OCR correct).

J'en oublie certainement pléthore.

Autre point fort dans mon cas : le fait que dessous c'est du json. Ainsi, pour le serveur web qui affiche la vue, il suffit de renvoyer directement le résultat json d'une requête car c'est interprétable directement en javascript côté client. Il est là pour moi le gain de productivité : pas de mapping à faire / maintenir !

Ca tombe bien avec SQL Server tu rajoute "FOR JSON" à la fin de ta requête SQL, et ça te retourne un résultat formaté en JSON...
Idem avec "FOR XML".
=> Et l'avantage, c'est que la même requête peut produire indifféremment un datatable, du json ou du xml, sans changer une ligne de code

[SQLpro]

Exemple de ce que ça donne en Go:

Code go :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
type FileAttributes struct {
    FilePath   string `bson:"_id"`
    FileSize   int64
    ModTime    time.Time
    Tags       []string          ",omitempty"
    Attributes map[string]string ",omitempty"
}
 
func ScanDir(searchDir string, c *mgo.Collection) {
    filepath.Walk(searchDir, func(path string, f os.FileInfo, err error) error {
        attr := FileAttributes{
            FilePath: path,
            FileSize: f.Size(),
            ModTime:  f.ModTime(),
        }
        if err := c.Insert(&attr); err != nil {
            log.Fatal(err)
        }
        return nil
    })
}
 
func main() {
    session, err := mgo.Dial("localhost")
    if err != nil {
        panic(err)
    }
    defer session.Close()
 
    c := session.DB("test").C("files-metadata")
    ScanDir("E:/", c)
}

30 lignes de code pour....

Exemple de ce que cela donne en SQL Server :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
CREATE TABLE dbo.Documents AS FILETABLE WITH
	(   FILETABLE_DIRECTORY = 'MesDocuments',
	    FILETABLE_COLLATE_FILENAME = French_CI_AS);
 
SELECT FT.name, FT.is_directory, FT.file_type,
       FT.cached_file_size / 1024.0 AS FileSizeKb,
       FT.creation_time,
       FT.file_stream.GetFileNamespacePath(1, 0) AS FilePath,
       ISNULL(PT.file_stream.GetFileNamespacePath(1, 0), 'Root Directory') AS ParentPath
FROM   dbo.Documents AS FT
       LEFT OUTER JOIN dbo.Documents AS PT
            ON FT.path_locator.GetAncestor(1) = PT.path_locator
FOR JSON AUTO;

Désolé, je n'ai pas réussi à faire mieux que 2 instructions pour :
1) faire exister dans la base une table contenant tous les fichiers et tout les répertoires à partir du point d'arborescence de l'OS Windows considéré (ici MesDocuments, à partir du "storage" autorisé à lire le file système windows - question de sécurité, d'ailleurs non géré dans ton exemple...)
2) lire l'intégralité des fichiers et répertoire, sous fichiers, sous répertoires... de tous niveaux à partir de ce point et le renvoyer en JSON vers l'appli cliente... Cette dernière requête pouvant être transformée en vue pour la simplifier !

En plus le système est dynamique... Tout ajout de fichier dans l'OS est immédiatement vu par la table et vice versa... Ce que ton pauvre code est incapable de faire !

Je te conseille donc de te recycler vite et d'aller voir ce dont sont capable de vraies bases de données avec, en sus, des mécanisme dont ton pauvre code est incapable : contraintes + parallélisme !!!



A +

[Aurelien.Regat-Barrel]

Ca tombe bien avec SQL Server tu rajoute "FOR JSON" à la fin de ta requête SQL, et ça te retourne un résultat formaté en JSON...
Idem avec "FOR XML".
=> Et l'avantage, c'est que la même requête peut produire indifféremment un datatable, du json ou du xml, sans changer une ligne de code

J'ai pas droit à Sql Server (Linux/Docker oblige) mais Postgres aurait été possible. Et je découvre au passage qu'il supporte ce mécanisme de transformation vers JSON, chose que je ne connaissais pas. Donc merci pour l'info!

En plus le système est dynamique... Tout ajout de fichier dans l'OS est immédiatement vu par la table et vice versa... Ce que ton pauvre code est incapable de faire !

Bon par internet comme ça vous pouvez pas avoir le contexte précis dans mon cas, à savoir - entre autre - que ni moi ni mon serveur n'a accès à tous les documents (confidentialité). Du coup le fait de fournir un exécutable autonome (en Go) que les personnes autorisées vont lancer sur leurs répertoires pour l'indexation est considéré comme une bonne chose par elles. Mais là n'est pas le sujet de mon code d'exemple.

Mon but était d'illustrer mes propos initiaux sur la simplicité et la flexibilité offertes par une approche sans schéma (couple Mongo + Go). A savoir que ma structure de données est définie telle que j'en ai besoin dans mon code, et que la bdd s'adapte sans rien avoir à faire : "your data is the schema". En particulier j'ai une map de clé-valeurs... si c'est dans ma struct, c'est dans ma base! Et je peux librement spécialiser mon type (par héritage... ou pas!) pour certains cas de documents et là encore, la bdd s'adapte de façon transparente sans m'imposer un modèle beaucoup plus flat. Pour moi, c'est du bonheur.

Car si vous avez vite mis le doigts sur les petites choses qui nous feraient pinailler pendant des jours, vous avez omis de répondre à la question initiale : la gestion de champs "nullable" pour reprendre le terme qui a valu à un malheureux de se faire foudroyer par la colère de Zeus^^. Voici où moi j'en étais resté :
- faire un update de la table c'est crade et lourd
- créer de nouvelles tables à chaque fois c'est encore plus lourd!
- la solution "table poubelle" qui stocke du JSON... à quoi bon? MongoDB propose mieux que ça, en termes de requête, d'indexation, et de stockage (BSON = JSON binaire).

Je te conseille donc de te recycler vite et d'aller voir ce dont sont capable de vraies bases de données

Lol. La bdd n'est pas mon domaine d'expertise (voilà qui devrait te rassurer) mais je pense que ce n'est pas le cas non plus de beaucoup d'autres développeurs. Et ne t'en déplaise, la solution que j'ai mise en place répond parfaitement au problème, à savoir: faciliter le classement de 200.000 documents pendant le temps que ça prend par une dizaine de personnes et ensuite... poubelle! (à la base ce sont des feuilles Excel qui étaient utilisées...).

Là en très peu de temps, sans être spécialiste, j'ai un serveur web qui affiche une liste de documents filtrables avec possibilité pour chacun d'entre eux de renseigner des tags ou clé/valeurs au choix. Et le plus long c'est le dev web car la partie bdd a été expédiée en 30 minutes chrono, installation (Docker) du serveur compris!

Bon je suis conscient c'est pas représentatif non plus de l'utilisation classique des bdd. Mais histoire d'essayer d'être un brin constructif (même si c'est pas vraiment le but de ce topic^^), voilà ce que je retiens de nos échanges :
- le modèle NoSQL (à la Mongo) incite à priori davantage le développeur à implémenter la logique côté code plutôt que côté bdd (les SGBDR sont plus puissants à ce niveau là)
- dans la pratique beaucoup de développeurs rechignent à le faire en SQL d'où le succès des ORM
- les spécialistes en bdd s'en désolent mais les développeurs sont contents d'avoir un langage de moins à gérer
- le NoSQL serait donc plutôt à comparer au couple SQL+ORM qu'au SQL "natif"?
- c'est une techno qui est très liée au Web (JSON)
- ce que MongoDB permet de faire en terme de fonctionnalités, un SGBDR sérieux le permet aussi bien voire mieux mais l'inverse n'est pas vrai
- le faire en SQL demande plus de boulot et de réglages
- tout cela s'applique dans un contexte "classique" et non pour du big data, domaine pour lequel le NoSQL est initialement apparu! Comprendre ce dernier point c'est comprendre le choix techniques de Mongo (non ACID...).

Je conclus en disant que j'ai pas fait de SQL depuis 4 ou 5 ans. A l'époque j'avais utilisé Postgres (vues, procédures stockées, triggers...) et avait au final (plusieurs mois d'étude et conception) fait quelque chose de très satisfaisant en terme de robustesse et intégrité des données (au passage, Frédéric, la lecture de tes article m'avait bien aidé ). Et c'est clair que le NoSQL n'a rien à voir avec ça et que c'est une hérésie de l'utilisé pour un tel besoin. Mais en même temps, c'est pas ce qu'on lui demande!

A+

[Shepard]

Joli récapitulatif (+1).

Par contre si je ne dis pas de bêtises Microsoft SQL Server est disponible sous Linux.

[StringBuilder]

Joli récapitulatif (+1).

Par contre si je ne dis pas de bêtises Microsoft SQL Server est disponible sous Linux.

Si je ne m'abuse, il n'y a pas encore de version commerciale (juste des pre-release réservées à quelques gros clients) et la couverture fonctionnelle et technique n'est pas encore totalement arrêtée/communiquée.

Donc on peut espérer que d'ici quelques mois, effectivement, l'exemple de SQLPro fonctionnera sous Linux, mais aujourd'hui ce n'est malheureusement pas le cas.

CEPENDANT (oui, y'a quand même un MAIS) un serveur de base de données devant être DÉDIÉ, et SQL Server supportant parfaitement les standard tels de ODBC, il n'y a AUCUNE raison réellement valable pour le mettre de côté, même dans un environnement utilisateur full Linux.

Le seul semblant de raison serait l'absence d'administrateur qualifié pour gérer un serveur Windows. Là, personnellement, je trouve que c'est bien pipeau comme argument, mais ça n'engage que moi.
Quant au prix, rien qu'en maintenabilité du serveur et de l'application, on gagne largement le prix de la licence (surtout si on peut travailler avec SQL Server Express qui ne nécessite du coup qu'une licence Windows Server -et encore, ça tourne aussi sur les version desktop de Windows, même si là ça commence à devenir crade-).

[Aurelien.Regat-Barrel]

Merci

Par contre si je ne dis pas de bêtises Microsoft SQL Server est disponible sous Linux.

Effectivement (technical preview)!
https://hub.docker.com/r/microsoft/mssql-server-linux/

[SQLpro]

Si je ne m'abuse, il n'y a pas encore de version commerciale (juste des pre-release réservées à quelques gros clients) et la couverture fonctionnelle et technique n'est pas encore totalement arrêtée/communiquée.

Si... j'ai fait un article la dessus et proposé en actu, mais DVP n'en as pas voulu... !
https://www.developpez.net/forums/d1...er-sous-linux/

A +

[SQLpro]

Pour information, voici ce que dit Rudi Bruchez dans son ouvrage consacré au NoSQL et au Big Data... (pages 33/34)

"
Méfiez-vous des comparaisons

Une chose assez évidente, mais qui est hélas rarement mise en avant dans les comparaisons faites par les défenseurs du NoSQL avec les moteurs relationnels, c'est que MySQL est souvent utilisé comme point de comparaison. La plupart des entreprises qui ont développé des moteurs NoSQL ont un esprit open source: Google, Facebook, Twitter, Linkedln utilisent tous intensivement MySQL ou MariaDB. Twitter par exemple a développé en 2011 une couche de sharding sur MySQL nommée Gizzard.

Le problème, c'est que MySQL n'est pas le meilleur moteur relationnel. Il souffre d'un certain nombre de problématiques qui rendent son utilisation intensive et ses performances délicates, et on ne peut pas le prendre comme modèle d'une critique objective de tous les moteurs relationnels. En voici quelques preuves.

Beaucoup de défenseurs du mouvement NoSQL avancent que l'une des forces de ces moteurs est l'absence de jointures, et que ce sont les jointures qui provoquent de forts ralentissements dans les moteurs relationnels. À la base, la jointure n'est pas un problème dans un bon SGBDR. Elle se fait en général entre la clé primaire et une clé étrangère, et si toutes les deux sont indexées, cela équivaut à une recherche de correspondance à travers deux index. Si la cardinalité du résultat est faible, c'est-à-dire si la correspondance touche un petit nombre de lignes, les algorithmes de jointure des moteurs relationnels offrent d'excellentes performances. En fait, les performances sont meilleures que celles d'un moteur NoSQL, parce que ce qui coûte le plus cher dans un moteur de base de données ce sont les entrées-sorties. À partir du moment où le modèle relationnel élimine la redondance, le volume de données à parcourir pour résoudre la requête est moindre que dans un moteur NoSQL, et donc les performances sont meilleures.

Mais, historiquement, MySQL gère très mal les jointures. Jusqu'à la version 5.6 de MySQL et les versions 5.3 et 5.5 de MariaDB, le seul algorithme disponible est la boucle imbriquée. C'est un algorithme valable sur des petits volumes et qui devient totalement contre-performant sur des volumétries plus importantes. Les moteurs relationnels commerciaux implémentent deux autres algorithmes qui sont la jointure de fusion (merge join ou sort-merge join) et la jointure de hachage (hash join). Notamment, la jointure de hachage est beaucoup plus performante sur des gros volumes.

Donc MySQL n'est vraiment pas un bon point de comparaison pour les jointures volumineuses, car d'autres moteurs relationnels s'en sortent beaucoup mieux. Mais il est clair que lorsqu'on veut effectuer des jointures sur des volumes importants pour des requêtes analytiques où le nombre de correspondances est important, un moteur relationnel va montrer ses limites et le NoSQL arrive à la rescousse.

Autre exemple, on a abordé le sujet de la rigidité du modèle. Si vous utilisez MySQL, vous pouvez facilement avoir l'impression qu'il est très pénible de modifier le schéma de vos tables. Jusqu'à la version 5.6 de MySQL, un certain nombre de modifications de tables étaient effectuées « hors ligne». Beaucoup de commandes ALTER TABLE, au lieu d'effectuer simplement la modification dans la structure de la table, déclenchaient derrière le rideau la création d'une nouvelle table, suivie de la copie de toutes les données de l'ancienne table dans la nouvelle, puis de la suppression de l'ancienne table et enfin du renommage de la nouvelle. Vous imaginez l'effet sur des tables volumineuses dans un environnement fortement multi-utilisateurs. Or, bien entendu, les SGBDR ne fonctionnent pas tous ainsi.

On voit également souvent des données chiffrées de volumétrie. Par exemple, on lit qu'une table comportant un million de lignes deviendrait impossible à gérer dans un moteur relationnel. En réalité, un moteur SQL est capable de gérer correctement des tables qui comportent des centaines de millions de lignes, voire des milliards de lignes, à partir du moment où les recherches qu'on effectue sur ces tables sont sélectives et utilise de bons index. Dans le terme Big Data, Big veut dire vraiment Big.
"

Comme par hasard, tous ceux ou presque qui ont posté dans cette enfilade font des comparaisons avec MySQL qui n'est même pas un SGBD relationnel et l'un des moins performants et des plus pauvres en matière de fonctionnalités...

Les références du livre et l'extrait des pages...







A +