Discussion :

[Artemus24]

Salut kiki.

c'est parce que j'ai l'habitude de Mysql et de son typage dynamique

Je comprends ce que vous dite, mais le type doit toujours être explicite, c'est-à-dire déclaré avant son utilisation et sans ambiguïté.
Quand c'est implicite, c'est fréquemment sujet à des conversions, et donc perte de temps. Autrement dit, à éviter !

et moi ça ne me choque pas de comparer un INT à un BOOL : SELECT 5 IS TRUE -> 0+1+0+1=1 -> TRUE

Et comparer des navets avec des poireaux, ça donne quoi ? Désolé mais ça me choque grandement !

En informatique, il n'y a qu'une seule règle : la rigueur. Et faire n'importe quoi n'est pas une règle.

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

Le NULL n'est pas une bidouille mais répond à un besoin, celui d'indiquer que la colonne n'a pas encore été renseignée.
Le UNKNOWN et le NULL ne sont pas indissociables. Ce sont deux notions différentes pour des besoins différents.

Je le répète encore une fois :
--> le NULL est un marqueur et donc ce n'est pas une valeur. Il indique l'absence de valeur renseignée dans une colonne.
--> le UNKNOWN est une valeur qui signifie que comme son nom l'indique, un état inconnu ou si vous préférez un état intermédiaire entre le VRAI et le FAUX.
Ce n'est vraiment pas la même chose.

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".

Vous mélangez deux notions différentes, à savoir la logique et le système de numération.
Dans votre premier exemple, vous êtes en base dix, tandis que dans le second, vous êtes en base deux.
Il n'existe aucune opération de type calcul en base ternaire. Donc je ne voie pas ce que vous cherchez à démontrer.

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

Non, non et non ! Le NULL est un marqueur et c'est tout ce dont vous devez savoir.
Je le répète encore une fois, le NULL n'est pas une valeur tandis que UNKNOWN est une valeur.
Vous mélangez tout et vous ne comprenez pas ces notions de logique.

"vos certitudes sur la mauvaise gestion du NULL par Mysql n'est que le fruit de votre incompréhension des langages à typage dynamique!"

Elle est de qui cette phrase ? Je ne voie aucun rapport entre le type et le marqueur NULL.

J'ai jeté un coup d’œil a ce que vous nommez le typage dynamique : https://fr.wikipedia.org/wiki/Typage_dynamique
En gros, c'est une connerie monstrueuse !
C'est l'apanage des langages dits interprétés qui ont pour but de faciliter le développement au détriment de la performance et de la cohérence de vos données.
Il est toujours préférable de faire des déclaratives explicites comme par exemple "int val;" en 'C', pour indiquer que la variables est de type integer(entière).
Cela évite des tas de confusions et des pertes de temps en conversions inutiles.

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

Vous mélanger, encore une fois, deux notions différentes, le stockage physique d'une donnée et sa manipulation logique.

Ce que vous soulevez comme notion, se nomme la portabilité : https://fr.wikipedia.org/wiki/Portab...(informatique)
Le langage informatique utilisé, peut être de l'assembleur, voire autre chose, permet de développer toutes les fonctionnalités d'un SGBD.
Le même langage peut s'exécuter sur différentes machines ayant des processeurs différents et non compatibles entre eux.
Pour réaliser cette prouesse, il existe une couche entre le matériel et le langage proprement dit qui interprète ce que l'on nomme des API.
Ce sont les API qui sont utilisés dans le langage, et ce sont eux qui sont spécifiques à une machine particulière, et non le langage lui-même.

Le bit qui est utilisé dans ce langage peut avoir une représentation différentes d'une machine à une autre, et nécessite d'être interprétée pour que cette notion soit comprise par la machine.
Donc oui, on a la séparation du physique et du logique et quand même manipuler des bits.

@+

[SQLpro]

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??

