Gestion du type INT

Bonjour à tous,

J'ai un souci dans la gestion de mes INT pour SQL-Server 1 est égal à 01, 001, 0001 ...

Donc si je fais :

Code:

---

1 2 3 4

SELECT COUNT(*) as LigneFacture FROM MaTable WHERE maFacture = 1

---

C'est la même chose que ça :

Code:

---

1 2 3 4

SELECT COUNT(*) as LigneFacture FROM MaTable WHERE maFacture = 001

---

Or dans MySQL je n'ai pas ce problème, ces mêmes requêtes ne renvoient pas le même résultat. Quelqu'un pourrait m'expliquer c'est quoi le problème :aie:

un integer représentant un nombre, effectivement 1 = 01 = 001.
Les zéros de gauche ne sont pas significatifs.

Salut Ptit_Dje et merci pour ton aide :king:

Mais alors comment je fais moi pour gérer ça ... Limite là je comprend pas... :aie:

Comment je vais gérer mes numéros de factures... Je vais pas devoir passer par un varchar quand même, c'est le comble :aie:

Je testerais sur oracle et postgres voir si j'ai le droit à la même histoire...

Quel solutions puis-je appliquer alors ?

Simplement utiliser des nombres qui sont de 1 à x.... en utilisant par exemple la propriété identity.

1 != 2 != 3 ....

Quel intéret de préfixer un nombre de 0 ?!
Qu'espéreriez vous comme résultat de l'addition suivante par exemple : 001 + 000001 ? 2 ? ou alors 001000001 ?

Oui si vous utilisez du varchar '1' != '01', cependant je n'en vois pas l'intéret ici.

L'intérêt il faudrait le demander aux comptables de ma boîte ... :aie:

Et pour le 001 + 000001 = 2 évidemment puisque on travaille sur des INT et que la valeur 000001 est équivalent à 1. Par contre ce n'est pas la même chose...
Cela veut quand on fera un select :

Code:

---

1 2 3 4

Select count(*) as cpt from matable where monChiffre = 001

---

Il prendra tes 1 et 000001 et 0001 ...

Alors pourquoi ne pas faire pareil avec :

Code:

---

1 2	select 1.000000000 + 0

---

C'est comme si à l'insertion il enlevait automatiquement les espaces en début et fin de ligne...

Je ne comprend pas la logique.

La logique est pourtant simple, tu utilises un type de données int, integer, nombre entier.
Or pour un nombre entier, 01 = 0000001 = 1.

Dans ton champ int, tu auras du mal à trouver une valeur à 0001 dans tout SGBD qui se respecte.

Et pourtant ...

Tu fais sous MySQL

Code:

---

1 2	SELECT 0001

---

Tu auras en retour 0001

Si tu fais la même oppération sous SQL-Server tu auras en retour 1

Puisqu'on pousse le raisonnement à son maximum pourquoi quand on fait :

Code:

---

1 2	SELECT 1.0000

---

Il ne retourne pas 1.0 ? On est bien dans la même logique là, non ?

Ce qui me déplait même si vous ne trouvez pas ça logique, c'est qu'on a introduit une logique humaine là dedans, alors qu'apparemment MySQL ne le gère pas de la même façon, je ne m'avance pas pour Oracle ni Postgres car je n'ai pas encore testé.

Same same but different :aie:

On n'a jamais dit que MySQL était un SGBD respectable...
Quand tu fais un select 1.0000, tu passes en type décimal, ce n'est plus du int. On parle alors de précision de décimal.

On est pas là pour faire l'apologie de tel ou tel SGBD ni pour lancer un troll, car c'est bien facile de trouver à répondre à ça :aie:

J'ai sauté du cock à l'ane en passant de int à décimal, mais je parlais de la logique...

Car quand tu fais un insert de 1.000000 il insèrera 1 alors pourquoi le select ne fais pas pareil ? Et là c'est la même chose pour l'insertion dans MySQL...

Quand tu insert 1.0000 dans un champ de type int. Effectivement il fait la conversion et insert 1.
Lorsque tu fais un simple select 1.00000 sans préciser de cast, il va choisir automatiquement le typage le plus approprié.
En mettant un .000 tu précises par défaut que c'est du décimal. Il affiche donc un décimal avec la précision encore une fois la plus appropriée, donc respectant l'ensemble des décimal que tu as donné.

C'est bon, c'est bon j'arrête les base de données :aie:

Le bon vieux fichier .txt est très bien aussi :aie:

Citation:

---

Envoyé par LhIaScZkTer

On est pas là pour faire l'apologie de tel ou tel SGBD ni pour lancer un troll, car c'est bien facile de trouver à répondre à ça :aie:

J'ai sauté du cock à l'ane en passant de int à décimal, mais je parlais de la logique...

Car quand tu fais un insert de 1.000000 il insèrera 1 alors pourquoi le select ne fais pas pareil ? Et là c'est la même chose pour l'insertion dans MySQL...

---

Tu as raison, chaque SGBD à ses pours et ses contres.
Il faut en tenir compte et savoir comment le SGBD que tu utilises réagis.
Après les différences de comportement entre chaque SGBD doivent faire l'objet d'une analyse dans le cadre d'une migration car justement, tu arrives sur de tels problèmes.

Petite parenthèse humouristique... Ou pas...
Quand tu passes du cock à l'ane... WAOW... Quel changement de calibre... :mouarf:

Personnellement, un SGBDR qui considère que l'entier 1 est différent de l'entier 01, ça m'embêterai énormement : ils ont la même valeur, ils sont donc égaux, le 0 à gauche n'est pas significatif. C'est mathématique, le type "int" représentant les entiers. Si tu ne considère pas la valeur, mais considères la chaine, dans ce cas, il faut utiliser des variables de type chaine de charactères... Ca me semble tout à fait légitime...