Discussion :

[Shepard]

ou je suis débile, mais si je ne me trompe pas SQL est un dinosaure du '92, et rien n'a changé depuis, sauf un petit soupçon d'XML et quelques verbes de plus....

Et monsieur SQL reste figé dans le temps (je me revois dans les bancs de physique à l'université).

Je ne vois pas trop basculer de SQL a noSQL.... mais une chose est sure, il faut un gros coup de pied dans la fourmilière et faire vraiment avancer ce fossile.

Si ce mouvement existe, c'est qu'il existe des besoins qui ne sont pas couverts par SQL !!!!

À part MySQL et SQLite qui ne gèrent pas plus que ce que tu dis, tu es à mon humble avis dans le faux ...

Quelques exemples:

Les requêtes récursives qui permettent une puissance grandement accrue, à des performances inimaginables dans un langage traditionnel (j'ai dû transformer un programme qui tournait en 10h avec C# et MS SQL Server en récupérant les données pour les traiter en un programme exécutant 7-8 requêtes SQL et faisant le même boulot en 20 secondes)

Les fonctions de fenêtrage qui permettent de faire des classements statistiques en tous genres, une fois de plus avec des performances qu'on n'ose pas imaginer dans un langage procédural

En vrac, la gestion des tableaux, des objets, l'utilisation des indexes toujours plus rapides, etc.

Et je suis sûr d'en oublier beaucoup ! La technologie SQL n'est pas du tout une technologie stagnante, c'est d'ailleurs pourquoi à mon avis (d'étudiant), les dba sont indispensables lorsqu'il s'agit de traiter des applications où la base de données est le centre critique ...

[pseudocode]

Effectivement, les BdD relationnelles deviennent de plus en plus performantes. Mais cette performance à un prix : la complexité de sa mise en oeuvre. Je m'explique.

Pour être performant, de plus en plus d'actions doivent être executées par le moteur de la BdDR ( = plus de code coté SQL, moins de code coté appli ). Ton exemple de requêtes récursives est un exemple.

Corolaire : on enrichit le schéma et le langage SQL de nouvelles fonctions. Et donc il faut de plus en plus de connaissances en BdD pour savoir les utiliser. Ta remarque sur le rôle essentiel du dba est très juste.

Plus ça va, plus les SGBDR deviennent des environnements complets d'exécution d'application. Ms-SQL server ressemble de plus a une gigantesque machine virtuelle executant des applications SQL.

[B.AF]

Effectivement, les BdD relationnelles deviennent de plus en plus performantes. Mais cette performance à un prix : la complexité de sa mise en oeuvre. Je m'explique.

Pour être performant, de plus en plus d'actions doivent être executées par le moteur de la BdDR ( = plus de code coté SQL, moins de code coté appli ). Ton exemple de requêtes récursives est un exemple.

Corolaire : on enrichit le schéma et le langage SQL de nouvelles fonctions. Et donc il faut de plus en plus de connaissances en BdD pour savoir les utiliser. Ta remarque sur le rôle essentiel du dba est très juste.

Plus ça va, plus les SGBDR deviennent des environnements complets d'exécution d'application. Ms-SQL server ressemble de plus a une gigantesque machine virtuelle executant des applications SQL.

Je suis tout à fait d'accord avec toi. On est en train de reproduire les erreurs du passé. Des applications peu ou pas évolutives, bloquées sur des technos anciennes.
L'informatique est un éternel recommencement, comme le cloud et le web 2.0 qui tentent de se rapprocher du mainframe

[ZashOne]

Plus ça va, plus les SGBDR deviennent des environnements complets d'exécution d'application. Ms-SQL server ressemble de plus a une gigantesque machine virtuelle executant des applications SQL.

Et c'est pas bien ca ?
Selon moi, les temps de développement côté" base de données sont plus rapides à mettre en place que du développemnt côté application.

[B.AF]

Et c'est pas bien ca ?
Selon moi, les temps de développement côté" base de données sont plus rapides à mettre en place que du développement côté application

Mouaai...Ça reste compliqué à tester, très orienté données.

[el_slapper]

Et c'est pas bien ca ?
Selon moi, les temps de développement côté" base de données sont plus rapides à mettre en place que du développemnt côté application.

et à maintenir? (je pose la question, je n'ai jamais eu le cas, mais j'ai des doutes)

[B.AF]

et à maintenir? (je pose la question, je n'ai jamais eu le cas, mais j'ai des doutes)

Maintenir une appli faites quasi exclusivement de SQL c'est un vrai retour dans le passé quand tu as gouté aux joies de langage plus récents.

[psychadelic]

c'est vrai que maintenir du SQL, surtout en procédures stockées est une vraie galère.

Les liens entre celles vraiment utilisées, passées, de test et les appli les utilisant réellement constitue un vrai petit foutoir.

De ce point de vue LINQ est une vraie avancée.

Mais si on résume le mouvement NoSQL à juste une autre manière d'interroger des Bases de Données structurées autrement que par des tables et des colonnes, on passe largement à coté de ce problème de maintenance.

[ametaireau]

NoSQL ne signifie pas "Non au SQL", mais bien "Not Only SQL". Il existe d'autres solutions, peut être plus adaptées à nos applications.

Rien ne sert de fonctionner par dichotomie, et de penser que l'un est à l'inverse de l'autre par ailleurs. Je trouve que l'approche de certaines bases de données NoSQL peut être très interessante et apporter beaucoup en terme d'évolution de nos pratiques de requetage de données (je pense par exemple au système de Map/Reduce).

NoSQL "s'écarte du modèle relationnel et aurait tout aussi bien pu s'appeller de façon plus appropriée le "NoREL", ou quelque chose dans ce sens" (dixit wikipedia).

Mais j'avoue que le terme est un peu fort et provocateur, à tort selon moi.

[SQLpro]

Quelques remarques<...

Et c'est pas bien ca ?
Selon moi, les temps de développement côté" base de données sont plus rapides à mettre en place que du développemnt côté application.

Oui, lisez les études de Paul Dorsey et Toons Koopelars sur le sujet. Y'a pas photo.

Maintenir une appli faites quasi exclusivement de SQL c'est un vrai retour dans le passé quand tu as gouté aux joies de langage plus récents.

Vous oubliez le point noir : les langages itératifs nécessite un déploiement et une interruption de service même pour des serveurs d'objets, alors qu'avec du SQL toute interruption est inutile puisque le code est strictement dynamique !

c'est vrai que maintenir du SQL, surtout en procédures stockées est une vraie galère.

Là vous plaisantez j'espère, c'est un problème de culture et donc de connaissance et formation...
Le code C#, Java est aussi abscons pour un néophyte que du SQL !
Mais l'avantage de SQL c'est qu'il est très richement documenté, ce qui n'est pas le cas des langages les plus récents !

Au total, je me demande si vous n'êtes pas des techno victimes comme il y a des fashion victimes ???

A +

[B.AF]

Vous oubliez le point noir : les langages itératifs nécessite un déploiement et une interruption de service même pour des serveurs d'objets, alors qu'avec du SQL toute interruption est inutile puisque le code est strictement dynamique !

Et que définissez comme interruption de service ?
Le fait que toute modification soit prise en charge instantanément ?

La plupart des langages qui sont supportés par des VM permettent de faire cela bien plus facilement qu'on ne le croit. En tous les cas .Net et Java sont très efficaces sur ce sujet. Il suffit de voir des projets comme Mono Addins, M.E.F, OSGi, RCP....Avec des mécaniques d'activation très pointues et des fonctionnalités de déploiement intégrées.

Les patchs SQL en revanche, c'est un enfer à réaliser, à gérer, à appliquer...

[Katleen Erna]

Mise à jour du 09.07.2010 par Katleen
Des développeurs vous offrent une méthode d'utilisation de NoSQL, cette technologie est-elle un must ou un feu de paille ?

Une équipe de développeurs passionnés (du site DZone) vient de publier une carte de référence intitulée "Débuter avec NoSQL et l'extension de données".

Les bases de données NoSQL (et les technologies opérationnelles sur les données associées) sont en effet désormais incontournable pour les développeurs web. Elles sont largement utilisées pour les grandes boutiques en ligne et commence à se faire une place dans les infrastructures IT.

Donc, cette carte de référence est là pour aider les professionnels à se poser les bonnes questions concernant les implémentations spécifiques de NoSQL ; tout en apportant les outils de base pour identifier les différentes technologies NoSQL et les utiliser.

Source : Getting Started with NoSQL and Data Scalability (PDF)

Trouvez-vous cette refcard utile ?

Pensez-vous qu'un développeur doive maîtriser le NoSQL, ou bien n'est-il qu'une mode passagère ?

[piklein]

Des développeurs vous offrent une méthode d'utilisation de NoSQL, cette technologie est-elle un must ou un feu de paille ?

Un peu de failles ?

[Porkepix]

Un peu de failles ?

Joli, joli!

[Nathanael Marchand]

Il est clair qu'aucun editeur n'a fait du SQL à sa sauce (le PL/SQL et le T-SQL ne sont que des vues de l'esprit). Il est aussi limpide que par exemple pour retourner les trois premières lignes d'une requêtes il existe une seule instruction (non sur Oracle ca n'est pas ROWNUM, non sur SQLServer ca n'est pas TOP, non sur MySQL ca n'est pas LIMIT)

[psychadelic]

Citation:Envoyé par ezmac
si ce mouvement existe c'est qu'il existe des besoins qui ne sont pas couverts par SQL !!!!

Lesquels par exemple ?
Personne n'a donné d'exemples concrets.

BigTable de Google par exemple, tu te débrouillerai comment toi, pour référencer, classer, restituer,... des milliards d'informations non structurées ??

[B]Mise à jour du 09.07.2010 Pensez-vous qu'un développeur doive maîtriser le NoSQL, ou bien n'est-il qu'une mode passagère ?

Même réponse

[pseudocode]

Pensez-vous qu'un développeur doive maîtriser le NoSQL, ou bien n'est-il qu'une mode passagère ?

Hum. Pour moi il n'existe pas de NoSQL à "maîtriser", sous-entendu il n'y a pas une spécification unique de ce qu'est le NoSQL. Pour moi c'est plus un philosophie consistant à réfléchir quelques instants avant de courir vers une solution SGBD.

Je pense aussi que c'est plus qu'une "mode", dans le sens où le problème de font est bien réel : comment gérer efficacement des (grandes) quantités de données non structurées, à la disponibilité changeante, et liées entre elles par des relations floues (non booléennes, temporelles, ...) ?

Je ne sais pas si la solution consiste en une évolution des SGBD actuels, où en la création d'un nouveau concept.

[daedric]

Mais est ce qu'il y a quelqu'un qui a *vraiment* regardé ce qu'etait une base de donnée NoSQL ? Le débat ici est totalement inutile et à côté de la plaque.

Vous vous contentez de dire pour la majorité:
'SQL c'est bien' et 'NoSQL c'est bien'

La comparaison des deux n'a pas lieu d'être faite ... C'est fait pour des problèmes différents ...

Exemples:

Redis peut servir à mettre en cache des données, comme memcache.
A la base c'est pour du stockage 'in memory'
Donc ça pourrait être mis en place pour mettre en cache le résultat d'une requête SQL.

Riak: Bonne distribution. On peut ajouter des nodes les doigts dans le nez, les supprimer. Map-Reduce sur les donnees reçu. Deploiement facile.

MongoDB: Base de données distribuées. Stocke du BSON. peut faire du sharding: stock dans tel ou tel noeud les données reçu selon la valeur de certaine clefs.

Cassandra: P2P mais très statique dans sa configuration (et ses super-column), stocke du json de mémoire.

Toutes gerent plus ou moins de la replication, master/slave, etc.


Une base de données relationnelles comme son nom l'indique sert à stocker des données aillant des relations. Donc je ne vois pas ou est le débat:

Par exemple: Je veux stocker des metrics d'un pool de serveur, j'utilise un Riak d'autant plus si je veux les traiter a la volée à la reception, (typiquement un retour de collectd).

Je veux faire un blog, donc: utilisateur associés avec des articles, des commentaires ... j'utiliserais un *SQL (postgres, mysql, sqlserver, oracle et j'en passe)

[pseudocode]

c'est toi qui a décidé d'en faire "2 problèmes différents" en segmentant leur utilisation par domaine. Mysql n'est plus spécialement destiné aux blogs que Riak aux métriques.

Réduire le débat a SQL=relation et NoSQL=indexation est a mon sens très restrictif.

Exemple :

Code :

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

1
2
3
4
5
6
7
8
Imaginons une application gérant des individus (A, B, C, ...) 
et une relation "fait confiance à" représentée par une valeur entre 0% et 100%. 
 
En l'absence de relation directe entre 2 individus, on utilise la transitivité :
 
si A --(fait confiance à 80% à)--> B 
et B --(fait confiance à 50% à)--> C
alors A  --(fait confiance à 50%*80%=40% à)--> C

Il s'agit donc bien ici de stocker des entités avec relations. Est-ce que SQL est le plus adapté pour gérer des requêtes du genre "quels sont les individus auquel 'A' accorde +50% de confiance" ? Et si on ajoute une notion temporelle dans la relation (valeur de confiance variant en fonction de la date) ?

[daedric]

c'est toi qui a décidé d'en faire "2 problèmes différents" en segmentant leur utilisation par domaine. Mysql n'est plus spécialement destiné aux blogs que Riak aux métriques.

Malgré tout je pense que si, après ça dépend evidemment du volume, du traitement et de la manière de les stocker.

Réduire le débat a SQL=relation et NoSQL=indexation est à mon sens très restrictif.

Je le reduis pas a ce point là il est quand même de faire des requêtes assez puissantes en NoSQL.

Simplement ce n'est pas aussi puissant que des requêtes SQL avec des jointures entre tables ...

Exemple :

Code :

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

1
2
3
4
5
6
7
8
Imaginons une application gérant des individus (A, B, C, ...) 
et une relation (fait confiance à) représentée par une valeur entre 0% et 100%. 
 
En l'absence de relation directe entre 2 individus, on utilise la transitivité :
 
si A --(fait confiance à 80% à)--> B 
et B --(fait confiance à 50% à)--> C
alors A  --(fait confiance à 50%*80%=40% à)--> C

Il s'agit donc bien ici de stocker des entités avec relations. Est-ce que SQL est le plus adapté pour gérer des requêtes du genre "quels sont les individus auquel 'A' accorde +50% de confiance" ? Et si on ajoute une notion temporelle dans la relation (valeur de confiance variant en fonction de la date) ?

A ce niveau la je pense que l'architecture rentre en compte. Si le tout doit être distribué il sera peut-être plus simple de mettre une db NoSQL qu'une base de donnée relationnelle.