Si vous faites référence à &, | et ^ pour les chaines binaires ce sont des comparateurs de chaines héxadécimales puisque le SQL permet l'utilisation de BINARY et VARBINARY... Mais ils ne fonctionnent pas du tout en bit à bit, du fait de la prise en compte de l'alignement qui diffère suivant le type utilisé BINARY ou VARBINARY !

A +

[SQLpro]

Salut kiki.

Je comprends ce que vous dite, mais ....

Pour une fois je vous ais donné un +1 !

Ce que kiki ne maitrise pas c'est la porosité des couches MySQL qui se vautre dans des transtypages imbitables qui provoque des résultats erronés. Nous avions déjà soulevé ce problème il y a longtemps avec l'exemple suivant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
SELECT x, x+1, x-1, x=1, x='3'
FROM   meeeeeh;

Résultat de la requête précédente :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
+------+------+------+------+-------+
| x    | x+1  | x-1  | x=1  | x='3' |
+------+------+------+------+-------+
| 3    |    2 |    0 |    1 |     1 |
+------+------+------+------+-------+

Que contient la colonne X de la table meeeeeh pour provoquer un tel résultat ?

A +

... la suite au prochain numéro de ce passionnant feuilleton !

J'en profite pour faire une pub pour moi même car ce genre de sujet sur le typage et l'utilisation des NULL dans SQL Server (et oui, pas dans cet infâmes monstruosité qu'est MySQmerde...) sera traité en long en large et en travers ici :

[Artemus24]

Salut SQLPRO.

Pour une fois je vous ais donné un +1 !

Merci !

Que contient la colonne X de la table meeeeeh pour provoquer un tel résultat ?

Le gros problème de l'interprétation repose sur les deux conditions x=1 et x='3'.
Comment se fait-il que ces deux conditions soient vraies toutes les deux à la fois ?

En première position dans le select, l'affichage de la colonne x donne 3.
Ce résultat est en conformité avec la cinquième position, à savoir la chaîne de caractères '3'.
Donc en première position, le 3 n'est pas un nombre mais une chaîne de caractères.
Cela résout l'interprétation de la première et de la cinquième position du select, à savoir que le contenu de la colonne x est '3'.

En ce qui concerne la quatrième position du select, la condition x=1 est vraie.
Vu qu'il ne s'agit pas de la chaîne de caractères '3', il s'agit forcément d'un indice.
J'en déduis alors que la chaîne '3' se trouve être associé à l'indice 1.
Donc, nous nous trouvons dans une structure de type tableau.
Or cela n'existe pas en tant quel tel sous MySql, sauf pour les types "enum" et "set".

Je suis en conformité avec les résultats de la deuxième et troisième position dans le select, si je considère que x vaut 1 :
--> x-1 donne 0.
--> x+1 donne 2.

Une opération de type arithmétique sur la colonne se fait alors sur l'indice. Cela se traduit en tant que tableau par "x[1] = '3'".

Je fais le test de vérification que voici :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
--------------
SET AUTOCOMMIT = 0
--------------
 
--------------
START TRANSACTION
--------------
 
--------------
DROP DATABASE IF EXISTS `base`
--------------
 
--------------
CREATE DATABASE `base`
    DEFAULT CHARACTER SET `latin1`
    DEFAULT COLLATE       `latin1_general_ci`
--------------
 
--------------
DROP TABLE IF EXISTS `meeeeeh`
--------------
 
--------------
CREATE TABLE `meeeeeh`
( `id`             integer unsigned not null auto_increment primary key,
  `x`              enum('3')
) ENGINE=InnoDB
  DEFAULT CHARSET=`latin1` COLLATE=`latin1_general_ci`
  ROW_FORMAT=COMPRESSED
--------------
 
--------------
insert into `meeeeeh` (`x`) values ('3')
--------------
 
--------------
select * from `meeeeeh`
--------------
 
+----+------+
| id | x    |
+----+------+
|  1 | 3    |
+----+------+
--------------
SELECT x, x+1, x-1, x=1, x='3'
FROM   meeeeeh
--------------
 
+------+------+------+------+-------+
| x    | x+1  | x-1  | x=1  | x='3' |
+------+------+------+------+-------+
| 3    |    2 |    0 |    1 |     1 |
+------+------+------+------+-------+
--------------
COMMIT
--------------
 
--------------
SET AUTOCOMMIT = 1
--------------
 
Appuyez sur une touche pour continuer...

Je suis en conformité avec le résultat. Suis-je dans le vrai ?

Il y a juste un truc, je n'utilise jamais le enum car sont fonctionnement peut-être pernicieux.
Le enum (tout comme le set) n'est pas un tableau, mais juste une façon de définir un ensemble de définition.
Je trouve cela contraire à la philosophie de la théorie des ensembles et n'apporte rien d'intéressant.
Autant définir une mini table avec cette ensemble de définition et de l'utiliser en tant que clef étrangère dans les tables associatives.
Autoriser des opérations sur les indices est une erreur ! Même si le stockage se fait d'une manière indicielle.

@+

[SQLpro]

Donc, nous nous trouvons dans une structure de type tableau.

Un vrai Sherlock Holmes ! Bravo

Or cela n'existe pas en tant quel tel sous MySql, sauf pour les types "enum" et "set".

[...]

Je suis en conformité avec le résultat. Suis-je dans le vrai ?

Oui !

Il y a juste un truc, je n'utilise jamais le enum car sont fonctionnement peut-être pernicieux.
Le enum (tout comme le set) n'est pas un tableau, mais juste une façon de définir un ensemble de définition.
Je trouve cela contraire à la philosophie de la théorie des ensembles et n'apporte rien d'intéressant.
Autant définir une mini table avec cette ensemble de définition et de l'utiliser en tant que clef étrangère dans les tables associatives.
Autoriser des opérations sur les indices est une erreur ! Même si le stockage se fait d'une manière indicielle.

Raison pour laquelle certains editeurs de SGBDR se sont abstenu des types "objets" de la norme SQL tel que les "set" les "row" ou les "array"... C'est le cas de SQL Server notamment. En sus c'est par nature pas indexable, donc performances de merde !

A +

[Artemus24]

Salut SQLPRO.

Nous sommes d'accord et c'est pourquoi vous m'avez mis un '-1'.

Il y a des tas de choses que l'on rajoute dans les bases de données qui n'ont pas lieu d'être car on peut faire sans.
L'exemple même du tableau est une aberration puisqu'elle enfreint la règle 1 des "forme normal" : atomique

@+

[SQLpro]

Salut SQLPRO.

Nous sommes d'accord et c'est pourquoi vous m'avez mis un '-1'.

Désolé et je m'en excuse... Je dois avoir tellement l'habitude de mettre des -1 que je me suis "naturellement" trompé ! Honte à moi... Je plaide coupable ! Mea culpa...

Il y a des tas de choses que l'on rajoute dans les bases de données qui n'ont pas lieu d'être car on peut faire sans.
L'exemple même du tableau est une aberration puisqu'elle enfreint la règle 1 des "forme normal" : atomique

@+

Exact ! Et je me tue à expliquez aux développeurs qu'il ne faut jamais utiliser ce genre d'imbécilité car ce sont de véritables bombes à retardement...

A +

[Artemus24]

Salut SQLPRO.

J'ai un gros doute ! Est-ce vous SQLPRO derrière votre écran ? Dans le même sujet, vous m'avez mis trois fois '+1'.
Etes-vous possédez pas un démon ou bien avez-vous changez d'attitude à mon égard ?

Désolé et je m'en excuse... Je dois avoir tellement l'habitude de mettre des -1 que je me suis "naturellement" trompé ! Honte à moi... Je plaide coupable ! Mea culpa...

Ce n'est pas grave quand on reconnait son erreur, mais je préférerais plutôt des explications que de me faire noter comme à l'école.
Si je ne partage pas avec vous l'opinion que vous avez sur certains sujets, soit cela provient d'un regard différent sur le sujet, soit nous avons des problèmes de communications.

Exact ! Et je me tue à expliquez aux développeurs qu'il ne faut jamais utiliser ce genre d’imbécillité car ce sont de véritables bombes à retardement...

Le fond du problème est que la culture informatique se perd.
Nos chers développeurs débutants n'ont jamais connu comme nous, des ordinateurs archaïques où nous devions nous casser la tête pour résoudre des problèmes de programmations.

Le premier réflexe que j'ai, est de me dire comment vais-je résoudre ce problème (peu importe le problème).
Je vais tenter de trouver une solution avec les outils qui sont à ma disposition.
Par exemple, en Javascript, je vais chercher une solution pour faire une animation.

Les jeunes d'aujourd'hui raisonnent différemment en se disant que quelqu'un a déjà trouvé une solution à ce problème.
C'est le cas avec Jquery, qui permet de faire exactement la même chose mais avec une écriture plus simple.
Sauf que ils sont obligés de s'adjoindre la bibliothèque Jquery ce qui va pénaliser le temps de chargement de leur page web.

Quand on leur explique que ce n'est pas la bonne méthode, ils ne comprennent pas car il est plus facile pour eux de faire du copier/coller que de chercher une solution adaptée.

Le problème est bien plus grave que cela, car les entreprises ont comme mot d'ordre, "le temps c'est de l'argent".
Donc prendre son temps pour finaliser un projet est du temps perdu qui serait mieux utiliser par ailleurs.
Mais le pire dans tout cela, c'est qu'un projet sans bug ne rapporte rien à leur entreprise.
Donc un projet qui nécessite une maintenance est un bon projet car cela va rapporter des royalties à l'entreprises.

Même si en apparence, c'est une imbécillité (et je suis d'accord avec vous), la solution de facilité sera toujours le premier réflexe de ces débutants.
Alors comment résoudre ce problème de culture ? Une des solutions est de les interdire.
Une autre, est d'inculquer les bonnes pratiques, mais là, ce n'est pas gagné !

