Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Affichage des résultats du sondage: SQL ou NoSQL, quelle est votre préférence en 2018 ?

Votants
91. Vous ne pouvez pas participer à ce sondage.
  • SQL

    62 68,13%
  • NoSQL

    15 16,48%
  • Pas d'avis

    14 15,38%
  1. #1
    Community Manager

    Avatar de Siguillaume
    Homme Profil pro
    Conseil - Consultant en systèmes d'information
    Inscrit en
    août 2007
    Messages
    5 859
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Côte d'Ivoire

    Informations professionnelles :
    Activité : Conseil - Consultant en systèmes d'information
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : août 2007
    Messages : 5 859
    Points : 31 310
    Points
    31 310

    Par défaut SQL ou NoSQL, quelle est votre préférence en 2018 ? Avez-vous adopté le NoSQL ?

    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.

    Nom : NoSQL-vs-sql.jpg
Affichages : 6264
Taille : 48,1 Ko

    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
    Vous avez envie de contribuer au sein du Club Developpez.com ? Contactez-nous maintenant !
    Vous êtes passionné, vous souhaitez partager vos connaissances en informatique, vous souhaitez faire partie de la rédaction.
    Il suffit de vous porter volontaire et de nous faire part de vos envies de contributions :
    Rédaction d'articles/cours/tutoriels, Traduction, Contribution dans la FAQ, Rédaction de news, interviews et témoignages, Organisation de défis, de débats et de sondages, Relecture technique, Modération, Correction orthographique, etc.
    Vous avez d'autres propositions de contributions à nous faire ? Vous souhaitez en savoir davantage ? N'hésitez pas à nous approcher.

  2. #2
    Membre du Club
    Homme Profil pro
    Étudiant
    Inscrit en
    mai 2012
    Messages
    35
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Étudiant
    Secteur : Industrie

    Informations forums :
    Inscription : mai 2012
    Messages : 35
    Points : 69
    Points
    69

    Par défaut

    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é !

  3. #3
    Membre averti Avatar de Stopher
    Homme Profil pro
    Responsable technique
    Inscrit en
    juin 2004
    Messages
    198
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 33
    Localisation : France, Nord (Nord Pas de Calais)

    Informations professionnelles :
    Activité : Responsable technique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : juin 2004
    Messages : 198
    Points : 444
    Points
    444

    Par défaut il n'y a pas à choisir

    Il ne s'agit pas de choisir , mais exploiter au mieux ces technologies . Un projet n'est pas égal à un sgbd .

  4. #4
    Membre régulier
    Homme Profil pro
    Développeur Fullstack (Python)
    Inscrit en
    janvier 2011
    Messages
    47
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 29
    Localisation : France, Maine et Loire (Pays de la Loire)

    Informations professionnelles :
    Activité : Développeur Fullstack (Python)
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : janvier 2011
    Messages : 47
    Points : 80
    Points
    80

    Par défaut

    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.

  5. #5
    Membre à l'essai
    Homme Profil pro
    Étudiant
    Inscrit en
    juin 2013
    Messages
    5
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : juin 2013
    Messages : 5
    Points : 13
    Points
    13

    Par défaut

    Autre, pas de préférence et des cas d'utilisation différents..

  6. #6
    Rédacteur/Modérateur


    Homme Profil pro
    Développeur .NET
    Inscrit en
    février 2004
    Messages
    19 861
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur .NET
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : février 2004
    Messages : 19 861
    Points : 39 607
    Points
    39 607

    Par défaut

    Je l'ai adopté pour un projet cette année. J'ai utilisé Azure Cosmos DB. Et à vrai dire je m'en mords un peu les doigts... Ça a de très bons côtés (très facile de modéliser des données complexes, pas besoin de tables de jointures etc, performances excellentes, etc), mais le manque de certaines features (ACID, transactions, contraintes d'intégrité, d'unicité, etc) se fait cruellement ressentir. D'autant plus avec Cosmos où le modèle de facturation fait qu'on a plutôt intérêt à mettre toutes les données dans une seule collection :/

    Si c'était à refaire, je pense que je m'orienterais plutôt vers MongoDB (qui a le support d'ACID depuis la v4) ou RavenDB.

  7. #7
    Expert éminent

    Homme Profil pro
    Architecte technique
    Inscrit en
    juin 2003
    Messages
    5 636
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Architecte technique

    Informations forums :
    Inscription : juin 2003
    Messages : 5 636
    Points : 9 989
    Points
    9 989
    Billets dans le blog
    3

    Par défaut

    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.

  8. #8
    Rédacteur
    Avatar de SQLpro
    Homme Profil pro
    Expert SGBDR & SQL, spécialiste Microsoft SQL Server
    Inscrit en
    mai 2002
    Messages
    18 211
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert SGBDR & SQL, spécialiste Microsoft SQL Server
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 18 211
    Points : 42 581
    Points
    42 581

    Par défaut

    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.
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Enseignant CNAM PACA - ISEN Toulon - CESI Aix en Provence * * * * *

  9. #9
    Membre régulier
    Profil pro
    Inscrit en
    novembre 2005
    Messages
    95
    Détails du profil
    Informations personnelles :
    Localisation : France, Seine et Marne (Île de France)

    Informations forums :
    Inscription : novembre 2005
    Messages : 95
    Points : 104
    Points
    104

    Par défaut

    adoption de NOSQL, par nécessité , mais couplé à une base SQL,

  10. #10
    Membre extrêmement actif
    Homme Profil pro
    Inscrit en
    janvier 2014
    Messages
    417
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : janvier 2014
    Messages : 417
    Points : 2 214
    Points
    2 214

    Par défaut

    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


  11. #11
    Expert éminent

    Homme Profil pro
    Architecte technique
    Inscrit en
    juin 2003
    Messages
    5 636
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Architecte technique

    Informations forums :
    Inscription : juin 2003
    Messages : 5 636
    Points : 9 989
    Points
    9 989
    Billets dans le blog
    3

    Par défaut

    Citation Envoyé par SQLpro Voir le message
    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...
    J'ai pas trouvé cette étude de Forrester mais j'ai trouvé celle-ci de Gartner qui doit en fait être celle que tu mentionnes:
    https://www.enterprisedb.com/fr/blog...magic-quadrant

    Précisons quand même que ces 2 cabinets d'analyse sont très optimistes sur l'avenir du NoSQL. Après se pose l'éternelle question de parier sur le bon cheval.

    Gartner c'est quand même très orienté grands comptes. Dans la culture devops qui s'impose à l'heure actuelle, les outils propriétaires comme Oracle ou SqlServer n'ont aucune place. On aime ou pas, mais c'est comme ça.

  12. #12
    Membre éclairé
    Homme Profil pro
    Architecte de système d'information
    Inscrit en
    août 2014
    Messages
    368
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 49
    Localisation : France, Ain (Rhône Alpes)

    Informations professionnelles :
    Activité : Architecte de système d'information

    Informations forums :
    Inscription : août 2014
    Messages : 368
    Points : 702
    Points
    702

    Par défaut

    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.

  13. #13
    Expert confirmé
    Avatar de pachot
    Homme Profil pro
    DBA au CERN (Genève), Oracle ACE Director, OCM 12c, Oak Table
    Inscrit en
    novembre 2007
    Messages
    1 629
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 47
    Localisation : Suisse

    Informations professionnelles :
    Activité : DBA au CERN (Genève), Oracle ACE Director, OCM 12c, Oak Table
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : novembre 2007
    Messages : 1 629
    Points : 5 729
    Points
    5 729
    Billets dans le blog
    5

    Par défaut

    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.
    Franck Pachot - DBA au CERN - Oracle ACE Director - OCM 12c - Oak Table member - twitter: @FranckPachot - blog: blog.pachot.net

  14. #14
    Expert confirmé
    Avatar de pachot
    Homme Profil pro
    DBA au CERN (Genève), Oracle ACE Director, OCM 12c, Oak Table
    Inscrit en
    novembre 2007
    Messages
    1 629
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 47
    Localisation : Suisse

    Informations professionnelles :
    Activité : DBA au CERN (Genève), Oracle ACE Director, OCM 12c, Oak Table
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : novembre 2007
    Messages : 1 629
    Points : 5 729
    Points
    5 729
    Billets dans le blog
    5

    Par défaut

    Citation Envoyé par SQLpro Voir le message
    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.
    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.
    Franck Pachot - DBA au CERN - Oracle ACE Director - OCM 12c - Oak Table member - twitter: @FranckPachot - blog: blog.pachot.net

  15. #15
    Rédacteur
    Avatar de SQLpro
    Homme Profil pro
    Expert SGBDR & SQL, spécialiste Microsoft SQL Server
    Inscrit en
    mai 2002
    Messages
    18 211
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert SGBDR & SQL, spécialiste Microsoft SQL Server
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 18 211
    Points : 42 581
    Points
    42 581

    Par défaut

    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 +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Enseignant CNAM PACA - ISEN Toulon - CESI Aix en Provence * * * * *

  16. #16
    Expert confirmé
    Avatar de pachot
    Homme Profil pro
    DBA au CERN (Genève), Oracle ACE Director, OCM 12c, Oak Table
    Inscrit en
    novembre 2007
    Messages
    1 629
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 47
    Localisation : Suisse

    Informations professionnelles :
    Activité : DBA au CERN (Genève), Oracle ACE Director, OCM 12c, Oak Table
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : novembre 2007
    Messages : 1 629
    Points : 5 729
    Points
    5 729
    Billets dans le blog
    5

    Par défaut

    In-Memory Column Store est un storage additionel (comme un index ou une vue materialisée) pour des tables relationnelles. Toutes les modifications sont faites sur le row store. Le Column Store est invalidé par les modifications, et mis à jour de manière asynchrone. Les requêtes analytiques peuvent en bénéficier - l'optimiseur choisit. Et si, bitmap index est la première approche columnar. Un index par colonne, bitmaps combinés pour aller trouver les lignes ensuite. Mais ce n'est pas pour de l'OLTP bien sûr.
    Franck Pachot - DBA au CERN - Oracle ACE Director - OCM 12c - Oak Table member - twitter: @FranckPachot - blog: blog.pachot.net

  17. #17
    Rédacteur
    Avatar de SQLpro
    Homme Profil pro
    Expert SGBDR & SQL, spécialiste Microsoft SQL Server
    Inscrit en
    mai 2002
    Messages
    18 211
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert SGBDR & SQL, spécialiste Microsoft SQL Server
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 18 211
    Points : 42 581
    Points
    42 581

    Par défaut

    Citation Envoyé par pachot Voir le message
    Mais ce n'est pas pour de l'OLTP bien sûr.
    Alors que le ColumsStore de SQL Server est fait pour de l'OLTP comme pour de l'OLAP… En sus de l'indexation en Hash ou range du In Memory…

    A +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Enseignant CNAM PACA - ISEN Toulon - CESI Aix en Provence * * * * *

  18. #18
    Membre à l'essai
    Homme Profil pro
    Étudiant
    Inscrit en
    octobre 2012
    Messages
    15
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Cap-Vert

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : octobre 2012
    Messages : 15
    Points : 22
    Points
    22

    Par défaut

    Citation Envoyé par Chuck 3.50 Voir le message
    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é !

    Grand risque de duplication de données

Discussions similaires

  1. SQL Vs NoSQL, quel est votre préféré ? participez au débat et donnez-nous vos avis
    Par Francis Walter dans le forum Débats sur le développement - Le Best Of
    Réponses: 40
    Dernier message: 10/11/2018, 18h09
  2. Réponses: 84
    Dernier message: 08/10/2010, 17h33

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo