Discussion :

[Bluedeep]

NoSQL est, à l'heure actuelle, le seul mécanisme pas trop mal adapté pour gérer les big data et le volume important de données totalement hétéroclites.

A ce propos, quelqu'un peut il expliquer à l'ignare que je suis la différence profonde entre le "NoSQL" et le séquentiel indexé ?

[dehorter olivier]

FIREBIRD

Simple, robuste ...

il lui manque les fonctions de fenêtrages (mais cela vient avec la version 3)

et les fonctions pour la gestions des coordonnées géographiques

[sevyc64]

A ce propos, quelqu'un peut il expliquer à l'ignare que je suis la différence profonde entre le "NoSQL" et le séquentiel indexé ?

Dans NoSQL, ce n'est pas les bases SQL qui sont remises en cause, mais un des pilier de leur structure qui est le lien relationnel entre les données.

Quelques liens renvoyer par google pour te documenter :
Wikipédia en français et en anglais, souvent plus complet.
Un livre blanc

A noter qu'il y a, à l'heure actuelle, plus de 150 SGBD NoSQL de recensés

[alassanediakite]

Dans NoSQL, ce n'est pas les bases SQL qui sont remises en cause, mais un des pilier de leur structure qui est le lien relationnel entre les données.

Je pense qu'il y a lieu d'éclaircir un peut ce point.
Pour moi (pour être trop simple):

• relationnel: intégrité prime sur la rapidité (adapté pour les domaines comme la comptabilité)
• NoSQL: rapidité prime sur l'intégrité (adapté pour les domaines comme les sites de milliards d'abonnés)

@+

[SQLpro]

Je pense qu'il y a lieu d'éclaircir un peut ce point.
Pour moi (pour être trop simple):

• relationnel: intégrité prime sur la rapidité (adapté pour les domaines comme la comptabilité)
• NoSQL: rapidité prime sur l'intégrité (adapté pour les domaines comme les sites de milliards d'abonnés)

@+

Enfin en ce moment le NoSQL a du plomb dans l'aile... Les opérateurs NoSQL commencent à faire machine arrière en rajoutant les transactions....

Ainsi cassandra avec le concept de l'Atomic batching... ça vous rappelle rien ???

le NoSQL ou l'art le prendre les informaticiens pour des cons !

Bref, retour à la case départ... NoSQL devient SQL !!!!

A +

[vidgeur]

Utilisateur de Delphi (V5 - je ne peux pas suivre les évolutions), j'aime bien Interbase. La version 6 est Open Source et fonctionne sur Windows, Mac OS X, Linux et Solaris.

[Pierre GIRARD]

...La version 6 est Open Source et fonctionne sur Windows, Mac OS X, Linux et Solaris.

Donc : identique à FireBird puisque ce dernier est issu de la version Open Source d'Interbase. Pour moi, c'est quasiment la même chose.

[ddoumeche]

NoSQL, si on aime coder ses propres routines (& fiables) de vérification d'erreurs ou si la perte de données est une option, il y a rien de plus productif

[Bluedeep]

Dans NoSQL, ce n'est pas les bases SQL qui sont remises en cause, mais un des pilier de leur structure qui est le lien relationnel entre les données.

Je reboucle donc sur ma question : dès l'instant où tu supprimes le lien relationnel et le concept d'intégrité qui va avec, où est la différence profonde avec de l'ISAM ???
(à part un nouveau mot qui fait "buzz").

[el_muchacho]

Enfin en ce moment le NoSQL a du plomb dans l'aile... Les opérateurs NoSQL commencent à faire machine arrière en rajoutant les transactions....

Ainsi cassandra avec le concept de l'Atomic batching... ça vous rappelle rien ???

le NoSQL ou l'art le prendre les informaticiens pour des cons !

Bref, retour à la case départ... NoSQL devient SQL !!!!

A +

Le NoSQL n'a pas du plomb dans l'aile du tout. Mais le terme NoSQL est entouré de bcp de méconceptions, qui il faut le dire, est un peu de la faute de tout le hype originel. En particulier, la promesse de ne plus écrire de SQL est probablement l'argument le plus stupide d'entre tous, et MongoDB (entre autres) n'est pas étranger à cela.

