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 !
Et quand c'est pas possible de changer de SGBD, on fait comment ?Envoyé par SQLPRO
SQL est un langage de requête afin de manipuler les bases de données.Envoyé par SQLPRO
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.
Ce ne sont pas les règles de fonctionnement qui définissent le modèle, mais bien l'organisation physique des données.Envoyé par SQLPRO
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 !
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.Envoyé par SQLPRO
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.
@+
Partager