IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
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

  1. #41
    Membre éprouvé
    Homme Profil pro
    Développeur informatique
    Inscrit en
    juin 2004
    Messages
    359
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 32
    Localisation : Belgique

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Enseignement

    Informations forums :
    Inscription : juin 2004
    Messages : 359
    Points : 1 245
    Points
    1 245
    Par défaut
    Citation Envoyé par ezmac Voir le message
    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 ...

  2. #42
    Rédacteur
    Avatar de pseudocode
    Homme Profil pro
    Architecte système
    Inscrit en
    décembre 2006
    Messages
    10 061
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 48
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Architecte système
    Secteur : Industrie

    Informations forums :
    Inscription : décembre 2006
    Messages : 10 061
    Points : 15 834
    Points
    15 834
    Par défaut
    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.
    ALGORITHME (n.m.): Méthode complexe de résolution d'un problème simple.

  3. #43
    Membre chevronné
    Profil pro
    Inscrit en
    février 2005
    Messages
    1 273
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : février 2005
    Messages : 1 273
    Points : 2 063
    Points
    2 063
    Par défaut
    Citation Envoyé par pseudocode Voir le message
    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

  4. #44
    Membre actif
    Inscrit en
    juillet 2007
    Messages
    357
    Détails du profil
    Informations forums :
    Inscription : juillet 2007
    Messages : 357
    Points : 280
    Points
    280
    Par défaut
    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.

  5. #45
    Membre chevronné
    Profil pro
    Inscrit en
    février 2005
    Messages
    1 273
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : février 2005
    Messages : 1 273
    Points : 2 063
    Points
    2 063
    Par défaut
    Citation Envoyé par ZashOne Voir le message
    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.

  6. #46
    Expert éminent sénior
    Profil pro
    Inscrit en
    décembre 2007
    Messages
    6 614
    Détails du profil
    Informations personnelles :
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations forums :
    Inscription : décembre 2007
    Messages : 6 614
    Points : 31 084
    Points
    31 084
    Par défaut
    Citation Envoyé par ZashOne Voir le message
    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)
    Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
    1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
    2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
    3)le temps de comprendre toutes les exigences, le projet est terminé
    4)le temps de terminer le projet, les exigences ont changé
    Et le serment de non-allégiance :
    Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.

  7. #47
    Membre chevronné
    Profil pro
    Inscrit en
    février 2005
    Messages
    1 273
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : février 2005
    Messages : 1 273
    Points : 2 063
    Points
    2 063
    Par défaut
    Citation Envoyé par el_slapper Voir le message
    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.

  8. #48
    Expert confirmé Avatar de psychadelic
    Profil pro
    Inscrit en
    mai 2010
    Messages
    2 529
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : mai 2010
    Messages : 2 529
    Points : 4 556
    Points
    4 556
    Par défaut
    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.
    «La pluralité des voix n'est pas une preuve, pour les vérités malaisées à découvrir, tant il est bien plus vraisemblable qu'un homme seul les ait rencontrées que tout un peuple.» [ René Descartes ] - Discours de la méthode

  9. #49
    Futur Membre du Club
    Inscrit en
    février 2007
    Messages
    4
    Détails du profil
    Informations forums :
    Inscription : février 2007
    Messages : 4
    Points : 6
    Points
    6
    Par défaut
    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.

  10. #50
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    mai 2002
    Messages
    20 870
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 20 870
    Points : 49 603
    Points
    49 603
    Billets dans le blog
    1
    Par défaut
    Quelques remarques<...

    Citation Envoyé par ZashOne Voir le message
    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.

    Citation Envoyé par B.AF Voir le message
    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 !

    Citation Envoyé par psychadelic Voir le message
    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 +
    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...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

  11. #51
    Membre chevronné
    Profil pro
    Inscrit en
    février 2005
    Messages
    1 273
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : février 2005
    Messages : 1 273
    Points : 2 063
    Points
    2 063
    Par défaut
    Citation Envoyé par SQLpro Voir le message
    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...

  12. #52
    Expert éminent sénior
    Avatar de Katleen Erna
    Profil pro
    Inscrit en
    juillet 2009
    Messages
    1 547
    Détails du profil
    Informations personnelles :
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : juillet 2009
    Messages : 1 547
    Points : 75 937
    Points
    75 937
    Par défaut
    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 ?

  13. #53
    Membre à l'essai
    Profil pro
    Inscrit en
    février 2008
    Messages
    4
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : février 2008
    Messages : 4
    Points : 10
    Points
    10
    Par défaut
    Citation Envoyé par Katleen Erna Voir le message

    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 ?

  14. #54
    Membre habitué
    Profil pro
    Inscrit en
    mai 2008
    Messages
    92
    Détails du profil
    Informations personnelles :
    Âge : 30
    Localisation : France

    Informations forums :
    Inscription : mai 2008
    Messages : 92
    Points : 163
    Points
    163
    Par défaut
    Citation Envoyé par piklein Voir le message
    Un peu de failles ?
    Joli, joli!

  15. #55
    Rédacteur
    Avatar de Nathanael Marchand
    Homme Profil pro
    Expert .Net So@t
    Inscrit en
    octobre 2008
    Messages
    3 615
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 35
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Expert .Net So@t
    Secteur : Conseil

    Informations forums :
    Inscription : octobre 2008
    Messages : 3 615
    Points : 8 082
    Points
    8 082
    Par défaut
    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)

  16. #56
    Expert confirmé Avatar de psychadelic
    Profil pro
    Inscrit en
    mai 2010
    Messages
    2 529
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : mai 2010
    Messages : 2 529
    Points : 4 556
    Points
    4 556
    Par défaut
    Citation Envoyé par Lung Voir le message
    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 ??

    Citation Envoyé par Katleen Erna Voir le message
    [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
    «La pluralité des voix n'est pas une preuve, pour les vérités malaisées à découvrir, tant il est bien plus vraisemblable qu'un homme seul les ait rencontrées que tout un peuple.» [ René Descartes ] - Discours de la méthode

  17. #57
    Rédacteur
    Avatar de pseudocode
    Homme Profil pro
    Architecte système
    Inscrit en
    décembre 2006
    Messages
    10 061
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 48
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Architecte système
    Secteur : Industrie

    Informations forums :
    Inscription : décembre 2006
    Messages : 10 061
    Points : 15 834
    Points
    15 834
    Par défaut
    Citation Envoyé par Katleen Erna Voir le message
    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.
    ALGORITHME (n.m.): Méthode complexe de résolution d'un problème simple.

  18. #58
    Membre actif
    Profil pro
    Étudiant
    Inscrit en
    juillet 2004
    Messages
    230
    Détails du profil
    Informations personnelles :
    Âge : 31
    Localisation : Canada

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : juillet 2004
    Messages : 230
    Points : 250
    Points
    250
    Par défaut
    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)

  19. #59
    Rédacteur
    Avatar de pseudocode
    Homme Profil pro
    Architecte système
    Inscrit en
    décembre 2006
    Messages
    10 061
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 48
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Architecte système
    Secteur : Industrie

    Informations forums :
    Inscription : décembre 2006
    Messages : 10 061
    Points : 15 834
    Points
    15 834
    Par défaut
    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) ?
    ALGORITHME (n.m.): Méthode complexe de résolution d'un problème simple.

  20. #60
    Membre actif
    Profil pro
    Étudiant
    Inscrit en
    juillet 2004
    Messages
    230
    Détails du profil
    Informations personnelles :
    Âge : 31
    Localisation : Canada

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : juillet 2004
    Messages : 230
    Points : 250
    Points
    250
    Par défaut
    Citation Envoyé par pseudocode Voir le message
    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.

    Citation Envoyé par pseudocode Voir le message
    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 ...

    Citation Envoyé par pseudocode Voir le message
    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.

Discussions similaires

  1. Réponses: 72
    Dernier message: 05/02/2011, 18h16
  2. Réponses: 6
    Dernier message: 24/03/2010, 19h36
  3. Réponses: 20
    Dernier message: 16/11/2009, 23h04
  4. Réponses: 2
    Dernier message: 10/12/2008, 10h53
  5. [Débutant] créer une méthode particuliere utilisable à volonté
    Par singleProject dans le forum Débuter avec Java
    Réponses: 16
    Dernier message: 10/06/2008, 08h16

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