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

MySQL Discussion :

Désaccord avec SQLPRO !


Sujet :

MySQL

  1. #1
    Expert éminent sénior Avatar de Artemus24
    Homme Profil pro
    Agent secret au service du président Ulysses S. Grant !
    Inscrit en
    Février 2011
    Messages
    6 346
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Agent secret au service du président Ulysses S. Grant !
    Secteur : Finance

    Informations forums :
    Inscription : Février 2011
    Messages : 6 346
    Points : 18 958
    Points
    18 958
    Par défaut Désaccord avec SQLPRO !
    Salut SQLPRO.

    Nous allons consacré ce sujet pour débattre de nos désaccords.
    Le premier point que je constate à plusieurs reprises est que nous ne nous comprenons pas.

    Quand je dis que la logique ternaire n'apporte rien de plus vis-à-vis de la logique binaire dans le traitement des lignes, tout ce que vous me dites, c'est de me référer à la norme.
    Si j'avais besoin de connaitre la norme sur ce point, je vous l'aurais explicitement demandé, mais ce n'est pas ce que je recherche.
    Or vous reformulez à votre façon ce que j'ai dit précédemment.

    Vous avez une excellente connaissance de votre domaine de compétence, mais vous avez une vision sectaire des choses.
    A savoir que votre bible est la norme et tout ce qui n'est pas dans la norme est nécessairement faux.
    J'ai l'impression d'avoir à faire à un gourou où le dogme est votre crédo ! Inversement, j'ai tendance à refaire le monde !

    Voire même quand quelqu'un pense différemment de vous, cela vous dérange ! En réagissant ainsi, vous refusez de réfléchir et de vous mettre à la porter des autres.
    C'est peut-être un défaut du métier de professeur, de croire que vous seul détenez la connaissance et que votre fonction est de la dispenser.
    C'est un échange du savoir en sens unique !!!
    Il se peut aussi que vous n'avez plus rien à apprendre, ou selon le principe de Peter, vous avez atteint votre niveau d'incompétence.

    Le problème sur lequel vous passez vite est le fait que le NULL est traité comme une valeur dans la logique ternaire.
    Et cela ne vous dérange aucunement ??? J'ai appris que le NULL est un marqueur et non une valeur.
    Donc pourquoi le traiter comme une valeur dans la logique ternaire alors que c'est une marqueur ?

    Il y a deux opérateurs, soit l'égalité "where colonne = {valeur}" qui gère les valeurs ou le IS "where colonne IS NULL" qui gère le cas particulier du marqueur NULL.
    Donc il ne peut pas y avoir confusion entre la valeur et le marqueur qu'est le NULL.
    Les deux prédicats nous retournent toujours soit VRAI ou soit FAUX.
    En quoi inventer une troisième valeur comme "INCONNU" apporte quelque chose de plus ?
    C'est sur ce point de compréhension que je vous sollicite et non sur ce que la norme indique !

    Citation Envoyé par SQLPRO
    Tout simplement changer de SGBD pour un vrai SGBD réellement relationnel ce que MySQL n'est pas... !
    Et quand c'est pas possible de changer de SGBD, on fait comment ?

    Citation Envoyé par SQLPRO
    ... que un produit met dans son nom l'acronyme SQL (qui d'ailleurs est un langage) qu'il est relationnel...
    SQL est un langage de requête afin de manipuler les bases de données.
    Aucun rapport avec le modèle d'organisation des données de type hiérarchique, réseau ou encore relationnel.
    Sur ce point, nous sommes d'accord.

    Citation Envoyé par SQLPRO
    C'est pourquoi il édictât les 12 règles de Codd que tous les SGBD Relationnel devait respecter à la lettre.
    Ce ne sont pas les règles de fonctionnement qui définissent le modèle, mais bien l'organisation physique des données.
    Je relève deux règles qui me paraissent douteuses :
    --> la règle 8 de l'indépendance physiques des données.
    --> la règle 9 de l'indépendance logique.

    Si l'on s'arrête à la relation entre l'organisation des données que ce soit physique ou logique, et les applications qui vont les gérer, il est tout à fait possible de créer une interface à l'instar de ce que existe déjà dans le modèle OSI des réseaux.
    Si nous nommons couches basses, tout ce qui est physique et logique, et couches hautes tout ce qui est applicatif, nous pouvons nommer couche intermédiaire, tout ce qui va accéder aux données et les convertir d'une manière indépendante et normalisé afin d'être exploitées par les applications.
    De ce point de vue, il y a bien indépendance et donc les règles 8 & 9 sont respectées.

    Le problème repose sur la couche intermédiaire, que l'on nomme API (Application Programming Interface) et qui a pour conséquence de pénaliser les performances.

    Croire que cette indépendance existe réellement est une hérésie (dans le sens défini par Codd), car la performance des accès nécessite d'être au plus près de la machine.
    Or la transportabilité des applications, indépendamment du support physique (matériel) et logique a été résolu par la Couche d'abstraction matérielle des systèmes d'exploitations.

    Or en reprenant ces 12 règles, on s'aperçoit quelles peuvent s'appliquer aujourd'hui à beaucoup de SGBD même sans être relationnel.

    Et je ne voie nulle part une quelconque définition de ce que représente le modèle relationnel selon Codd.
    Dire que cela consiste à mettre en relation des informations entre elles, le modèle hiérarchique et réseau répond aussi à ce besoin.

    Quand jadis, j'avais posé la question, on m'avait répondu que l'information était indépendante de toute représentation physique et logique.
    Autrement dit, les données sont en vrac sans aucune relation entre elles. C'est le moteur du SGBD qui doit répondre à la demande logique.
    Sauf que pour des raisons de performances, les index ont été créés.

    Ce qui faisait la force du relationnel lors de la création par Codd, c'est-à-dire d'être indépendant du physique et du logique, n'est plus vraiment respecté aujourd'hui.
    Je ne suis pas très au courant de ce qui est dit entre les partisans du relationnel et les opposants.
    Si vous pouviez m'éclairer sur ce différend !

    Citation Envoyé par SQLPRO
    Donc, je maintient que MySQL est une vraie daube et je voie de plus en plus de clients qui ont sombré dans ce produit infâme qui sont bloqués et n'arrivent plus à en sortir...
    L'erreur n'est pas d'avoir choisi MySQl comme SGBD, mais de ne pas avoir su dimensionner correctement la base de données dès le départ.
    On n'utilise pas le même SGBD pour gérer quelques milliers (10^3 ou kilo) de lignes, par rapport à des billions de lignes (10^12 ou tera) ou des trillions de lignes (10^12 ou exa).

    Ne vous plaigniez pas, vous avez du boulot pour réparer les mauvais choix qui ont été faits.

    @+
    Si vous êtes de mon aide, vous pouvez cliquer sur .
    Mon site : http://www.jcz.fr

  2. #2
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    21 736
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

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

    Informations forums :
    Inscription : Mai 2002
    Messages : 21 736
    Points : 52 447
    Points
    52 447
    Billets dans le blog
    5
    Par défaut
    Citation Envoyé par Artemus24 Voir le message
    Quand je dis ... tout ce que vous me dites, c'est de me référer à la norme.
    Le langage SQL est une norme. Il est donc normal de s'y référer... Sinon, parlons d'autres chose, du macramé ou du sexe tantrique... Là y'a pas de norme !
    Maintenant si vous voulez inventer votre propre langage libre à vous !

    Le problème sur lequel vous passez vite est le fait que le NULL est traité comme une valeur dans la logique ternaire.
    Ben non... Encore une fois vous n'avez pas compris...
    Le NULL n'est pas une valeur, c'est justement un marqueur d'absence de valeur. C'est aussi d'ailleurs techniquement le cas. En effet il est impossible de "griller" une quelconque valeur arbitraire pour représenter le NULL dans les octets stockées pour les lignes de table. C'est pourquoi la nullité (ou non) d'une valeur de colonne est stockée généralement par un bit à côté de la valeur.
    En revanche UNKNOWN est une valeur qui n'est ni TRUE ni FALSE et qui survient lorsque l'expression d'un prédicat ne peut être évaluée ni à VRAI ni à FAUX (ce qui est la majorité des cas en présence du NULL, sauf quelque cas particulier spécifique comme IS NULL ou COALESCE).

    SQL est un langage de requête afin de manipuler les bases de données.
    Aucun rapport avec le modèle d'organisation des données de type hiérarchique, réseau ou encore relationnel.
    Sur ce point, nous sommes d'accord.
    Nous ne sommes absolument pas d'accord du tout !!! Encore une fois vous dites n'importe quoi et vous essayez même de me faire dire ce que je n'ai pas dit. Puisque vous êtes borné, je vous présente une copie de Wikipedia sur le langage SQL, dont vous verrez qu'il est conçu pour les bases de données relationnelles et uniquement pour ces dernières !
    Nom : SQLwikipedia.jpg