@+

[SQLpro]

Etes-vous possédez pas un démon ou bien avez-vous changez d'attitude à mon égard ?

Etant politiquement incorrecte et pas du touy adepte du consensus mou, je préfère de côté démoniaque... Au tout début de DVP je donnais plutôt dans le Sissi Impératrice en corrigeant gentiment les bêtises des internautes et je me suis aperçut que l'on ne suivait pas mes conseils et que l'on me prenait pour un vieux con... Alors je suis passé à la phase Terminator et depuis, ça marche mieux, ça rentre dans le crâne plus facilement !

[...]


Le fond du problème est que la culture informatique se perd.

A qui e dis tu !

Nos chers développeurs débutants n'ont jamais connu comme nous, des ordinateurs archaïques où nous devions nous casser la tête pour résoudre des problèmes de programmations.
[...]
Les jeunes d'aujourd'hui raisonnent différemment en se disant que quelqu'un a déjà trouvé une solution à ce problème.

Tout à fait, et donc, j'ai changé ma stratégie de cours pour les écoles d'ingénieurs. Je suis passé du cours magistral aux TD directement en disant : "je vous donne mon cours en pdf, vous avez Internet, quand on se revoit dans 1 mois, vous savez tout et on commence les exercices...". Bien évidemment, premier exercice ils se vautrent tout lamentablement et commence à comprendre qu'ils sont passés à côté de beaucoup de choses...

