IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Sondage : SQL ou NoSQL, quelle est votre préférence en 2018 ? Avez-vous adopté le NoSQL ?
Partagez vos avis

Le , par Community Management

1KPARTAGES

20  2 
SQL ou NoSQL, quelle est votre préférence en 2018 ?
SQL
77 %
NoSQL
19 %
Pas d'avis
4 %
Voter 188 votants
SQL ou NoSQL, quelle est votre préférence en 2018 ? Avez-vous adopté le NoSQL ?
Vous êtes invités à voter et partager votre avis sur le NoSQL (Not only SQL)


Avec la croissance élevée et continue des volumes de données dans certains environnements telles que les plateformes Web et les environnements de réseaux sociaux, les bases de données relationnelles ont présenté des contraintes, qui ont justifié que les administrateurs (DBA) et les développeurs explorent d’autres horizons pour atteindre des niveaux d’extensibilité plus que nécessaires, pour ces cas là. C’est ainsi que Google aurait construit son SGBD propriétaire BigTable, orienté colonnes, suivi plus tard par Facebook avec Cassandra puis HBase, SourceForge avec MongoDB, et bien d’autres grands acteurs du Web.

Les systèmes de gestion de bases de données (SGBD) NoSQL semblent réussir à s’être affirmés comme une alternative valable au SGBD SQL.


Cependant le NoSQL ne semble pas couvrir toutes les attentes pour le stockage structurel des données. Le SQL aurait donc encore de bien longs jours devant lui. Mais la question de savoir laquelle des deux architectures répondrait de mieux en mieux aux exigences des applications et à la logique de gestion des données mérite d’être posée.
Un sondage en 2017 présentait SQL en première position avec plus de 31 voix sur 42 votants.

Certains langages de programmation Web, comme PHP, offrent de plus en plus des facilités à s’orienter vers du NoSQL. Et plusieurs systèmes de gestion de bases de données adoptant cette architecture voient le jour.

Vous êtes donc invités à voter pour votre préférence entre SGBD SQL et SGBD NoSQL sur la base de :
  • Stabilité et gestion de la montée en charge,
  • Scalabilité et extension dans la gestion des volumes de données,
  • Facilité d’intégration à la programmation,
  • Gestion et optimisation des ressources de stockage,
  • Bien d’autres points que vous pourrez relever.


Bien que votre vote soit le bienvenu, votre contribution dans les commentaires serait appréciée pour développer un débat de qualité.

Voir aussi

SQL Vs NoSQL, quel est votre préféré ?~~ Participez au sondage et au débat puis donnez-nous vos avis
Forum SQL
Forum NoSQL
Rtrouvez les meilleurs cours et tutoriels pour apprendre le NoSQL
La Rubrique NoSQL

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de jedema
Membre régulier https://www.developpez.com
Le 06/11/2018 à 13:24
Vous êtes plutôt voiture, avion ou marche à pied ?

Ca dépend... pour aller à New York, à Rennes ou à la boulangerie ?

Pour le NoSQL c'est la même chose. Ca dépend des besoins du projet.

Pour ma part, j'ai utilisé du NoSQL (MongoDB, Redis, BerkeleyDB) sur desprojets. J'aime bien ces technos mais elle ne remplacent pas un SGBDR lorsqu'on en a besoin.
17  0 
Avatar de Mingolito
Membre extrêmement actif https://www.developpez.com
Le 06/11/2018 à 14:24
Dans les faits le NoSQL c'est surtout utilisé par les baltringues incompétents en bases de données qui n'ont jamais rien compris au magnifique langage qu'est le SQL