Il faut imaginer l'usage du NoSQL là où on faisait du "sharding", càd la distribution des tables sur plusieurs bases (en général MySQL). Cette architecture impose de très sévères restrictions sur le schéma. En particulier, la plupart du temps, il est impossible d'effectuer des jointures lorsque les tables sont découpées et réparties sur N serveurs. Pour pallier à cette impossibilité, et éviter de faire les jointures coté software (ce qui serait pénible à coder et désastreux pour les performances), le schéma est dénormalisé, autrement dit, on regroupe toutes les tables en une seule grosse table pleine de NULLs et de données redondantes (ce qui est généralement considéré à juste titre comme *mal*), et cette grosse table est distribuée sur N serveurs en fonction d'une clef naturelle bien choisie, avec un load balancer devant. Le problème vient ensuite de comment gérer la haute disponibilité (que se passe-t'il si un des serveurs tombe), l'extensibilité (comment redistribuer les clefs sur les N+1 serveurs), etc. Tous ces problèmes posent des casse-têtes d'administration velus. D'où la naissance de bases comme Cassandra et HBase, qui ne font que reprendre ce principe de schéma clef-famille de colonnes, en simplifiant fortement l'administration, et en automatisant le sharding, la redondance multisites, etc.
Ces softwares sont très bien adaptés à des matériels comme les blade servers.

Pour résumer, les bases NoSQL ne remplaceront jamais les RDBMS traditionnels, qui sont de formidables outils. Ceux qui s'imaginent le contraire devraient s'attendre à d'énormes difficultés conceptuelles. Par exemple le CQL (le langage de requête de Cassandra) n'est que très superficiellement similaire au SQL. Il est par exemple impossible de faire des range queries sur des index secondaires, ni même sur une partie quelconque de la clef naturelle: même si le CQl ressemble à du SQL, la base reste essentiellement une table clef-valeurs dans ses capacités, rien à voir avec ce que peut faire une base SQL même primitive. MongoDB est un peu plus souple, mais n'est pas très rigoureux avec la consistence et la persistence des données et peut souffrir de pb de performances. Il faut donc plutôt voir le NoSQL comme un complément pour des usages et des contraintes extrêmes, où les produits existants sont soit inadaptés, soit portant un coût prohibitif.
A noter qu'il existe des solutions commerciales intermédiaires, comme Greenplum, qui se base sur une version modifiée de PostgreSQL pour faire du massivement parallèle dans les applications analytiques.

PS: je suis sûr que je ne vous apprends rien en écrivant tout cela, mais je me suis permis d'éclairer (je l'espère) un peu plus nos lecteurs sur l'existant en NoSQL.

[el_muchacho]

Sinon, pour répondre à la question du topic, j'ai choisi PostgreSQL comme moteur dans nos produits. Il ne se contente pas d'être un bon RDBMS à la base, il se bonifie vraiment avec le temps. C'est certainement l'un des projets open source les plus professionnels qui soient.
J'avoue ne pas avoir essayé Firebird ni MariaDB.

[Pierre GIRARD]

FireBird, c'est bien pour un particulier comme moi et pour des petites bases de données. Et surtout, son intégration dans Delphi permet de faire des applications assez puissantes, performantes et ceci assez facilement même pour un programmeur amateur comme moi.

[jjc_Mtl]

Je trouve bizarre que SQLite ne soit même pas mentionné.
tous mes tests de structures et de requêtes SQL sont faits avec SQLite
j'ai aussi quelques implantations web avec SQLite et php.
http://www.sqlite.org/

[jjc_Mtl]

Désolé, je n'avais pas lu les pages précédentes.
je suis heureux de voir que je ne suis pas seul à apprécier SQLite
(sur Mac et PC)

[SQLpro]

Il faut imaginer l'usage du NoSQL là où on faisait du "sharding", càd la distribution des tables sur plusieurs bases (en général MySQL). Cette architecture impose de très sévères restrictions sur le schéma. En particulier, la plupart du temps, il est impossible d'effectuer des jointures lorsque les tables sont découpées et réparties sur N serveurs.

Cela ma fait hurler de rire !!!!

SQL Server pratique cela depuis la version 7 (1999) avec les vues partitionnées et il est parfaitement possible de faire une jointure entre la vue concaténant la partition des différentes serveurs et n'importe quelle autre table du fait que l'optimiseur SQL sait tirer partie des contraintes SQL du partitionnement...

Donc aujourd'hui ce que vous dites c'est que grâce à MySQL on est revenu 14 ans en arrière et que c'est génial !!!!

Je pisse de rire !

[sevyc64]

Cela ma fait hurler de rire !!!!

SQL Server pratique cela depuis la version 7 (1999) avec les vues partitionnées et il est parfaitement possible de faire une jointure entre la vue concaténant la partition des différentes serveurs et n'importe quelle autre table du fait que l'optimiseur SQL sait tirer partie des contraintes SQL du partitionnement...