[...]

Le problème est bien plus grave que cela, car les entreprises ont comme mot d'ordre, "le temps c'est de l'argent".

Et au lieu de le dépenser en préalable elle vont le payer beaucoup plus cher au final !

Donc prendre son temps pour finaliser un projet est du temps perdu qui serait mieux utiliser par ailleurs.
Mais le pire dans tout cela, c'est qu'un projet sans bug ne rapporte rien à leur entreprise.
Donc un projet qui nécessite une maintenance est un bon projet car cela va rapporter des royalties à l'entreprises.

Pour info cela m'est arrivé avec un grand loueur de voiture dans lequel il y avait pléthore d'intervenants d'une grande SSII qui colmataient les fuites du tonneau des danaïdes... Quand je suis arrivé j'ai dit stop et on a migré tout le système. Quelques mois plus tard ils ont viré 50% des prestataires pour lesquels c'était une rente de situation !

Même si en apparence, c'est une imbécillité (et je suis d'accord avec vous), la solution de facilité sera toujours le premier réflexe de ces débutants.
Alors comment résoudre ce problème de culture ? Une des solutions est de les interdire.
Une autre, est d'inculquer les bonnes pratiques, mais là, ce n'est pas gagné !

Pourquoi crois-tu que je continue à faire de la formation qui me rapporte 50% de moins que du conseil ???
J'y crois, j'y apporte ma pierre, mais c'est pas gagné tant on voit de conneries écrites sur Internet, comme le classique "faut pas faire des jointures c'est pas performant !!!"