16  4 
Avatar de kilroyFR
Membre éprouvé https://www.developpez.com
Le 06/11/2018 à 22:30
Ce qui est malgré tout important pour une boite c'est la perennité de son investissement.
Quand tu prends du Sqlserver/Oracle (bdd commerciales) tu sais que dans 10 ans, 15 ans tu auras encore du support et que la boite sera encore là vue leur taille.
On fait de l'oracle depuis 1997 et on a pu migrer nos systemes complexes entiers depuis tout ce temps sans soucis et on sait que dans 10 ans ce sera encore pareil. Ces memes sgbd commerciaux suivent les technos et intégrent les nouveautés a chaque nouvelle version; c'est pas comme s'ils n'evoluaient pas.
On a essayé nosql (hors oracle) mais on est vite revenu a nos fondamentaux. Ca facilité la vie du developpeur (parce qu'il va manipuler des données en json) mais la perennité sur le long terme est pas garantie et l'incompatibilité plus que probable (avec tout ce qui est nouveau/hype, la notion de compatibilité ascendante n'est plus un element essentiel alors qu'il l'es toujours pour les BDDs existantes depuis longtemps -c'est entre autre comme ca qu'ils fidelisent leurs usagers). Apres faut savoir ce que l'on veut, c'est chaque boite qui choisit en fonction de ses priorités.

PS : oui dans mon cas on fait des systemes de plusieurs dizaines de serveurs (en archi soa micro services) et pas de simples applications - pour des grands comptes mais aussi des entreprises de taille moyenne. On est en organisation devops egalement.
9  0 
Avatar de pachot
Expert éminent https://www.developpez.com
Le 09/11/2018 à 14:51
Pour prévoir l'avenir du NoSQL, je conseille de lire au moins l'intro de: A Relational Model of Data for Large Shared Data Banks E. F. CODD qui explique pourquoi on est passé de modèles hierarchiques et réseau (comme ceux du diagramme 'Non SQL Databases' de cet article) au modéle relationel et language SQL. Il est amusant de voir que ce sont ces arguments qui sont parfois avancés à tort aujourd'hui par les architectes pour aller vers du NoSQL, pour éviter l'effort de la conception d'un système d'information durable.

Un Google Translate rapide pour les francophones:
Les futurs utilisateurs de grandes banques de données doivent éviter de savoir comment les données sont organisées dans la machine (la représentation interne). [...] la plupart des programmes d'application ne doivent pas être affectés lorsque la représentation interne des données est modifiée [...].
Les systèmes de données formatés non inférentiels existants fournissent aux utilisateurs des fichiers structurés en arborescence ou des modèles de réseau un peu plus généraux. La section 1 présente les insuffisances de ces modèles. [...]
Les bases NoSQL sont liées à une structure, à un language. Pas de jointures, pas de ACID. Et surtout, un modéle optimisé pour un seul use-case. Ok pour une appli spécifique chez Google ou Amazon. Pas vraiment pour un système d'information d'entreprise.

Autre lecture rapide, les raison pour lequelles le CERN est parti sur du relationnel à l'époque (Oracle 2.3 en 1982). Justement pour sortir des contraintes des structures hierarchiques et réseau. Grâce au tables et aux jointures, le modèle relationnel est évolutif. Visiblement un bon choix vu que 32 ans plus tard, le PetaBytes est dépassé dans ces bases relationnelles.

Un Google Translate d'un extrait:
Les systèmes hiérarchiques ne [...] permettent que des possibilités limitées de structuration des données. Les systèmes de réseau nécessitent des techniques de navigation pour accéder aux données ayant une structure prédéfinie. Les systèmes relationnels transforment des structures de données complexes en simples tables bidimensionnelles faciles à visualiser. Ces systèmes sont destinés aux applications où la planification préalable est difficile et sont conçus pour offrir une facilité d'utilisation [...]
Le 'non structured data' et 'schema on read' pour faciliter la scalabilité et la flexibilité, c'est une illusion très court-terme. On peut enregistrer n'importe quel document, mais il faut que le code soit adapté à chacune de ces structures. Ce n'est valable que pour des applis/données qui ont une durée de vie très courte (regardez les use-case Google, Facebook, Twitter... sur ces technos NoSQL - leur ERP reste SQL bien sûr). Pour saisir des données qu'on est guaranti de pouvoir lire et faire évoluer dans 10 ans, de toujours lire lorsque PHP, Java, et autres languages de 3ème génération qui se succèdent, seront passés de mode, et dont on a la guarantie de la cohérence des données, les bases SQL sont toujours indispensables. Le relationnel (la principale approche scientifique de la modélisation de donnée), et le SQL (seul language de 4ème génération utilisé en entreprise aujourd'hui) évoluent mais n'ont pas d'alternatives globales.
7  0 
Avatar de SQLpro
Rédacteur https://www.developpez.com
Le 06/11/2018 à 14:15
Le choix est inepte... par ce qu'il existe aujourd'hui des SGBD Relationnels capable de faire du NoSQL et du Big Data tout à la fois dans une même base de données ... !

Exemple : Microsoft SQL Server est à la fois un SGBD relationnel +


et bien entendu le big data avec Apach spark et Kubernetes

Comme le disait récemment une étude du groupe forrester, dans les années à venir la plupart des produits NoSQL d'aujourd'hui seront morts. Ne subsisterons que quelque uns des produits les plus achevés (mongodb, neo4J, Redis, Cassandra...
Pensez à ce qui est arrivé aux SGBD Objets....
Pensez à ce qui est arrivé aux SGBD XML...

A +

Notez que Oracle fait à peu de chose près la même chose, sauf que les index verticaux ne sont pas disponibles pour les tables relationnelles.
10  4 
Avatar de Stopher
Membre averti https://www.developpez.com
Le 06/11/2018 à 12:51
Il ne s'agit pas de choisir , mais exploiter au mieux ces technologies . Un projet n'est pas égal à un sgbd .
2  0 
Avatar de Aurelien.Regat-Barrel
Expert éminent sénior https://www.developpez.com
Le 06/11/2018 à 14:13
Perso j'ai l'impression que la donne a un peu changé depuis les débuts du NoSQL. C'est toujours pareil : au début une nouvelle techno débarque et rafle la mise car elle seule sur un créneau, mais les autres ne restent pas les bras croisés et compensent progressivement leurs lacunes jusqu'à parfois repasser devant.

Je dis ça part rapport à Postgres en particulier qui a quand même bien su évoluer et s'adapter aux besoins à la marge du SQL traditionnel. Je continue d'utiliser Mongo pour du prototypage rapide, mais une fois que le modèle de données est mieux maîtrisé, SQL se montre très intéressant.

Tiens, je fais seulement maintenant le parallèle avec le débat langages dynamiques vs fortement typés.
2  0 
Avatar de Chuck 3.50
Membre confirmé https://www.developpez.com
Le 06/11/2018 à 11:59
Dans mon job on utilise SQL avec énormément de relation entre les tables, des vue, des procédures stockés, et donc je me demande comment on pourrait faire aussi bien, propre etc avec du NOSQL

par contre dans mes projets perso j'utilise NOSQL, et je sais que je pourrais jamais faire aussi vite, simplement, et facilement les choses avec SQL, car j'aime bien éviter les relations entre les tables/document quand c'est possible.

j'aimerai bien voir l'utilisation du NOSQL dans des projets d'envergure pour savoir comment c'est utilisé !
1  0 
Avatar de matd.h
Nouveau membre du Club https://www.developpez.com
Le 06/11/2018 à 13:24
Autre, pas de préférence et des cas d'utilisation différents..
1  0 
Avatar de SQLpro
Rédacteur https://www.developpez.com
Le 09/11/2018 à 16:12
Citation Envoyé par pachot Voir le message
C'est quoi un index vertical? Il y a quelques fonctionalités columnar de puis longtemps chez Oracle. Ca commence en 1993 avec Bitmap Index. Et ça continue avec Hybrid Columnar Compression et In-memory Column Store.

Indexation verticale Oracle = Colum Store. Et ce n'est disponible que pour les tables "In Memory". Par pour les tables relationnelles classique du genre OLTP, contrairement à SQL Server qui le permet sur du relationnel. Quand à parler d'indexation verticale sur du BitMap… j'espère que c'est une plaisanterie suisse !

A +
1  0