Affichages : 940
Taille : 99,8 Ko

    Donc il a bien tout à voir avec des bases dont le modèle est strictement relationnel et non pas hiérarchique, fichier plat ou réseau (on devrait d'ailleurs aujourd'hui dire "en graphe"), même si certains petits malins s'en donne à cœur joie pour le faire fonctionner sur ce genre de chose au risque de présenter des résultats faux, ce qui est le cas en particulier de MySQL !

    Je n'irais pas plus loin, car tout le reste est bien entendu faux puisque dès le départ vous vous êtes trompés !

    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/ * * * * *

  3. #3
    Expert éminent sénior Avatar de Artemus24
    Homme Profil pro
    Agent secret au service du président Ulysses S. Grant !
    Inscrit en
    Février 2011
    Messages
    6 346
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Agent secret au service du président Ulysses S. Grant !
    Secteur : Finance

    Informations forums :
    Inscription : Février 2011
    Messages : 6 346
    Points : 18 958
    Points
    18 958
    Par défaut
    Salut SQLPRO.

    Encore une fois, on ne se comprend pas du tout. Je pense de plus en plus que vous avez un problème de communication et de compréhension !

    Je prends votre exemple ci-après :
    Citation Envoyé par SQLPRO
    En revanche UNKNOWN est une valeur qui n'est ni TRUE ni FALSE et qui survient lorsque l'expression d'un prédicat ne peut être évaluée ni à VRAI ni à FAUX (ce qui est la majorité des cas en présence du NULL, sauf quelque cas particulier spécifique comme IS NULL ou COALESCE).
    Vous associez la valeur "UNKNOW" à la présence du NULL ! C'est vous qui le dite, pas moi.

    Et vous osez affirmer : "Le NULL n'est pas une valeur, c'est justement un marqueur d'absence de valeur.".
    Avez-vous compris ce que signifie ne pas être une valeur ? J'en doute !

    Je le répète car vous ne me comprenez pas, dans une logique ternaire en associant le "UNKNOW" à la présence du NULL, vous traiter le NULL comme une valeur.
    La seule façon logique de traiter cela est d'ignorer totalement la présence du NULL et donc de ne pas extraire la ligne !!!
    La logique ternaire est fausse et ne respecte pas le fait que le NULL soit un Marqueur.

    Pour être pleinement logique, ce sont les prédicats qui doivent restituer VRAI ou FAUX et seulement ça.
    Et par deux opérateurs distincts, faire la différence entre tester une valeur "where colonne = {valeur}" et tester le marqueur "where colonne IS NULL".

    Citation Envoyé par SQLPRO
    Nous ne sommes absolument pas d'accord du tout !!!
    En fait, vous n'êtes jamais d'accord sur rien ! Ça en dit long sur votre ouverture d'esprit.

    Le langage SQL est un langage standardisé qui n'a aucun rapport ni avec la base de données, ni avec un SGBD particulier.
    Vous confondez le fait que si un SGBD relationnel utilise couramment le langage SQL, que ce langage soit exclusivement utilisé pour le relationnel.
    Autrement dit, on peut utiliser le langage SQL pour un SGBD qui ne soit pas relationnel.

    Citation Envoyé par SQLPRO
    Je n'irais pas plus loin, car tout le reste est bien entendu faux puisque dès le départ vous vous êtes trompés !
    En sommes, vous êtes à court d'arguments ! Je commence à avoir de sérieux doute à votre sujet.
    Et votre opinion, c'est de faire un copier/coller de ce que l'on trouve sur internet.

    Et non, moi je ne mets pas des "-1" dès que je ne suis pas d'accord avec mon interlocuteur.

    @+
    Si vous êtes de mon aide, vous pouvez cliquer sur .
    Mon site : http://www.jcz.fr

  4. #4
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    21 736
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

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

    Informations forums :
    Inscription : Mai 2002
    Messages : 21 736
    Points : 52 447
    Points
    52 447
    Billets dans le blog
    5
    Par défaut
    Permettez moi de vous dire que vous êtes vraiment ... NULL !

    Citation Envoyé par Artemus24 Voir le message
    Je le répète car vous ne me comprenez pas, dans une logique ternaire en associant le "UNKNOW" à la présence du NULL, vous traiter le NULL comme une valeur.
    La seule façon logique de traiter cela est d'ignorer totalement la présence du NULL et donc de ne pas extraire la ligne !!!
    Il suffit de regarder les tables de vérité de la logique ternaire pour vous prouver le contraire car :
    valeur1 = NULL OR valeur2 = valeur2
    https://fr.wikipedia.org/wiki/Logique_ternaire
    dans un prédicat WHERE retiendra bien la ligne, malgré la présence du NULL !
    La logique ternaire est fausse et ne respecte pas le fait que le NULL soit un Marqueur.
    Bien sur que si ! Encore une fois lisez les tables de vérité de la logique ternaire !
    Pour être pleinement logique, ce sont les prédicats qui doivent restituer VRAI ou FAUX et seulement ça.
    Ben non, comme son nom l'indique, logique ternaire veut dire 3 valeurs... C'est justement pas la logique binaire souvent appelée booléenne. Il en existe d'autres 'quaternaire par exemple) toutes d'ailleurs ont été formalisées par les travaux du mathématicien Heyting dans les années 50
    Pour info la logique relationnelle devait avoir encore plus de marqueurs logiques comme +infini, -infini, futur et passé... Mais là Codd s'est fâché car cela devenait très compliqué à metttre en oeuvre...
    Et par deux opérateurs distincts, faire la différence entre tester une valeur "where colonne = {valeur}" et tester le marqueur "where colonne IS NULL".


    En fait, vous n'êtes jamais d'accord sur rien ! Ça en dit long sur votre ouverture d'esprit.

    Le langage SQL est un langage standardisé qui n'a aucun rapport ni avec la base de données, ni avec un SGBD particulier.
    Vous confondez le fait que si un SGBD relationnel utilise couramment le langage SQL, que ce langage soit exclusivement utilisé pour le relationnel.
    Ben là vous êtes aveugle, car je viens de vous prouver le contraire avec l'article de wikipédia. Au moins lisez le

    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/ * * * * *

  5. #5
    Modérateur
    Avatar de escartefigue
    Homme Profil pro
    bourreau
    Inscrit en
    Mars 2010
    Messages
    10 088
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loir et Cher (Centre)

    Informations professionnelles :
    Activité : bourreau
    Secteur : Finance

    Informations forums :
    Inscription : Mars 2010
    Messages : 10 088
    Points : 38 393
    Points
    38 393
    Billets dans le blog
    9
    Par défaut
    Citation Envoyé par Artemus24 Voir le message
    SQL est un langage de requête afin de manipuler les bases de données.
    Aucun rapport avec le modèle d'organisation des données de type hiérarchique, réseau ou encore relationnel.
    Sur ce point, nous sommes d'accord.
    Sauf erreur de ma part, le langage SQL appliqué sur les bases non relationnelles, n'est qu'un ersatz faisant appel à des routines internes qui transforment le SQL en langage propriétaire, bien évidemment au détriment des performances, et avec de nombreuses limitations
    Je ne vois d'ailleurs pas comment il pourrait en être autrement dans la mesure où SQL applique la théorie des ensembles propres au SGBDR (jointures, intersections, etc... qui n'ont pas de sens dans les SGBD qui fonctionnent par pointeurs)
    Si toutefois il existe des exceptions, je serai très curieux d'apprendre lesquelles et aussi comment elles fonctionnent

  6. #6
    Expert éminent sénior Avatar de Artemus24
    Homme Profil pro
    Agent secret au service du président Ulysses S. Grant !
    Inscrit en
    Février 2011
    Messages
    6 346
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Agent secret au service du président Ulysses S. Grant !
    Secteur : Finance

    Informations forums :
    Inscription : Février 2011
    Messages : 6 346
    Points : 18 958
    Points
    18 958
    Par défaut
    Salut Escartefigue.

    Citation Envoyé par escartefigue Voir le message
    Sauf erreur de ma part, le langage SQL appliqué sur les bases non relationnelles, n'est qu'un ersatz faisant appel à des routines internes qui transforment le SQL en langage propriétaire, bien évidemment au détriment des performances, et avec de nombreuses limitations
    Je ne vois d'ailleurs pas comment il pourrait en être autrement dans la mesure où SQL applique la théorie des ensembles propres au SGBDR (jointures, intersections, etc... qui n'ont pas de sens dans les SGBD qui fonctionnent par pointeurs)
    Si toutefois il existe des exceptions, je serai très curieux d'apprendre lesquelles et aussi comment elles fonctionnent
    Donc vous reconnaissez qu'il est possible d'utiliser le langage SQL pour autre chose que du relationnel !

    Même aujourd'hui, le relationnel fonctionne aussi avec des pointeurs (ou index), donc je ne voie pas en quoi cela serait impossible.
    Mais à l'inverse du relationnel, tout ne serait pas possible.
    Est-ce que cela aurait encore un sens de faire une intersection si la modélisation ne la pas prévue ?

    @+
    Si vous êtes de mon aide, vous pouvez cliquer sur .
    Mon site : http://www.jcz.fr

  7. #7
    Modérateur
    Avatar de escartefigue
    Homme Profil pro
    bourreau
    Inscrit en
    Mars 2010
    Messages
    10 088
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loir et Cher (Centre)

    Informations professionnelles :
    Activité : bourreau
    Secteur : Finance

    Informations forums :
    Inscription : Mars 2010
    Messages : 10 088
    Points : 38 393
    Points
    38 393
    Billets dans le blog
    9
    Par défaut
    Citation Envoyé par Artemus24 Voir le message
    Donc vous reconnaissez qu'il est possible d'utiliser le langage SQL pour autre chose que du relationnel !
    Pas directement, en tout cas pas à ma connaissance, et encore une fois je ne vois pas comment ce serait possible.
    Ce dont je parle ce sont les artifices qui permettent à partir de requêtes écrites en SQL, de passer par une étape de traduction qui produit un langage propriétaire qui lui même accède à la base de données non relationnelle.
    Ce type de fonctionnement était proposé avec ideal-Datacom pour accéder à des bases non relationnelles sur Mainframe. Cette solution était vendue comme une sorte de migration en douceur vers le relationnel, mais les limites et les performances désastreuses en ont fortement limité la diffusion.

    Citation Envoyé par Artemus24 Voir le message
    Même aujourd'hui, le relationnel fonctionne aussi avec des pointeurs (ou index), donc je ne voie pas en quoi cela serait impossible.
    Il est vrai que certains SGBD relationnels proposent depuis peu des colonnes de type pointeur, j'avoue n'en avoir toujours pas compris l'intérêt.
    Mais si dans certains SGBDR, l'usage d'un pointeur est possible, ce n'est qu'une option très marginale, alors que dans les SGBD hiérarchiques ou réseau, c'est la seule façon d'accéder à une ligne précise de la base de données. Il s'agit donc d'une approche conceptuellement fondamentalement différente.

    Citation Envoyé par Artemus24 Voir le message
    Est-ce que cela aurait encore un sens de faire une intersection si la modélisation ne la pas prévue ?
    Là je ne comprends pas ?

  8. #8
    Expert éminent sénior Avatar de Artemus24
    Homme Profil pro
    Agent secret au service du président Ulysses S. Grant !
    Inscrit en
    Février 2011
    Messages
    6 346
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Agent secret au service du président Ulysses S. Grant !
    Secteur : Finance

    Informations forums :
    Inscription : Février 2011
    Messages : 6 346
    Points : 18 958
    Points
    18 958
    Par défaut
    Salut Escartefigue.

    Tout ce dont je parle au sujet du langage SQL, c'est qu'il peut s'utiliser indifféremment de l'organisation des données.
    Maintenant, je reconnais qu'il peut être limité dans ce qu'il peut faire dans une organisation non relationnelle, et avoir quelques problèmes de performances.
    Cela peut facilement se comprendre puisque à l'origine, le langage SQL est fait pour le relationnel.

    Citation Envoyé par Escartefigue
    Ce type de fonctionnement était proposé avec ideal-Datacom pour accéder à des bases non relationnelles sur Mainframe.
    Quand je faisais du Focus (Informations Builders) sur Mainframe IBM, il était possible dans un fichier de type master (si j'ai un bon souvenir) de faire le descriptif d'une base (qui n'était pas celle utilisé par focus), et de faire des accès comme s'il s'agissait d'une base focus.
    C'est cela que j'avais à l'esprit en parlant du langage SQL. Maintenant, j'ignore totalement s'il est utilisé dans un SGBD non relationnel.
    Mais à bien refléchir, je ne voie pas en quoi, cela serait impossible.

    Et comme vous le dites, il existe parfois des solutions que je qualifie de batardes où d'un coté, on veut utiliser un langage comme le SQL et de l'autre coté, ne pas avoir une base relationnelle.
    Il est en principe prévu de migrer la base de données vers du relationnel, mais pour des raisons autres, cette situation batarde peut demeurer en l'état.
    Ce sont des situations hétérogènes que l'on peut rencontrer quand on veut faire cohéxister des bases ayant différentes origines au sein d'une même appliction.

    Citation Envoyé par Escartefigue
    Il est vrai que certains SGBD relationnels proposent depuis peu des colonnes de type pointeur, j'avoue n'en avoir toujours pas compris l'intérêt.
    Vous voulez certainement parler du nosql.
    Je suppose que par pointeur, vous voulez parler de l'organisation de type réseau, comme en Bull avec IDS II ou Socrate développé à l'université Joseph-Fourier à Grenoble.
    Il est vrai que cette organisation est bien plus performante que le relationnel, qui lui garde toute sa souplesse car l'idée sous-jacente est bien la théorie des ensembles.

    Citation Envoyé par Escartefigue
    Il s'agit donc d'une approche conceptuellement fondamentalement différente.
    C'est pourquoi, je considère que l'organisation relationnel est en faite sans aucune organisation à proprement parlé, à l'inverse de l'organisation hiérarchique qui n'est qu'un cas particulier de l'organisation réseau.
    A l'origine, le relationnel était juste un ensemble de lignes de même structure dans une table.
    C'est le moteur du SGBD qui devrait faire les opérations ensemblistes, mais cela posant un énorme problème de performance.

    On peut remarquer que dans l'organisation réseau, cela nomme une collection que l'on représente comme un collier de perle, ou chaque perle est un élément de la collection.
    Avec un pointeur début, un pointeur fin, un pointeur avant, un pointeur arrière, et aussi un pointeur parent et un pointeur enfant. Oui, je sais, cela fait beaucoup de pointeurs.
    En plus de ces pointeurs, il a été ajouté aussi des index, pour accéder autrement à l'éléments et des clefs afin d'accéder directement à la collection sans passer par les parents.

    Ayant utilisé pendant plusieurs années les bases IDS II sous Bull, j'ai bien aimé cette façon d'organiser les données entre elles.
    Il y a juste un très léger problème, c'est la rigidité du modèle des données.
    Si le modèle ne prévoit pas telle ou telle chose, et bien, on ne peut pas le faire, à l'inverse du relationnel où il n'y a aucune contrainte d'accès sur les données.

    Dans l'organisation relationnelle, toutes les notions d'index, de clef étrangères ... ont été rajoutés pour des questions de performances, par emprunt à l'organisation reseau.
    Ce qui fait que ces ajouts ont tendance à rapprocher l'organisation relationnelle de plus en plus vers l'organisation réseau, uniquement pour des raisons de performances.

    Par contre, hormis l'approche ensembliste, je ne voie pas en quoi le relationnel est mieux que le réseau.
    Je pense qu'à terme, l'organisation relationnelle va disparaitre pour être remplacée par une version hybride relationnelle - réseau.
    Voire même dans certains cas, cela sera que du réseau.
    J'ai tendance à croire que l'on a enterré un peu trop rapidement l'organisation réseau et qu'aujourd'hui il fait son apparition sous une autre forme dite hybride.

    Citation Envoyé par Escartefigue
    Là je ne comprends pas ?
    Dans l'organisation réseau, les différents records (les tables) sont liés par des pointeurs (des chemins d'accès).
    Si l'on veut mettre en relation deux records dans l'organisation réseau, et bien, il faut dès le départ le prévoir.
    A l'inverse dans l'organisation relationnelle, il n'est pas nécessaire de prévoire la mise en relation car c'est le moteur du SGBDR qui va gérer cela.
    D'où la question que l'on peut se poser, sur l'utilité de mettre en relation deux records (ou deux tables) si le modèle des données ne le prévoit pas !
    C'est ce que j'ai voulu dire.

    Et par voie de conséquence, le réseau est bien supérieur au relationnel pour la performance.
    Aujourd'hui, nous sommes dans un élan vers le tout relationnel, parce que c'est simple à l'usage.
    Mais on constate de plus en plus, des problèmes de performances pour gérer de très grosses volumétries.

    @+
    Si vous êtes de mon aide, vous pouvez cliquer sur .
    Mon site : http://www.jcz.fr

  9. #9
    Modérateur
    Avatar de escartefigue
    Homme Profil pro
    bourreau
    Inscrit en
    Mars 2010
    Messages
    10 088
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loir et Cher (Centre)

    Informations professionnelles :
    Activité : bourreau
    Secteur : Finance

    Informations forums :
    Inscription : Mars 2010
    Messages : 10 088
    Points : 38 393
    Points
    38 393
    Billets dans le blog
    9
    Par défaut
    Citation Envoyé par Artemus24 Voir le message
    Et par voie de conséquence, le réseau est bien supérieur au relationnel pour la performance.
    Aujourd'hui, nous sommes dans un élan vers le tout relationnel, parce que c'est simple à l'usage.
    Mais on constate de plus en plus, des problèmes de performances pour gérer de très grosses volumétries.
    C'est très difficile de comparer l'un et l'autre car les machines qui supportaient les bases réseau, n'avaient ni les processeurs, ni les disques, ni la RAM, ni le réseau que nous connaissons aujourd'hui. Les progrès matériels sont énormes depuis les années 70-80 où les bases réseau et hiérarchiques étaient la règle.
    Cela étant, j'ai travaillé dans les années 80 sur bases réseau (Total de Cincom) et hiérarchiques (DL1 d'IBM), et les performances n'étaient pas toujours optimales, voire parfois très dégradées et ce malgré des volumes d'information très modestes et des fonctionnalités infiniment inférieures à celles des SGBDR.

  10. #10
    Expert éminent sénior Avatar de Artemus24
    Homme Profil pro
    Agent secret au service du président Ulysses S. Grant !
    Inscrit en
    Février 2011
    Messages
    6 346
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Agent secret au service du président Ulysses S. Grant !
    Secteur : Finance

    Informations forums :
    Inscription : Février 2011
    Messages : 6 346
    Points : 18 958
    Points
    18 958
    Par défaut
    Salut Escartefigue.

    Citation Envoyé par Escartefigue
    C'est très difficile de comparer l'un et l'autre car les machines qui supportaient les bases réseau, n'avaient ni les processeurs, ni les disques, ni la RAM, ni le réseau que nous connaissons aujourd'hui.
    Je suis d'accord avec vous sur l'aspect matériel.

    Citation Envoyé par Escartefigue
    Les progrès matériels sont énormes depuis les années 70-80 où les bases réseau et hiérarchiques étaient la règle.
    Oui sauf que le hiérarchique, c'est plutôt les années 60.

    Citation Envoyé par Escartefigue
    j'ai travaillé dans les années 80 sur bases réseau (Total de Cincom) et hiérarchiques (DL1 d'IBM), et les performances n'étaient pas toujours optimales
    Pour le DL1 que j'ai aussi utilisé, je confirme que c'est vraiment pas du tout performant.
    A l'inverse, sous BULL, IDS II c'est vraiment un petit bijou pour l'époque ! L'un des meilleurs SGBD des années 70-80 que j'ai pratiqué.

    Citation Envoyé par Escartefigue
    voire parfois très dégradées et ce malgré des volumes d'information très modestes et des fonctionnalités infiniment inférieures à celles des SGBDR.
    Pour le réseau, encore fait-il parfaitement maitriser la modélisation.
    Ce qui n'est pas toujours évident, surtout quand des ajouts fonctionnels, non prévu dès le départ, viennent remmettre en cause le modèle des données.

    Pour revenir sur les 12 règles de Codd, je ne voie pas en quoi est-ce une définition d'un SGBD relationnel ?

    La règle 2 est floue car la notion de clef primaire n'existe pas dans l'organisation réseau.
    Je pense que c'est une autre façon de définir un accès directe à la donnée ou encore la donnée est accessible par une adresse unique.

    La règle 4 definie la meta modélisation des données dans le SGBD, notion qui n'existe pas en réseau.

    Ce sont les règles 8 (indépendance physique) et 9 (indépendance logique) qui m'ont fait réagir.
    Actuellement pour des raisons de performances, ces deux règles ne sont pas du tout respectés et ce pour n'importe quel SGBD.
    A l'instar du langage Pascal et de son pseudo code P, l'idée est de créer une couche intermédiaire pouvant résoudre d'une part les spécificités proprent au matériel entre autre le codage physique des données, comme par exemple l'ASCII ou l'EBCDIC et d'autre part changer le modèle des données utilisés, entre autre la structure des données.
    Cette couche intermédiaire serait comme des API venant redéfinir les primitives systèmes et en randant la partie applicative transportable sur n'importe quel système.
    Aujourd'hui, ce rôle est celui du système d'exploitation, ce qui fait que dans la réalité, chaque SGBD est écrit pour ce système d'exploitation.
    Du coup, la définition de Codd de l'indépendance physique et logique n'est plus vraiment respectée.

    Vu que SQLPRO n'a pas su me répondre, sauf en disant que je suis NULL, j'aimerai connaitre votre opinion à ce sujet.

    @+
    Si vous êtes de mon aide, vous pouvez cliquer sur .
    Mon site : http://www.jcz.fr

  11. #11
    Modérateur
    Avatar de escartefigue
    Homme Profil pro
    bourreau
    Inscrit en
    Mars 2010
    Messages
    10 088
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loir et Cher (Centre)

    Informations professionnelles :
    Activité : bourreau
    Secteur : Finance

    Informations forums :
    Inscription : Mars 2010
    Messages : 10 088
    Points : 38 393
    Points
    38 393
    Billets dans le blog
    9
    Par défaut
    Le lien ci-dessous répond en partie à ces interrogations
    https://sgbd.developpez.com/actu/873...el-de-donnees/

    Le tableau date un peu, car la version DB2 est très ancienne (les versions plus récentes sont conformes), mais on voit clairement que les bases DATACOM et IDMS/R ne sont pas conformes du tout

    FSMRel, l'auteur de l'article, ne peut pas être suspect d'amateurisme ni d'approximation

    Au sujet des dates : les SGBD hiérarchiques étaient encore très répandus dans les années 80, et des poches de résistance ont survécu jusque dans les années 2000 à ma connaissance (expérience dans le monde de l'industrie, de la banque et de la retraite complémentaire)
    Pour l'anecdote : je suis intervenu chez un client qui n'a remplacé ses dernières bases DL1 qu'en 2013 !

  12. #12
    Expert éminent sénior Avatar de Artemus24
    Homme Profil pro
    Agent secret au service du président Ulysses S. Grant !
    Inscrit en
    Février 2011
    Messages
    6 346
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Agent secret au service du président Ulysses S. Grant !
    Secteur : Finance

    Informations forums :
    Inscription : Février 2011
    Messages : 6 346
    Points : 18 958
    Points
    18 958
    Par défaut
    Salut Escartefigue.

    Citation Envoyé par Escartefigue
    FSMRel, l'auteur de l'article, ne peut pas être suspect d'amateurisme ni d'approximation
    Oh que non !

    Le tableau date de 30 ans, donc 2015 (article écrit par FSMRel) - 30 ans = 1985.
    Si je me réfères à l'histoire de DB2, la version DB2 Version 1 Release 1 est apparu le 2 avril 1985.
    S'agit-il de cette version qui a été testé par Codd ? Soit une note de 7/12.

    L'interprétation de certaines règles portent à caution.
    Je prends la règle 8 (indépendance physique des données) qui pour DB2 a été marqué comme Correcte. Voici ce que dit ou interprète FSMRel :
    Citation Envoyé par FSMRel
    8. Physical data independence : Le SGBD doit garantir une totale séparation entre les aspects logiques, sémantiques d’une part, et d’autre part les aspects physiques, par conséquent la résolution des problèmes de performance
    Or si je prends cette autre définition :
    Citation Envoyé par Wikipedia
    Règle 8 Indépendance physique : Les modifications au niveau physique (comment les données sont stockées, si dans les rangées ou les listes liées etc...) ne nécessitent pas un changement d'une application basée sur les structures.
    le sens de cette règle 8 est toute autre !

    L'indépendance physique de la représentation des données, c'est le vieux problème du passage de la machine à l'humain.
    Prenons la différence entre IBM (EBCDIC) et Bull (ASCII) ou la codification poids forts et poids faibles sont inversés.
    D'où la nécessite d'interpréter la codification afin qu'elle soit compréhensible par l'homme.
    Et pour palier ce genre d'inconvénient, créer une couche intermédiaire qui va résoudre ce problème.

    Prenons aussi la règle 9 qui a été marqué pour DB2 à "par.", c'est-à-dire à faux :
    Citation Envoyé par FSMRel
    9. Logical data independence : Un changement de structure des données effectué sans qu’il y ait perte de données (lossless) doit être possible, de façon transparente pour les applications.
    et ce que dit wikipedia :
    Citation Envoyé par Wikipedia
    Règle 9 Indépendance logique : Les changements au niveau logique (tables, colonnes, rangées, etc) ne doivent pas exiger un changement dans l'application basée sur les structures. L'indépendance de données logiques est plus difficile à atteindre que l'indépendance de donnée physique.
    Pour résoudre ce problème, il faut utiliser la notion de masque logique.
    En gros, dans une ligne, tu ranges chaque donnée avec un ensemble d'outils qui vont caractériser la structure.
    Par exemple, un pointeur pour indiquer ou se trouve la prochaine colonne, le type de structure, la longueur variable de la colonne dans le cas du varchar, le NULL ...
    Et en plus, en début de ligne, il y a aussi d'autres caractéristiques, comme l'identifiant de la ligne propre à VSAM Linear Data Set.

    On comprends alors pourquoi pour atteindre la cinquième colonne, nous sommes obligés de de faire quatre déplacement dans la ligne.
    D'où l'intérêt de mettre les varchar en fin de ligne à cause des problèmes de réorganisation de la ligne, ce qui peut occasionner des problèmes dans la capacité de la ligne.
    Autrement dit, l'ordre n'a plus aucun importance car la structure de la donnée est stockée dans la ligne.

    Cet aspect là est résolu par IBM avec cette notion que tu dois nécessairement connaitre : la base et le déplacement.
    Vu que j'ai fait pas mal d'assembleur IBM 370 dans ma jeunesse, je sais que certains aspects physiques sont totalement méconnus par les développeurs.
    En ce qui concerne BULL, je n'en sais rien car je n'ai jamais fait d'assembleur.

    Pour l'anecdote aussi, j'ai eu un entretien avec une société basée à Paris qui faisait du routage de journaux (la presse) et autres périodiques pour la France entière.
    Toute leur application était écrire en assembleur IBM 370 !!! D'où la difficulté de trouver encore des gens qui connaissent l'assembleur dans les années 90.
    J'ai préféré me diriger vers l'administration DB2 car bien plus enrichissant comme activité !

    @+
    Si vous êtes de mon aide, vous pouvez cliquer sur .
    Mon site : http://www.jcz.fr

  13. #13
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    21 736
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

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

    Informations forums :
    Inscription : Mai 2002
    Messages : 21 736
    Points : 52 447
    Points
    52 447
    Billets dans le blog
    5
    Par défaut
    Citation Envoyé par Artemus24 Voir le message
    Pour revenir sur les 12 règles de Codd, je ne voie pas en quoi est-ce une définition d'un SGBD relationnel ?
    Vous avez encore une fois et décidément c'est une habitude (ou une mauvaise foi) lue de travers... Ce n'est pas une définition. Mais c'est ce qui permet de savoir si un SGBD est relationnel ou pas. Si un SGBD se prétendant être relationnel enfreint l'une de ces règles, alors il ne l'est pas.

    La règle 2 est floue car la notion de clef primaire n'existe pas dans l'organisation réseau.
    Elle n'est pas flou du tout. L'organisation de bases en réseau n'est strictement pas du tout relationnelle !

    Je pense que c'est une autre façon de définir un accès directe à la donnée ou encore la donnée est accessible par une adresse unique.
    Visiblement vous n'avez jamais compris les fondement du relationnel ! Les SGBDR relationnels n'accèdent pas par des adresses ou des pointeurs, mais par des valeurs et rien d'autre !

    La règle 4 definie la meta modélisation des données dans le SGBD, notion qui n'existe pas en réseau.
    Donc, l'organisation de bases en réseau n'est strictement pas du tout relationnelle, une fois de plus !

    Ce sont les règles 8 (indépendance physique) et 9 (indépendance logique) qui m'ont fait réagir.
    Actuellement pour des raisons de performances, ces deux règles ne sont pas du tout respectés et ce pour n'importe quel SGBD.
    Et bien, si, par exemple dans SQL Server c'est parfaitement respecté !

    Je ne eut pas répondre systématiquement à toutes vos élucubrations, toutes plus fantaisistes les une que les autres... Je ne suis pas à la retraite et j'ai un métier.... Le mien consiste à aider les autres à faire mieux leur boulot avec des SGBD Relationnels et cela depuis 1988 (et avec d'autres systèmes encore avant).

    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/ * * * * *

  14. #14
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    21 736
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

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

    Informations forums :
    Inscription : Mai 2002
    Messages : 21 736
    Points : 52 447
    Points
    52 447
    Billets dans le blog
    5
    Par défaut
    Citation Envoyé par Artemus24 Voir le message
    S

    Or si je prends cette autre définition :

    le sens de cette règle 8 est toute autre !
    La traduction WIKIPEDIA est approximative en sus d'être vérolée et donc fausse. Pour ma part, j'ai reproduit les traductions du livre de Connoly et al. qui sont des canadiens maitrisant les deux langues

    L'indépendance physique de la représentation des données, c'est le vieux problème du passage de la machine à l'humain.
    Prenons la différence entre IBM (EBCDIC) et Bull (ASCII) ou la codification poids forts et poids faibles sont inversés.
    Cette comparaison est hautement stupide, car la notion de jeu de caractères ne doit absolument pas intervenir au niveau logique ! Les SGBD doivent travailler sur des collations et nom sur des jeux de caractères, faute de quoi ils perdent leu indépendance logique ! C'est d'ailleurs pour cela que je me bat contre cette foutue merde de MySQmerde et son UTF-8 à la c...

    tout le reste de votre raisonnement est aussi faux puisque vous partez sur des bases fausses en étant persuadé qu'elles sont vraies !

    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/ * * * * *

  15. #15
    Membre du Club
    Inscrit en
    Mai 2010
    Messages
    27
    Détails du profil
    Informations forums :
    Inscription : Mai 2010
    Messages : 27
    Points : 50
    Points
    50
    Par défaut
    Salut,

    Allez, au passage j'en remet une couche, juste pour le plaisir de provoquer le roi des provocateurs! (j'ai nommé : SQLpro!)

    encodage & collation :
    comme d'habitude vous rejetez tout ce qui ne correspond pas à votre logique.
    si j'ai bien compris, SQLserveur définit indépendamment l'encodage et la collation. Donc lorsqu'on définit la collation, l'ordre peut être influencé par l'encodage.
    he bien je préfère l'approche de Mysql, plus simple, où l'on choisit à l'avance le couple encodage/collation.
    où est la stupidité ou l'hérésie là dedans?

    la gestion du "NULL"...
    tout d'abord, petite explication à Artemus24, car tout ça n'était pas clair! dans votre débat on confond la "valeur" ternaire, et la "valeur" représentée par le pool de bits ou de trits.
    donc pour résumer :
    en logique ternaire, les valeurs sont TRUE FALSE et UNKNOWN. c'est tout.
    mais nos systèmes de stockages sont binaires. donc pour pouvoir faire des opérations ternaires, on a inventé le marqueur "NULL".
    (si le stockage était ternaire, on aurait pas besoin du NULL, il suffirait que les trits soient à "UNKNOWN" pour que la valeur représentée soit UNKNOWN! et on ferait WHERE monchamp IS UNKNOWN et pas WHERE monchamp IS NULL )

    @SQLpro : celà nous amène à la séparation logique physique...
    on a donc créé une notion appartenant à la logique SQL (le NULL), pour s'adapter à une contrainte physique (le stockage binaire)........

    HA ELLE EST BELLE LA SEPARATION LOGIQUE / PHYSIQUE!!!!
    depuis des années que vous me "gonflez" avec cette séparation logique/physique...

    et tiens, pour enfoncer le clou...
    vos certitudes sur la mauvaise gestion du NULL par Mysql n'est que le fruit de votre incompréhension des languages à typage dynamique!
    oui, un système à typage dynamique vous permettra de faire une opération mathématique à partir de strings. Mais si vous ne savez pas comment sont convertis les strings en float, c'est sûr que vous pouvez être surpris par le résultat!
    (je me réfère à un des exemples que vous aviez pris il y a longtemps pour "démontrer" la mauvaise gestion des NULL par Mysql)

    Bon, sur ce... je part en courant car je sent que je vais me faire insulter!

  16. #16
    Expert éminent sénior Avatar de Artemus24
    Homme Profil pro
    Agent secret au service du président Ulysses S. Grant !
    Inscrit en
    Février 2011
    Messages
    6 346
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Agent secret au service du président Ulysses S. Grant !
    Secteur : Finance

    Informations forums :
    Inscription : Février 2011
    Messages : 6 346
    Points : 18 958
    Points
    18 958
    Par défaut
    Salut Kiki.

    Citation Envoyé par Kiki
    en logique ternaire, les valeurs sont TRUE FALSE et UNKNOWN. c'est tout.
    Je ne dis pas le contraire.

    Citation Envoyé par Kiki
    mais nos systèmes de stockages sont binaires. donc pour pouvoir faire des opérations ternaires, on a inventé le marqueur "NULL".
    Quel est le rapport avec le stockage ??? Aucun !
    Il s'agit d'être cohérent, surtout quand on fait de la logique. Vous faites la même erreur que tout le monde.
    Le NULL n'est pas une valeur et ne doit pas être traité en tant que telle, que ce soit dans une logique binaire ou ternaire.

    Si vous avez besoin de tester la (non) présence d'une valeur, il existe l'opérateur (is not null) "is null" et cela suffit largement à une logique binaire.
    Encore que dans une condition logique, le test se rapporte à une valeur et non à sa non présence.

    Si la colonne est à NULL (donc non renseignée) il suffit alors de l'ignorer.

    Citation Envoyé par Kiki
    si le stockage était ternaire, on aurait pas besoin du NULL
    Non, vous n'avez pas compris que le UNKNOW est une valeur, tandis que le NULL n'en est pas une.

    Prenons l'exemple que le VRAI corresponde à un MAX et le FAUX à un MIN.
    En toute logique le UNKNOW est ni un MAX, ni un MIN, mais une valeur qui existe.
    Disons que le UNKNOW est un état intermédiaire avant de basculer vers le MIN ou le MAX.
    Tandis que le NULL, c'est pas un état intermédiaire, c'est autre chose, disons une absence d'état.
    J'insiste lourdement pour dire qu'une absence de valeur n'est pas une valeur en soi.

    Nous nous retrouvons avec le UNKNOW dans un problème d'indécidabilité, qui n'a pas lieu d'être surtout dans le cas de la théorie des ensembles où nous devons toujours être prédictible.
    D'ailleurs, ne nomme-t-on pas une condition, un prédicat ? Et ce prédicat est une propriété.
    En gros, la logique ternaire n'apporte rien de plus, sinon à compliquer à outrance, vis-à-vis de la logique binaire.

    Et si vous désirez donner une sens à votre NULL, autant ne pas l'utiliser et lui trouver une valeur de substitution, si vous n'avez pas le choix.

    Je vois, dans le cas des dates, des personnes mettre NULL pour indiquer que c'est la plus petite date.
    Alors qu'en mettant '1970-01-01', la plus petite valeur autorisée, et n'entrant pas dans votre domaine de définition, vous signifiez un sens particulier à cette colonne, qui est renseignée avec une valeur et donc traitable par la logique binaire.

    Dans une chaîne de caractère, mettre vide n'est pas non plus une erreur.

    Il y a juste un léger problème avec le numérique car on ne sait pas faire la distinction entre zéro comme valeur, et zéro pour indiquer l'absence de valeur. C'est dans ce cas là, que nous pouvons utiliser le NULL.

    Mais utiliser une bases de données où vous ne renseignez pas le contenu des colonnes est un comportement plus que bizarre.
    Je pense sans trop me tromper, que s'il existe des colonnes à NULL, c'est que vous avez une erreur de conception dans votre modélisation.
    La meilleure façon de faire est de ne pas créer des lignes, tant que toutes les colonnes ne sont pas renseignées.

    Moins vous utiliserez le NULL dans les bases de données et mieux cela sera !

    Citation Envoyé par Kiki
    depuis des années que vous me "gonflez" avec cette séparation logique/physique...
    Cette séparation logique/physique existe bien, mais SQLPRO ne veut pas reconnaître qu'il existe une couche intermédiaire qui permet de passer de l'un à l'autre.
    Autant SQLPRO a une excellente connaissance de la manipulation des bases de données, autant il n'y connait rien coté système.
    Mais cela peut se comprendre car le but du jeu est de gérer des données dans un SGBD et non de savoir comment il fonctionne réellement.

    Pour illustrer mon propos, on ne demande pas à quelqu'un, lorsqu'il passe son permis de conduire de connaitre le fonctionnement du moteur à quatre temps.
    Surtout si la voiture qu'il va conduire est électrique !

    Citation Envoyé par Kiki
    vos certitudes sur la mauvaise gestion du NULL par Mysql n'est que le fruit de votre incompréhension des langages à typage dynamique!
    Avec le NULL, on doit tester la colonne et rien d'autre. En testant la colonne, on sait si elle est renseignée ou pas.
    Mais tester une valeur, c'est du n'importe quoi car cela provient justement de l'introduction de la logique ternaire.
    Et je le rappelle encore une fois, le NULL n'est pas une valeur mais un marqueur pour indiquer si la colonne contient une valeur ou pas.

    @+
    Si vous êtes de mon aide, vous pouvez cliquer sur .
    Mon site : http://www.jcz.fr

  17. #17
    Membre du Club
    Inscrit en
    Mai 2010
    Messages
    27
    Détails du profil
    Informations forums :
    Inscription : Mai 2010
    Messages : 27
    Points : 50
    Points
    50
    Par défaut
    ok je commence à comprendre ce qui vous choque avec le NULL, et je comprend aussi pourquoi vous ne me comprenez pas...

    c'est parce que j'ai l'habitude de Mysql et de son typage dynamique, et moi ça ne me choque pas de comparer un INT à un BOOL : SELECT 5 IS TRUE -> 0+1+0+1=1 -> TRUE
    donc ce que je voulais dire c'est qu'avec un stockage ternaire, on pourrait aussi comparer avec UNKNOWN : SELECT mon_champ_unknown IS UNKNOWN -> U+U+U+U=U -> TRUE
    mais avec du Binaire, puisqu'on ne peut pas "griller" une valeur arbitraire, on rajoute un bit pour pouvoir comparer avec UNKNOWN. donc dans le système de stockage, on a bien un bit avec une valeur 0 ou 1 pour représenter UNKNOWN ou NOT UNKNOWN

    c'est pour ça qu'à mes yeux UNKNOWN et NULL sont indisociables : NULL est une "bidouille" pour pouvoir faire des comparaisons ternaires.

    non?

  18. #18
    Membre du Club
    Inscrit en
    Mai 2010
    Messages
    27
    Détails du profil
    Informations forums :
    Inscription : Mai 2010
    Messages : 27
    Points : 50
    Points
    50
    Par défaut
    et comme je craint de ne pas avoir choisi le bon exemple avec mon typage dynamique...
    prenons une addition : 1+1=2
    la calcul binaire est 0001+0001=0010
    en ternaire, on pourrait avoir 0001+UUUU+0001=0010 les UNKNOWN sont bien "ignorés".

    donc pour moi ce qu'on veut simuler avec le marqueur NULL, c'est un équivalent de "tous les trits à UNKNOWN"

    d'ailleurs,

    SELECT NULL AND TRUE -> NULL
    SELECT NULL AND TRUE AND FALSE -> FALSE

    NULL est vraiment un simulacre de UNKNOWN !

  19. #19
    Membre du Club
    Inscrit en
    Mai 2010
    Messages
    27
    Détails du profil
    Informations forums :
    Inscription : Mai 2010
    Messages : 27
    Points : 50
    Points
    50
    Par défaut
    ha, et pour expliciter cette phrase : "vos certitudes sur la mauvaise gestion du NULL par Mysql n'est que le fruit de votre incompréhension des langages à typage dynamique!"

    c'était une addition sur ces données :
    INSERT INTO T_LIVRE_COMPTABLE_LVC VALUES (1, 'VENTE', NULL, '123,45');
    INSERT INTO T_LIVRE_COMPTABLE_LVC VALUES (2, 'ACHAT', '456,789', NULL);
    INSERT INTO T_LIVRE_COMPTABLE_LVC VALUES (3, 'VENTE', '50,00', '2 222,99');

    l'addition n'était fausse qu'à cause du transtypage de '2 222,99' ! c'est l'espace qui a rendu le calcul faux. pas la présence des NULL

  20. #20
    Membre du Club
    Inscrit en
    Mai 2010
    Messages
    27
    Détails du profil
    Informations forums :
    Inscription : Mai 2010
    Messages : 27
    Points : 50
    Points
    50
    Par défaut
    Allez, une dernière après j'arrête...

    La logique et le physique sont séparés dans SQLserver?
    Alors pourquoi il existe des comparateurs bit à bit??

Discussions similaires

  1. [langage] Comparer Perl avec d'autres langages comme C ?
    Par Anonymous dans le forum Langage
    Réponses: 3
    Dernier message: 11/08/2002, 00h52
  2. Problème avec la mémoire virtuelle
    Par Anonymous dans le forum CORBA
    Réponses: 13
    Dernier message: 16/04/2002, 17h10
  3. [Kylix] Runtime error 230 avec INDY
    Par Anonymous dans le forum EDI
    Réponses: 2
    Dernier message: 23/03/2002, 12h51
  4. Réponses: 2
    Dernier message: 21/03/2002, 00h01

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