A +

[Artemus24]

Salut SQLPRO.

Bien évidemment, premier exercice ils se vautrent tout lamentablement et commence à comprendre qu'ils sont passés à côté de beaucoup de choses...

Le résultat contraire serait surprenant car ils auraient anticipé le premier TD en s'y préparant.
De plus, vous leur prêtez des qualités qu'ils n'ont pas nécessairement, à savoir être dans l'autocritique.

Et au lieu de le dépenser en préalable elle vont le payer beaucoup plus cher au final !

Pas nécessairement car le client peut débourser une fortune pour obtenir ce qu'il aurait dû avoir dès le départ, un travail de qualité.

Pour info cela m'est arrivé avec un grand loueur de voiture ...

Au début de ma carrière professionnelle, je me suis fait convoquer par le directeur. En général, c'est pour se faire engueuler et non pour se faire féliciter.
Je ne voyais pas trop pourquoi car je faisais toujours en sorte que mes développements étaient impeccables : pas d'erreurs de compilation, respect des tests et du cahier des charges.
Le directeur m'explique que je suis un mauvais employé car je travaille trop bien. Pardon ?
Mes développements ne nécessitaient aucune maintenance et donc ne rapportaient rien à l'entreprise et de ce fait, j'étais un mauvais employé parce que je travaillais trop bien.
Il me demande de changer d'attitude pour engendrer de la maintenance afin d'extorquer au client des royalties qui n'avaient pas lieu d'être.
C'est du vécu et j'étais abasourdi quand j'ai appris cela ! Il y a de ces mentalités dans le monde des entreprises que l'on ne peut pas s'imaginer quand on ne l'a pas vécu.

Pourquoi crois-tu que je continue à faire de la formation qui me rapporte 50% de moins que du conseil ???

Parce que vous êtes un philanthrope !

J'y crois, j'y apporte ma pierre, mais c'est pas gagné tant on voit de conneries écrites sur Internet, comme le classique "faut pas faire des jointures c'est pas performant !!!"

A l'inverse de vous, je n'y crois pas. Il ne sert à rien d'aider les gens s'ils ne sont pas demandeur de cette aide.
Mais ce qui est pernicieux dans cette attitude, c'est que le demandeur ne fait plus aucun effort car il sait où trouver la réponse sans faire le moindre effort.
Et sans effort, on n'apprends rien, ou plutôt on ne retient rien. C'est la politique du copier/coller qu'offre justement l'internet où tout est accessible en un clic.

Je suis partisan de mettre les mains dans le cambouis, de soulever le capot et de voir pourquoi ça ne fonctionne pas comme je l'espère.
De faire des tests, de chercher sur le net ou ailleurs pour trouver ce qui me pose problème.
Puis quand j'ai ma solution (j'ai bien dit ma solution et non la solution que l'on m'impose), alors je range cela dans un cahier ou dans mon ordinateur ou dans ma tête.
J'ai toujours travaillé ainsi, et cela m'a toujours été profitable car j'applique le principe de Paracelse : de penser et d'expérimenter par moi-même et de ne jamais prendre pour argent comptant tout ce que l'on me dit, même si c'est vrai.

