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

Décisions SGBD Discussion :

SGBD : le mouvement anti-SQL s’amplifie ?


Sujet :

Décisions SGBD

  1. #41
    Inscrit

    Profil pro
    Inscrit en
    février 2004
    Messages
    862
    Détails du profil
    Informations personnelles :
    Âge : 44
    Localisation : Suisse

    Informations forums :
    Inscription : février 2004
    Messages : 862
    Points : 1 175
    Points
    1 175
    Par défaut
    Citation Envoyé par _Xavier_ Voir le message
    Au lieu de se limiter à dire que chez Google et chez facebook ça marche bien est ce qu'on peut nous montrer des études théoriques
    -->

    En effet, selon l’ingénieur de Facebook, Avinash Lakshman, son stockage de données fait confiance à Cassandra pour les interrogations, plutôt que de se servir de MySQL. Comme pour mieux justifier son choix il affirme qu’il ne faut que 0,12s pour écrire dans sa base jusqu’à 50Gb de données. Soit 2500 fois plus rapide que MySQL.
    Je peux me tromper, mais 500Gb/s en écriture ça me paraît difficilement atteignable sur les SGBDR actuels, même sans intégrité référentielle.
    In my experience, any attempt to make any system idiot proof will only challenge God to make a better idiot.

  2. #42
    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 084
    Points
    2 084
    Par défaut
    Citation Envoyé par Keihilin Voir le message
    -->
    Je peux me tromper, mais 500Gb/s en écriture ça me paraît difficilement atteignable sur les SGBDR actuels, même sans intégrité référentielle.
    Là encore il faut voir ce qui est socké, comment, pourquoi et comme c'est exploité à la fin. Pour faire 500Gb/s, il faut aussi le matos derrière.

    Ces systèmes ont aussi leurs contraintes, parfois physique.

    Mais je crois que ce sont des usage différents.

  3. #43
    Membre averti
    Profil pro
    Développeur indépendant
    Inscrit en
    août 2004
    Messages
    347
    Détails du profil
    Informations personnelles :
    Âge : 52
    Localisation : France

    Informations professionnelles :
    Activité : Développeur indépendant
    Secteur : Transports

    Informations forums :
    Inscription : août 2004
    Messages : 347
    Points : 436
    Points
    436
    Par défaut nosql mais ca recouvre quoi en fait.....
    ouais, finalement, plutot que de faire des plans sur la comete, j'ai été voir, et ca me fait peur .. j'explique..
    il veulent finalement, avoir quelque chose qui gére des tables de stockage mais sans relations entre elles, donc, ces relations (si elles sont necessaires) devront être externalisées dans le programme appelant.
    finalement, pour ce qui est de la rapidité d'execution de requetes simples visant à ajouter, modifier ou recuperer du contenu, pourquoi pas, l'equivalent d'un fichier mais accessible depuis javascript.. et oui, javascript, on retrouve les stockages json et compagnies derriére ce nosql.
    donc finalement, ce pourrait être une bonne solution, mais dans le cadre d'une demande de stockage et d'accés à des données indexées et sans possibilités de relations..
    rapidité, simplicité. et tout ca..
    le pendant de la chose, c'est que le sql permet de faire des choses assez magiques dés lors que l'on a pris le soin de reflechir et d'organiser ses données..
    ici, l'organisation, la hierarchisation ne sont plus de mises.
    on stocke les données et on les lit. point. finalement, ils reinventent le fichier plat
    mais accessible depuis un javascript avec les délais d'internet!!!
    woawww!!
    une autre explication de ce besoin, est la haine de ces gens qui ont appris le javascript et ne peuvent pas acceder à des bases de données depuis le navigateur...c'est un besoin qui pourrait se comprendre, ponctuellement, mais d'un autre coté, le javascript n'est pas fait pour charger le navigateur qui doit rester un afficheur de resultats..
    donc, pour moi, c'est du n'importe nawak..

  4. #44
    Membre habitué Avatar de Rapha222
    Profil pro
    Inscrit en
    octobre 2007
    Messages
    128
    Détails du profil
    Informations personnelles :
    Âge : 30
    Localisation : Belgique

    Informations forums :
    Inscription : octobre 2007
    Messages : 128
    Points : 167
    Points
    167
    Par défaut
    Citation Envoyé par pseudocode Voir le message
    On peut également constater que les SGBD Relationnels ont leurs limites : le typage statique des données, la structure fixe des tables et des contraintes fortes sur les relations. Ces limites apparaissent d'autant plus que la mode est à la "souplesse" dans la manipulation des données.

    Qui ne s'est pas retrouvé à devoir réécrire toutes ses requêtes SQL suite au changement de type d'un champ, ou le split d'une table en plusieurs ?
    Pour le typage dynamique, il y a ANY/SQL_VARIANT je pense, à confirmer.

    Maintenant c'est vrai que c'est pas nécéssairement recommandé ...
    Et puis je pense que c'est un peu voulu ce typage statique (performances, sécurité, optimisation de l'espace ?).
    Fedora 12 x64 (laptop) - OpenSuSe 11.2 (desktop)
    Hébergeur d'images et de fichiers (< 75Mio) gratuit et sans pub

  5. #45
    Membre chevronné

    Homme Profil pro
    Architecte logiciel
    Inscrit en
    novembre 2006
    Messages
    1 252
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 46
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Architecte logiciel
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : novembre 2006
    Messages : 1 252
    Points : 1 907
    Points
    1 907
    Par défaut
    Citation Envoyé par Rapha222 Voir le message
    Pour le typage dynamique, il y a ANY/SQL_VARIANT je pense, à confirmer.
    Pour stocker certains types de données non prévu par la norme, tu es obligé de de tricher, en éclatant la valeur sur plusieurs colonnes lorsque le type est complexe et ne se réifie pas en un type élémentaire.

    A l'époque, on rencontrait les cas des dates avec fuseau, des valeurs avec unités, des données géographiques... Aujourd'hui il y a eu quelques avancées de faites qui ont conduit à ce que les types manquants soient intégrés.

    Sinon pour réchauffer le débat, un récapitulatif des faiblesses du sql :
    http://c2.com/cgi/wiki?SqlFlaws

  6. #46
    Membre régulier
    Profil pro
    Étudiant
    Inscrit en
    janvier 2009
    Messages
    92
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : janvier 2009
    Messages : 92
    Points : 115
    Points
    115
    Par défaut
    Lors d'une discussion avec un "professionnelle" celui-ci m'a indiqué qu'il n'utilisait plus que JPA, car il en avait marre d'écrire des requêtes SQL.

    Traduction : je suis trop mauvais pour écrire des requêtes SQL qui fonctionnent du premier coup alors je prends une alternative qui ne me prend pas la tête.

    Je ne dis pas que tous les fans de "noSQL" ne comprennent rien à SQL.

    Je ne dis pas non plus que le "noSQL" c'est le mal. Il y a sans doute des cas ou c'est très utile.

    Je dis juste que j'en ai marre de voir de plus en plus de technologies émerger pour principalement remplacer les incompétences de certaines personnes.

  7. #47
    mon_nom_est_personne
    Invité(e)
    Par défaut
    Citation Envoyé par viking1404 Voir le message
    Je dis juste que j'en ai marre de voir de plus en plus de technologies émerger pour principalement remplacer les incompétences de certaines personnes.
    +1

  8. #48
    Inscrit

    Profil pro
    Inscrit en
    février 2004
    Messages
    862
    Détails du profil
    Informations personnelles :
    Âge : 44
    Localisation : Suisse

    Informations forums :
    Inscription : février 2004
    Messages : 862
    Points : 1 175
    Points
    1 175
    Par défaut
    Citation Envoyé par eomer212 Voir le message
    ouais, finalement, plutot que de faire des plans sur la comete, j'ai été voir, et ca me fait peur
    A part le mal réveillé en première page qui a pris ça comme une attaque directe sur MS SQL Server, personne ne tire de plans sur la comète


    Citation Envoyé par eomer212 Voir le message
    il veulent finalement, avoir quelque chose qui gére des tables de stockage mais sans relations entre elles, donc, ces relations (si elles sont necessaires) devront être externalisées dans le programme appelant.
    Oui oui, c'est pas pour rien que BigTable est plusieurs fois cité comme exemple.

    Citation Envoyé par eomer212 Voir le message
    ici, l'organisation, la hierarchisation ne sont plus de mises.
    on stocke les données et on les lit. point. finalement, ils reinventent le fichier plat
    Citation Envoyé par eomer212 Voir le message
    pour moi, c'est du n'importe nawak..
    Tu sais, je connais pas mal de cobolistes qui continuent à accéder à DB2 en mode natif et à traiter les tables comme des fichiers plutôt que d'utiliser SQL; ils t'expliqueront le plus sérieusement du monde que SQL c'est n'importe quoi et que l'accès natif est plus rapide (ce qui est vrai à l'échelle du pouième de seconde).

    Tu parles justement d'organisations des données, et c'est là la clé du problème. L'organisation des données induite par les SGBDR n'est pas la panacée absolue !

    Face à de nouvelles problématiques rencontrées par Google ou Facebook, on tombe clairement sur des "faiblesses" du relationnel et il faut envisager de nouvelles approches.

    Le problème est clairement que ces nouvelles approches ne se justifient que dans certains cas mais que malgré cela, il y a un risque d'effet de mode dans lequel les incompétents du SQL vont s'engouffrer...
    In my experience, any attempt to make any system idiot proof will only challenge God to make a better idiot.

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

    Informations forums :
    Inscription : décembre 2007
    Messages : 6 639
    Points : 31 214
    Points
    31 214
    Par défaut
    Citation Envoyé par Keihilin Voir le message
    (.../...)
    Tu sais, je connais pas mal de cobolistes qui continuent à accéder à DB2 en mode natif et à traiter les tables comme des fichiers plutôt que d'utiliser SQL; ils t'expliqueront le plus sérieusement du monde que SQL c'est n'importe quoi et que l'accès natif est plus rapide (ce qui est vrai à l'échelle du pouième de seconde).(.../...)
    Ca, c'est pour ma gueule. Réponse d'ingénieur : ça dépend.

    J'ai une base contrat et une base produit. Je dois faire une transaction de création/modification/suppression : évidemment, le SQL sera supérieur.

    Maintenant, je dois faire un batch qui scanne TOUS les contrats pour des raisons X ou Y(genre une revalorisation annuelle). Je peut faire un ordre SQL (Fetch / for update), ou alors une descente/remontée de base. Les deux solutions ont leurs avantages et leurs inconvénients. Le SQL pur sera plus lent. Le traitement sur fichier sera plus bavard(et il faut de toutes façons garder SQL pour manipuler les produits associés au contrat).

    Mais ma conclusion va répondre à ça :

    Citation Envoyé par Keihilin Voir le message
    Le problème est clairement que ces nouvelles approches ne se justifient que dans certains cas mais que malgré cela, il y a un risque d'effet de mode dans lequel les incompétents du SQL vont s'engouffrer...
    On vit dans un monde ou il existe des incompétents. C'est exact. Pour autant, il faut quand même que ces gens-là puissent être productifs, non? Dans mon exemple ci-dessus, traiter un fichier plat est plus accessible à un incompétent que faire du SQL pur.

    L'objectif, c'est quoi? Vivre dans un monde de bisounounours ou tout est parfait, mais personne n'y comprend rien? Ou bien adopter des solutions plus besogneuses, mais que le commun des mortels saura maintenir?

    A mon sens, une solution élégante mais que personne ne sait maintenir est une mauvaise solution.
    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.

  10. #50
    Membre confirmé
    Homme Profil pro
    Développeur Web
    Inscrit en
    décembre 2008
    Messages
    333
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 35
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Développeur Web

    Informations forums :
    Inscription : décembre 2008
    Messages : 333
    Points : 529
    Points
    529
    Par défaut
    Citation Envoyé par el_slapper Voir le message
    On vit dans un monde ou il existe des incompétents. C'est exact. Pour autant, il faut quand même que ces gens-là puissent être productifs, non? Dans mon exemple ci-dessus, traiter un fichier plat est plus accessible à un incompétent que faire du SQL pur.

    L'objectif, c'est quoi? Vivre dans un monde de bisounounours ou tout est parfait, mais personne n'y comprend rien? Ou bien adopter des solutions plus besogneuses, mais que le commun des mortels saura maintenir?

    A mon sens, une solution élégante mais que personne ne sait maintenir est une mauvaise solution.
    Ou de faire ne sorte que les personnes soient justes... formés ? S'il y a des incompétents, au lieu de leur filer des boués de secours, ils seraient peut-être mieux de les mettre à la photocopieuse ou les former aux outils nécéssaires.



    'fin, perso je suis a fond dans le XML qui correspond bien à mes petits besoins, donc j'ai rien à dire de plus, je réagissait plus à l'idée qu'à la technologie :p

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

    Informations forums :
    Inscription : décembre 2007
    Messages : 6 639
    Points : 31 214
    Points
    31 214
    Par défaut
    Citation Envoyé par Shirraz Voir le message
    Ou de faire ne sorte que les personnes soient justes... formés ? S'il y a des incompétents, au lieu de leur filer des boués de secours, ils seraient peut-être mieux de les mettre à la photocopieuse ou les former aux outils nécéssaires.

    'fin, perso je suis a fond dans le XML qui correspond bien à mes petits besoins, donc j'ai rien à dire de plus, je réagissait plus à l'idée qu'à la technologie :p
    Le truc aussi, c'est que l'être humain est limité. Le nombre de gens intelligents est encore plus limité. Et arrive toujours un moment ou on a plus que des gens limités à disposition. Ce jour là, si on a tout fait de manière trop intelligente, eh bien on se retrouve le bec dans l'eau.

    Tu peux enseigner 10 ans le SQL à quelqu'un qui n'a pas la fibre(genre ma femme), la personne n'y pannera jamais rien. Inversement, elle pourrait me donner des cours de dessin pendant 10 ans, ça serait toujours très moche. Nous humains sommes limités - et chacun a des limites différentes.
    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.

  12. #52
    Inscrit

    Profil pro
    Inscrit en
    février 2004
    Messages
    862
    Détails du profil
    Informations personnelles :
    Âge : 44
    Localisation : Suisse

    Informations forums :
    Inscription : février 2004
    Messages : 862
    Points : 1 175
    Points
    1 175
    Par défaut
    Citation Envoyé par el_slapper Voir le message
    On vit dans un monde ou il existe des incompétents. C'est exact. Pour autant, il faut quand même que ces gens-là puissent être productifs, non?
    Il faut que les incompétent puissent être productifs ? J'ai une meilleure suggestion : et si ils se recyclaient ? ou se formaient ?

    C'est vraiment quelque chose de formidable dans le monde du développement informatique : l'incompétence est parfaitement tolérée du moment que tu produis !

    C'est un peu comme si pour obtenir un diplôme d'architecte (en bâtiment) il suffisait de savoir dessiner.

    bref, on s'égare...
    In my experience, any attempt to make any system idiot proof will only challenge God to make a better idiot.

  13. #53
    Rédacteur
    Avatar de pseudocode
    Homme Profil pro
    Architecte système
    Inscrit en
    décembre 2006
    Messages
    10 062
    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 062
    Points : 15 892
    Points
    15 892
    Par défaut
    Citation Envoyé par viking1404 Voir le message
    Je dis juste que j'en ai marre de voir de plus en plus de technologies émerger pour principalement remplacer les incompétences de certaines personnes.
    C'est pas forcément de l'incompétence, mais la force de l'habitude. La solution traditionnelle pour faire de la "persistance objet" en Java c'est:
    - Un modèle objet simple (POJO)
    - une mappeur Objet/Relationnel (ORM)
    - une base de données relationnelle

    Cette solution, bien que totalement fonctionnelle est loin d''être idéale : conflit Objet/Relationnel (impedance mismatch), Schéma en double (dépendances vs relations), conversion de type Java/SQL, ...

    Et généralement, on se retrouve a recréer un langage de requête "orienté objet" au dessus du SQL, voir a taper directement dans la Base pour remonter des infos (comptage, existence, ...). Bref, beaucoup de boulot pour passer outre les contraintes de la solution "pojo+orm+sgbdr". Parfois on se rend compte qu'il est plus facile de faire un stockage brut des valeurs de l'objet (nom d'attribut+valeur) et d'écrire son propre système CRUD.

    Les NoSQListes (!) ne sont pas contre l'utilisation des SGBDR, mais ils sont contre son utilisation à tout prix comme si c'était la seule solution possible.
    ALGORITHME (n.m.): Méthode complexe de résolution d'un problème simple.

  14. #54
    En attente de confirmation mail

    Homme Profil pro
    Inscrit en
    juillet 2006
    Messages
    766
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 45
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations forums :
    Inscription : juillet 2006
    Messages : 766
    Points : 1 252
    Points
    1 252
    Par défaut
    JPA n'est pas destiné qu'aux incompétents. Je suis d'ailleurs tout aussi lent en SQL qu'en JPA QL.

    Mais quand je refactor mon projet parce que je n'ai pas un supérieur qui me pond de l'UML deux ans à l'avance, avec JPA je n'ai que la moitié, voire le tiers, à modifier. Et en faisant tourner les tests, les erreurs sont bien mieux décrites, genre un truc de de ouf, faut être triso pour pas trouver l'erreur.

    C'est un exemple. JPA est plus productifs pour bons et mauvais. Accessoirement, ce n'est pas le seul but : c'est également souvent plus performant quand on veut réutiliser des requêtes (boite de pandore ouverte )

    J'attends avec impatience JPA2 qui permettra le typesafe à l'interieur des requêtes.

  15. #55
    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 084
    Points
    2 084
    Par défaut
    En fait la finalité est biaisée.

    Tous les frameworks, de l'ORM à l'AOP en passant par les collections, le mvc, les fonctions numériques: n'ont qu'un vocation à l'origine : éviter au développeur de ré-écrire la roue.

    Seulement, ils répondent parfois à 80% des cas, et c'est pas toujours intéressant de les consevrer et d'essayer de gérer les 20% restant.

    Effectivement, c'est aussi une tendance qui "déresponsabilise" au sens où ça cache une partie au développeur. Les problèmes d'adhérence vienne souvent du fait que les outils sont choisis à priori de tout autre raisonnement.

    Concernant le SGBD, il a, et à juste raison, fait sa place dans l'informatique de gestion. Maintenant, pour la manipulation de documents, cela fait des annèes que les logiques de fs existent, d'ailleurs FAT et autres en sont la preuve, et on parle de stocker un gros élément indexé par son contenu.

    Donc, une autre utilisation.Il faut comparer et juger à périmètre constant.

  16. #56
    mon_nom_est_personne
    Invité(e)
    Par défaut
    Citation Envoyé par pseudocode Voir le message
    Les NoSQListes (!) ne sont pas contre l'utilisation des SGBDR, mais ils sont contre son utilisation à tout prix comme si c'était la seule solution possible.
    +1 comme voirs des tables de stockage d'objet serialise. Jamais compris pourquoi.

  17. #57
    Membre averti

    Inscrit en
    novembre 2007
    Messages
    197
    Détails du profil
    Informations personnelles :
    Âge : 39

    Informations forums :
    Inscription : novembre 2007
    Messages : 197
    Points : 362
    Points
    362
    Par défaut
    On peut également constater que les SGBD Relationnels ont leurs limites : le typage statique des données, la structure fixe des tables et des contraintes fortes sur les relations. Ces limites apparaissent d'autant plus que la mode est à la "souplesse" dans la manipulation des données.

    Qui ne s'est pas retrouvé à devoir réécrire toutes ses requêtes SQL suite au changement de type d'un champ, ou le split d'une table en plusieurs ?
    Pour le typage dynamique, il y a ANY/SQL_VARIANT je pense, à confirmer.

    Maintenant c'est vrai que c'est pas nécéssairement recommandé ...
    Et puis je pense que c'est un peu voulu ce typage statique (performances, sécurité, optimisation de l'espace ?).
    (désolé je ne sais toujours pas comment faire de bonne citation avec le nom du poster en haut )

    Le typage de données dans une BD relationnel ne fait pas partie de la première étape pour une bonne intégrité des données?!?
    ______________
    Never underestimated the browser
    Ne jamais sous-estimé le navigateur
    Vic Gundotra, Google IO 2009

  18. #58
    Membre extrêmement actif Avatar de eldran64
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    janvier 2008
    Messages
    341
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 35
    Localisation : France, Ille et Vilaine (Bretagne)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : janvier 2008
    Messages : 341
    Points : 1 475
    Points
    1 475
    Par défaut
    Je ne suis pas un expert dans le domaine des SGBD, mais je crois que c'est une bonne chose, que de nouvelles solutions apparaissent. Et si en plus c'est plus performant que l'ancien système, alors que demande le peuple?
    Tout le monde devrait avoir de l'esprit critique car personne ne pourra m'apporter la preuve de l'absence de celui-ci

  19. #59
    Rédacteur
    Avatar de pseudocode
    Homme Profil pro
    Architecte système
    Inscrit en
    décembre 2006
    Messages
    10 062
    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 062
    Points : 15 892
    Points
    15 892
    Par défaut
    Citation Envoyé par CIFQ_Drew Voir le message
    Le typage de données dans une BD relationnel ne fait pas partie de la première étape pour une bonne intégrité des données?!?
    Encore une fois, tout dépend de ton projet:

    - Si ton objectif originel c'est de construire une base de données, alors effectivement la définition du schéma est la première étape de ton projet.

    - Si ton objectif originel c'est de faire de la persistance de données (d'un logiciel), tes données existent déjà "avant" de créer ta BdD. La BdD n'est qu'une solution technique (parmi d'autres). Donc les problématiques d'intégrité, de relations, de typage devraient être gérées coté logiciel et non pas déportées dans la BdD.
    ALGORITHME (n.m.): Méthode complexe de résolution d'un problème simple.

  20. #60
    Membre confirmé
    Homme Profil pro
    Développeur Web
    Inscrit en
    décembre 2008
    Messages
    333
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 35
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Développeur Web

    Informations forums :
    Inscription : décembre 2008
    Messages : 333
    Points : 529
    Points
    529
    Par défaut
    Citation Envoyé par el_slapper Voir le message
    Tu peux enseigner 10 ans le SQL à quelqu'un qui n'a pas la fibre(genre ma femme), la personne n'y pannera jamais rien. Inversement, elle pourrait me donner des cours de dessin pendant 10 ans, ça serait toujours très moche. Nous humains sommes limités - et chacun a des limites différentes.

    Mais je suppose que ta femme est infirmière, secrétaire, caissière ou avocate, voir mère au foyer, pas informaticienne

    Dans la mesure où ton boulot c'est l'informatique, t'es censé être callé sur l'info, du moins dans ton domaine... Ca me fait penser au types qui "connaissent" 36 langages, mais en fait n'en maitrise aucun...
    Bref, t'as des gens qui sont chimistes et non pas mathématiciens, mais qui doivent tout de même connaître un minimum les maths pour faire correctement leur travail...


    C'est un peu comme Vista quoi, 85% des critiques sont infondés et émises par des personnes qui ne savent pas s'en servir / font n'importe quoi dessus.


    Bref, j'arrête le troll, et je vous laisse juste une petite histoire (descendre un peu pour la trad en anglais) :p

Discussions similaires

  1. SGBD : le mouvement anti-SQL s’amplifie ?
    Par Annaelle32 dans le forum Actualités
    Réponses: 76
    Dernier message: 17/07/2009, 12h04
  2. [sgbd] lancement de requetes sql
    Par Premium dans le forum SGBD
    Réponses: 3
    Dernier message: 11/11/2006, 16h12
  3. Quel SGBD choisir ? MySQL ou SQL-Server ?
    Par S_H_I dans le forum Décisions SGBD
    Réponses: 2
    Dernier message: 13/10/2006, 16h03
  4. [MySQL 5.0] Pb de SGBD et de Requete SQL clause GROUP BY
    Par skyrider dans le forum Langage SQL
    Réponses: 5
    Dernier message: 17/08/2006, 12h24
  5. [sgbd] Ouvrir une base sql
    Par Mu_Belier dans le forum SGBD
    Réponses: 4
    Dernier message: 07/06/2004, 13h05

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