Donc aujourd'hui ce que vous dites c'est que grâce à MySQL on est revenu 14 ans en arrière et que c'est génial !!!!

Je pisse de rire !

C'est un peu l'idée reçue qui circule, oui! Malheureusement.

Je viens de suivre un cours au cnam (smb111) ou il a été dit que les SGBD classiques comme SQLServeur, Oracle, MySQL etc n'était pas prévus pour faire de la base de données répartie, que le langage SQL habituel s'accordait mal avec les BDD réparties. Suite à une remarque concernant SQLServer (je ne connais pas las autres), le prof a confirmer que SQLServer avait bien des options, mais que c'était récent, que ce n'était pas un support complet, sans doute pas très au point et certainement très peu utilisé.

Il nous a été confirmer, dans ce cours que pour de la BDD répartie il fallait plutôt se tourner vers des structures NoSQL.
Personnellement, j'ai pas insister, parce que c'est pas avec le SMB111 que les auditeurs sauront utiliser et gérer des BDD, mais bon !

[SQLpro]

C'est un peu l'idée reçue qui circule, oui! Malheureusement.

Je viens de suivre un cours au cnam (smb111) ou il a été dit que les SGBD classiques comme SQLServeur, Oracle, MySQL etc n'était pas prévus pour faire de la base de données répartie, que le langage SQL habituel s'accordait mal avec les BDD réparties. Suite à une remarque concernant SQLServer (je ne connais pas las autres), le prof a confirmer que SQLServer avait bien des options, mais que c'était récent, que ce n'était pas un support complet, sans doute pas très au point et certainement très peu utilisé.

Il nous a été confirmer, dans ce cours que pour de la BDD répartie il fallait plutôt se tourner vers des structures NoSQL.
Personnellement, j'ai pas insister, parce que c'est pas avec le SMB111 que les auditeurs sauront utiliser et gérer des BDD, mais bon !

Je vais te faire rire, mais quand je donnais des sours d'admin au cnam je prenais SQL Server comme suport de cours et démo... Il m'a été fait remarqué par la haute direction à paris que le cours devait être fait sous Oracle et pas avec un "Access amélioré !"...
C'est navrant de voir à quel point certains enseignant soit disant de haut niveau ignorent totalement l'état de la technologie actuelle !
Il n'y a d’ailleurs que depuis quelques années que les fonctionnaire que sont les prof sont autorisé à aller voir dans le privé la vraie vie !!! Avant cela leur était interdit...

A +

[CinePhil]

sevyc64, tu as bien de la chance qu'on te parle de ces technologies dans le cours CNAM sur les BDD, ou alors celui-ci a évolué depuis que je l'ai suivi en 2003/2004.

Pour la petite histoire, le cours était divisé en deux parties, données par deux profs différents :
- un peu de théorie relationnelle ;
- pas mal de SQL.

Au début du premier cours, le prof a annoncé :
"Pour ceux que j'ai eu en BTS, on va refaire la même chose !"

Ma première impression était donc : "Il vaut quoi ce cours ?"

Et juste après : "Le SQL vu dans ce cours sera du Oracle."

Bon, en réalité, je n'ai pas souvenir qu'il y eut beaucoup de dialecte Oracle dans ce cours et je n'ai pas eu trop de difficultés lorsque j'ai eu à faire du MySQL intensivement lors de mon stage à l'INRA.

Mais dans ce cours destiné quand même à de futurs ingénieurs, il n'y avait que des connaissances basiques en modélisation de base de données et en SQL. Rien sur la réplication, le tuning d'une BDD, l'indexation, même pas de SQL un peu plus évolué genre CTE...

Bref, j'ai appris des trucs parce que je ne connaissais pas beaucoup le SQL mais j'ai trouvé ça quand même un peu décevant pour un cours de niveau ingénieur.

[al1_24]

ça ne s'est donc pas amélioré...
En 1990, mon sujet de mémoire m'a été refusé ; le projet portait sur un développement sur PC, avec un budget en millions de Francs, qui fournissait à la Direction Générale d'une grande banque les tableaux de bord qui lui permettaient d'évaluer sa rentabilité à court et moyen terme.
Le motif ? "On ne fait pas de vraie informatique sur un micro".

[CinePhil]

Pourtant, à l'époque, on faisait déjà des choses symptahiques avec "Supercalc" ou "Lotus 1 2 3 " ou, côté BDD, avec "dbase".