@+

[SQLpro]

Au début de ma carrière professionnelle, je me suis fait convoquer par le directeur. En général, c'est pour se faire engueuler et non pour se faire féliciter.
Je ne voyais pas trop pourquoi car je faisais toujours en sorte que mes développements étaient impeccables : pas d'erreurs de compilation, respect des tests et du cahier des charges.
Le directeur m'explique que je suis un mauvais employé car je travaille trop bien. Pardon ?
Mes développements ne nécessitaient aucune maintenance et donc ne rapportaient rien à l'entreprise et de ce fait, j'étais un mauvais employé parce que je travaillais trop bien.
Il me demande de changer d'attitude pour engendrer de la maintenance afin d'extorquer au client des royalties qui n'avaient pas lieu d'être.
C'est du vécu et j'étais abasourdi quand j'ai appris cela ! Il y a de ces mentalités dans le monde des entreprises que l'on ne peut pas s'imaginer quand on ne l'a pas vécu.

Cela m'est arrivé aussi plusieurs fois dans différentes SSII que je ne citerais pas. J'ai immédiatement pris le large.À l'époque on m'a considéré comme un instable ! Maintenant cela s'est transformé en expertise !
Si j'avais continué comme ça, non seulement j'aurais été frustré et mécontent de mon boulot, mais j'aurais aussi gagné moins d'argent et rarement eut la possibilité de choisir mes clients, ce que je fais aujourd'hui depuis 13 ans dans mes entreprises (SQL spot étant ma 2e).

Pour le reste plutôt d'accord !

A +

[Artemus24]

Salut SQLPRO.

Cela m'est arrivé aussi plusieurs fois dans différentes SSII que je ne citerais pas.

J'ai oubli de préciser que cette SSII où je travaillais, s'est retrouvé devant le justice pour avoir vendu à un client un produit qui n'existait pas.
La magouille consistait à développer le produit chez ce client, au frais du client, en faisant croire à de la maintenance, pour ensuite le revendre chez d'autres clients.

@+

[-kiki-]

Vous êtes mignons à vous congratuler mutuellement! ^^

Je n'ai eu que quelques cours de développement dans mon cursus, mais le prof avait réussi à glisser plus d'une fois qu'il ne fallait pas réinventer la roue, et que quelqu'un sur internet avait certainement déjà solutionné le même problème.
Mais le problème, c'est surtout que beaucoup de branleurs traduisent ça dans leur tête en "fais du copier-coller, ne te casses pas le cul à côder!".
Donc il faut que les formateurs soient vraiment vigilants, non pas à ce qu'ils veulent enseigner, mais à ce que reçoit l'élève!

Comme vous dites, c'est surtout l'attitude de l'élève qui pose problème.
Et il n'y a pas que le problème de l'effort, il y a le problème de l'égo vs incompétence :
Un élève (ou un junior) n'a pas toujours les connaissance pour comprendre les arguments du prof (ou de l'expert),
mais il ne se prend pas pour de la merde, donc il se dit que c'est ce vieux con qui est à côté de la plaque, et il persiste dans sa connerie.

A mon petit niveau ça m'est arrivé assez souvent avec des collègues. Mais je sais que j'aurais pu mieux faire :
- parfois, je considérais que mon interlocuteur était sensé connaitre son job, et je ne prenais pas la peine de lui expliquer tout ce qui aurait pu lui permettre de comprendre mes arguments
- parfois, c'est mon manque de maitrise sur le sujet qui faisais que mes arguments n'étaient pas assez précis

Donc si vous enseignez (ce qui n'est pas mon cas je vous rassure :p) prenez bien le temps de vous assurer que vos élèves ont bien compris chaque détail.

Dans votre débat par exemple, au début j'avais l'impression que vous confondiez tout deux la notion de valeur binaire et de valeur stockée dans la colonne!
bon, après je me suis dit que vous étiez qd même pas si con, j'ai relu, et j'ai mieux compris

En tout cas, merci pour vos explications.
Je comprend mieux certaines choses, je ne suis toujours pas d'accord sur certaines autres, mais ça me conforte surtout sur un point : la séparation physique/logique elle me gonfle!

[Artemus24]

Salut Kiki.

Merci pour ton retour d'expérience.
Après des années d'expériences professionnelles, je constate toujours que le principale handicap repose sur la communication et de bien se faire comprendre.
Il y a une énorme différence entre ce que l'on croit comprendre et la réalité.
Mais on n'a pas toujours le mots pour l'exprimer correctement et je le constate avec SQLPRO.
Surtout qu'en fonction de son propre cursus, les mots n'ont pas le même sens pour chacun d'entre nous.

Je me rappelle qu'une fois un chef m'a interpellé au sujet de l’amortissement, sans préciser de quoi il s'agissait.
Bien que nous étions dans une banque, il est parfois difficile de savoir ce que certains ont dans la tête.
Et ce qui peut être évident pour certains, ne le sont pas nécessairement pour d'autres.
J'avais cru comprendre qu'il s'agissait d'amortissement linéaire, voire dégressif.
Or il ne parlait pas de ce genre d'amortissement, mais d'un amortissement indivis.
Pour préciser mon désarrois, j'ai cru qu'il parlais d'amortissement comptable et non d'amortissement financier !
C'est sur ce genre de manque de précision, que les quiproquos peuvent provoquer des incompréhensions.

je ne suis toujours pas d'accord sur certaines autres

Lâchez-vous et poser dans ce sujet, toutes les questions qui vous posent problèmes.

En ce qui concerne la séparation entre le physique et le logique, cela repose sur la notion de portabilité d'une application.
Le physique, c'est ce qui se passe dans la machine. On le manipule très bien en faisant de l'assembleur.
Sauf que développer une application en assembleur, ne permet pas de l'exécuter sur un autre processeur.
Alors pour remédier à cela, on créer une couche intermédiaire, qui consiste à dire que le niveau supérieur est développé dans un langage indépendant de celui de la machine.
Pour faire simple, il s'agit d'une couche où on interprète des fonctionnalités du langage supérieure dans le langage de la machine.
Pour ce qui est du logique, il s'agit d'utiliser des structures de données indépendamment de ce que propose la machine.
Et de ce fait, vous avez trois niveaux :
--> le niveau matériel où l'assembleur est le langage compréhensible par la machine.
--> une couche intermédiaire qui la plupart du temps sera interprété et consiste à traduire les API du langage supérieure d'une manière compréhensible par la machine.
A partir de ce moment, le langage supérieur est portable sur n'importe quelle machine, car il suffit de réécrire cette couche.
--> une couche logique qui consiste à définir dans le langage utilisé une représentation des données indépendamment de celle de la machine.

C'est ce que fait certains langages de programmation, comme le 'C' (ainsi que le 'C++') qui sont dit portables.
Il suffit de reprendre le source et de le compiler sur une autre machine pour constater qu'il va s'exécuter sans problème.

@+

[SQLpro]

...mais ça me conforte surtout sur un point : la séparation physique/logique elle me gonfle!

Elle est pourtant fondamentale ! Faisons une petite comparaison...
Sur une voiture qui roule, heureusement que le pilote n'a pas à soulever le capot toutes les 5 minutes pour conduire !!!!

A +

[Artemus24]

Salut SQLPRO.

C'est surtout une garantie du bon fonctionnement de votre SGBDR.

... la suite au prochain numéro de ce passionnant feuilleton !

Et la suite, ce sera quand ?

@+

[SQLpro]

Et la suite, ce sera quand ?+

Quand j'aurai du temps et que les crétins de fonctionnaires du contrôle aérien qui gagnent un max de pognon, partent à la retraite 10 ans avant le privé et font le moins d'heures de travail comparés à leurs collègues d’Europe cesseront leur grève qui m'oblige à prendre ma voiture pour faire un Nice Paris de nuit pour aller bosser à cause des vols annulés !

A +