type d'un champ mysql

antoine

13/01/2009 à 10:10

Le lundi 12 janvier 2009 23:21, vous avez écrit :

> Il s'agit d'adresses IP (IPV4) enregistrées avec les points :
> A.B.C.D

----------------------------

Drôle d'idée d'utiliser la forme texte, d'autant plus qu'elle est mal
normalisée en IPv4 (A.B.C.D n'est pas la seule notation
possible). Pourquoi ne pas plutôt stocker la forme binaire, qui permet
des comparaisons et du masquage ?

---------------

"plutôt stocker la forme binaire" :

Merci alors de me donner le type de ce format :
int, bigint, bool, char ... ?

antoine

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/DebFrFrenchLists
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact

Mathieu JANIN

13/01/2009 à 10:40

Le mardi 13 janvier 2009, a écrit :

Le lundi 12 janvier 2009 23:21, vous avez écrit :
> > Il s'agit d'adresses IP (IPV4) enregistrées avec les points :
> > A.B.C.D

----------------------------

> Drôle d'idée d'utiliser la forme texte, d'autant plus qu'elle est m al
> normalisée en IPv4 (A.B.C.D n'est pas la seule notation
> possible). Pourquoi ne pas plutôt stocker la forme binaire, qui permet
> des comparaisons et du masquage ?

---------------

> "plutôt stocker la forme binaire" :

Merci alors de me donner le type de ce format :
int, bigint, bool, char ... ?

antoine

Bonjour,
ben en ipv4, c'est une donnée de 4 octets, et en ipv6, de 16.
pour éviter les recherches fastidieuses sur une partie de cette donnée de 4
octets, il me parait plus simple que chaque octet soit un champs séparé (pour
faire des recherches genre
SELECT ip3 FROM toto WHERE ip0="192" AND ip1="168" AND ip2="0";
pour récupèrer les machine d'un réseau de classe A, par exemple,
ou pour recomposer facilement la dénomination ARPA de l'adress d'une mach ine
ou d'un réseau, 0.168.192.IN-ADDR.DARPA )

Ca donnerait donc pour moi 4 champs individuels d'un octet (type CHAR) en i pv4
et 16 en ipv6.

Enfin je prendrais plutot pgsql pour ses fonctionnalités IP, si j'avais l e
choix.

++, MATT

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/DebFrFrenchLists
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact

Stephane Bortzmeyer

13/01/2009 à 21:40

On Tue, Jan 13, 2009 at 10:19:21AM +0100,
Mathieu JANIN wrote
a message of 53 lines which said:

pour récupèrer les machine d'un réseau de classe A,

Mauvaise idée, les classes ayant été supprimées il y a plus de dix
ans.

http://www.bortzmeyer.org/fini-les-classes.html

----------------------------

On voit souvent des administrateurs réseaux parler de « classe B » ou
de « classe C » en se référant à un groupe d'adresses IP. Ces termes
sont dépassés et reflètent une réalité qui a disparu depuis longtemps.
Ils ne devraient plus être employés.

Pour expliquer pourquoi, je dois faire un détour sur la façon dont
fonctionne l'adressage IP, normalisé, pour IP version 4, dans le RFC
791. Les adresses IPv4 faisant 32 bits, ce protocole permet 2^32 soit
plus de quatre milliards d'adresses. Pas question que les routeurs
aient une route vers chacune de ces adresses. Leur mémoire n'y
suffirait pas et, surtout, le rythme de changement serait trop élevé.
On regroupe donc aujourd'hui les adresses contiguës en *préfixes* de
longueur N où N est le nombre de bits qui servent à identifier le
préfixe, les autres bits identifiant la machine. En IPv4 et IPv6, ce
nombre de bits n'est pas fixé par le protocole, il est déterminé par
l'administrateur système. On note un réseau par son préfixe, suivi
d'une barre oblique et de la longueur du préfixe. Par exemple, le
préfixe 192.0.2.128/25 a une longueur N de 25 bits, ces 25 bits valant
11000000 00000000 00000010 10000000, laissant 7 bits pour identifier
une machine sur ce réseau. Si plusieurs routes sont possibles pour une
destination donnée, le routeur prendra la *plus spécifique* (celle dont
N est le plus grand).

A t-on toujours fait comme cela ? Non. Il y a de nombreuses années, les
préfixes étaient de taille fixe, on avait uniquement le choix en des
préfixes de longueur 8, baptisés « classes A », de longueur 16, les
« classes B » et de longueur 24, les « classes C ». Ce système était
très rigide et gaspillait considérablement les adresses (si une classe
C ne suffisait pas, pas possible de prendre un /23, il fallait sauter
directement à une classe B). Il a donc été abandonné au profit de
l'adressage actuel, qui avait été baptisé CIDR pour "Classless
Inter-Domain Routing". "Classless" donc, « sans classe ». Ce nom dit
bien ce qu'il veut dire, les classes ont disparu.

Le premier RFC sur les idées qui mèneront à CIDR a été le RFC 1338 en
juin 1992. Le RFC 1467 en août 1993 faisait le point sur le déploiement
de CIDR. Les RFC 1518 et RFC 1519 en septembre 1993 sont les premier à
décrire CIDR sous sa forme actuelle, pendant que le RFC 1517 décrivait
les motivations et les problèmes que CIDR visait à résoudre. C'est donc
depuis quinze ans que les classes ont disparu ! Révisée, la norme
actuelle est le RFC 4632. Comme on le voit, l'adressage actuel est très
ancien. Il est très inquiétant que des enseignants ignorants donnent
toujours des cours IP où les classes sont citées, sans préciser
qu'elles n'ont qu'un intérêt historique.

Les classes se voient encore un peu dans certaines techniques comme le
DNS où les délégations dans in-addr.arpa se font sur des frontières
d'octets. Ce problème a été largement réglé par le RFC 2317.

Pendant les quelques années où la communauté Internet testait la
nouvelle technique, certains termes avaient été utilisés, qui n'ont
plus de raison d'être. C'est ainsi qu'on parlait de "supernetting" pour
désigner l'*agrégation* de plusieurs classes en un préfixe plus général
(cette technique étant la base de CIDR, elle n'a plus besoin d'un nom
spécifique, même s'il faut encore apparemment dire à IOS ip classless
pour qu'il l'accepte). De même, les VLSM ("Variable Length Subnet Mask"
ont été oubliés : le masque du réseau est désormais *toujours* de
longueur variable.

Le successeur d'IPv4, IPv6, est, lui, parti proprement en tenant compte
de l'expérience de son prédécesseur et a toujours été « sans classe ».

Enfin je prendrais plutot pgsql pour ses fonctionnalités IP, si
j'avais le choix.

Oui, je ne sais pas pourquoi l'OP a choisi MySQL.

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/DebFrFrenchLists
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact

On Tue, Jan 13, 2009 at 10:19:21AM +0100,
Mathieu JANIN <mattotop@orange.fr> wrote
a message of 53 lines which said:

pour récupèrer les machine d'un réseau de classe A,

Mauvaise idée, les classes ayant été supprimées il y a plus de dix
ans.

http://www.bortzmeyer.org/fini-les-classes.html

----------------------------

On voit souvent des administrateurs réseaux parler de « classe B » ou
de « classe C » en se référant à un groupe d'adresses IP. Ces termes
sont dépassés et reflètent une réalité qui a disparu depuis longtemps.
Ils ne devraient plus être employés.

Pour expliquer pourquoi, je dois faire un détour sur la façon dont
fonctionne l'adressage IP, normalisé, pour IP version 4, dans le RFC
791. Les adresses IPv4 faisant 32 bits, ce protocole permet 2^32 soit
plus de quatre milliards d'adresses. Pas question que les routeurs
aient une route vers chacune de ces adresses. Leur mémoire n'y
suffirait pas et, surtout, le rythme de changement serait trop élevé.
On regroupe donc aujourd'hui les adresses contiguës en *préfixes* de
longueur N où N est le nombre de bits qui servent à identifier le
préfixe, les autres bits identifiant la machine. En IPv4 et IPv6, ce
nombre de bits n'est pas fixé par le protocole, il est déterminé par
l'administrateur système. On note un réseau par son préfixe, suivi
d'une barre oblique et de la longueur du préfixe. Par exemple, le
préfixe 192.0.2.128/25 a une longueur N de 25 bits, ces 25 bits valant
11000000 00000000 00000010 10000000, laissant 7 bits pour identifier
une machine sur ce réseau. Si plusieurs routes sont possibles pour une
destination donnée, le routeur prendra la *plus spécifique* (celle dont
N est le plus grand).

A t-on toujours fait comme cela ? Non. Il y a de nombreuses années, les
préfixes étaient de taille fixe, on avait uniquement le choix en des
préfixes de longueur 8, baptisés « classes A », de longueur 16, les
« classes B » et de longueur 24, les « classes C ». Ce système était
très rigide et gaspillait considérablement les adresses (si une classe
C ne suffisait pas, pas possible de prendre un /23, il fallait sauter
directement à une classe B). Il a donc été abandonné au profit de
l'adressage actuel, qui avait été baptisé CIDR pour "Classless
Inter-Domain Routing". "Classless" donc, « sans classe ». Ce nom dit
bien ce qu'il veut dire, les classes ont disparu.

Le premier RFC sur les idées qui mèneront à CIDR a été le RFC 1338 en
juin 1992. Le RFC 1467 en août 1993 faisait le point sur le déploiement
de CIDR. Les RFC 1518 et RFC 1519 en septembre 1993 sont les premier à
décrire CIDR sous sa forme actuelle, pendant que le RFC 1517 décrivait
les motivations et les problèmes que CIDR visait à résoudre. C'est donc
depuis quinze ans que les classes ont disparu ! Révisée, la norme
actuelle est le RFC 4632. Comme on le voit, l'adressage actuel est très
ancien. Il est très inquiétant que des enseignants ignorants donnent
toujours des cours IP où les classes sont citées, sans préciser
qu'elles n'ont qu'un intérêt historique.

Les classes se voient encore un peu dans certaines techniques comme le
DNS où les délégations dans in-addr.arpa se font sur des frontières
d'octets. Ce problème a été largement réglé par le RFC 2317.

Pendant les quelques années où la communauté Internet testait la
nouvelle technique, certains termes avaient été utilisés, qui n'ont
plus de raison d'être. C'est ainsi qu'on parlait de "supernetting" pour
désigner l'*agrégation* de plusieurs classes en un préfixe plus général
(cette technique étant la base de CIDR, elle n'a plus besoin d'un nom
spécifique, même s'il faut encore apparemment dire à IOS ip classless
pour qu'il l'accepte). De même, les VLSM ("Variable Length Subnet Mask"
ont été oubliés : le masque du réseau est désormais *toujours* de
longueur variable.

Le successeur d'IPv4, IPv6, est, lui, parti proprement en tenant compte
de l'expérience de son prédécesseur et a toujours été « sans classe ».

Enfin je prendrais plutot pgsql pour ses fonctionnalités IP, si
j'avais le choix.

Oui, je ne sais pas pourquoi l'OP a choisi MySQL.

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/DebFrFrenchLists
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Vous avez filtré cet utilisateur ! Consultez son message

On Tue, Jan 13, 2009 at 10:19:21AM +0100,
Mathieu JANIN wrote
a message of 53 lines which said:

pour récupèrer les machine d'un réseau de classe A,

Mauvaise idée, les classes ayant été supprimées il y a plus de dix
ans.

http://www.bortzmeyer.org/fini-les-classes.html

----------------------------

On voit souvent des administrateurs réseaux parler de « classe B » ou
de « classe C » en se référant à un groupe d'adresses IP. Ces termes
sont dépassés et reflètent une réalité qui a disparu depuis longtemps.
Ils ne devraient plus être employés.

Pour expliquer pourquoi, je dois faire un détour sur la façon dont
fonctionne l'adressage IP, normalisé, pour IP version 4, dans le RFC
791. Les adresses IPv4 faisant 32 bits, ce protocole permet 2^32 soit
plus de quatre milliards d'adresses. Pas question que les routeurs
aient une route vers chacune de ces adresses. Leur mémoire n'y
suffirait pas et, surtout, le rythme de changement serait trop élevé.
On regroupe donc aujourd'hui les adresses contiguës en *préfixes* de
longueur N où N est le nombre de bits qui servent à identifier le
préfixe, les autres bits identifiant la machine. En IPv4 et IPv6, ce
nombre de bits n'est pas fixé par le protocole, il est déterminé par
l'administrateur système. On note un réseau par son préfixe, suivi
d'une barre oblique et de la longueur du préfixe. Par exemple, le
préfixe 192.0.2.128/25 a une longueur N de 25 bits, ces 25 bits valant
11000000 00000000 00000010 10000000, laissant 7 bits pour identifier
une machine sur ce réseau. Si plusieurs routes sont possibles pour une
destination donnée, le routeur prendra la *plus spécifique* (celle dont
N est le plus grand).

A t-on toujours fait comme cela ? Non. Il y a de nombreuses années, les
préfixes étaient de taille fixe, on avait uniquement le choix en des
préfixes de longueur 8, baptisés « classes A », de longueur 16, les
« classes B » et de longueur 24, les « classes C ». Ce système était
très rigide et gaspillait considérablement les adresses (si une classe
C ne suffisait pas, pas possible de prendre un /23, il fallait sauter
directement à une classe B). Il a donc été abandonné au profit de
l'adressage actuel, qui avait été baptisé CIDR pour "Classless
Inter-Domain Routing". "Classless" donc, « sans classe ». Ce nom dit
bien ce qu'il veut dire, les classes ont disparu.

Le premier RFC sur les idées qui mèneront à CIDR a été le RFC 1338 en
juin 1992. Le RFC 1467 en août 1993 faisait le point sur le déploiement
de CIDR. Les RFC 1518 et RFC 1519 en septembre 1993 sont les premier à
décrire CIDR sous sa forme actuelle, pendant que le RFC 1517 décrivait
les motivations et les problèmes que CIDR visait à résoudre. C'est donc
depuis quinze ans que les classes ont disparu ! Révisée, la norme
actuelle est le RFC 4632. Comme on le voit, l'adressage actuel est très
ancien. Il est très inquiétant que des enseignants ignorants donnent
toujours des cours IP où les classes sont citées, sans préciser
qu'elles n'ont qu'un intérêt historique.

Les classes se voient encore un peu dans certaines techniques comme le
DNS où les délégations dans in-addr.arpa se font sur des frontières
d'octets. Ce problème a été largement réglé par le RFC 2317.

Pendant les quelques années où la communauté Internet testait la
nouvelle technique, certains termes avaient été utilisés, qui n'ont
plus de raison d'être. C'est ainsi qu'on parlait de "supernetting" pour
désigner l'*agrégation* de plusieurs classes en un préfixe plus général
(cette technique étant la base de CIDR, elle n'a plus besoin d'un nom
spécifique, même s'il faut encore apparemment dire à IOS ip classless
pour qu'il l'accepte). De même, les VLSM ("Variable Length Subnet Mask"
ont été oubliés : le masque du réseau est désormais *toujours* de
longueur variable.

Le successeur d'IPv4, IPv6, est, lui, parti proprement en tenant compte
de l'expérience de son prédécesseur et a toujours été « sans classe ».

Enfin je prendrais plutot pgsql pour ses fonctionnalités IP, si
j'avais le choix.

Oui, je ne sais pas pourquoi l'OP a choisi MySQL.

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/DebFrFrenchLists
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact

Mathieu JANIN

14/01/2009 à 09:10

Bonjour !

Le mardi 13 janvier 2009, Stephane Bortzmeyer a écrit :

On Tue, Jan 13, 2009 at 10:19:21AM +0100,
Mathieu JANIN wrote

a message of 53 lines which said:
> pour récupèrer les machine d'un réseau de classe A,

Mauvaise idée, les classes ayant été supprimées il y a plus de dix
ans.

(...)
Merci, je sais ce qu'est une adresse CIDR, mais mes habitudes datent de bie n
avant son appartition.

On voit souvent des administrateurs réseaux parler de « classe B » ou
de « classe C » en se référant à un groupe d'adresses IP. C es termes
sont dépassés et reflètent une réalité qui a disparu depuis lon gtemps.
Ils ne devraient plus être employés.

(...)
Je suis peut être un admin réseau obsolète, mais il se trouve que m ême si ce
que je disais est dépassé dans la forme, tu as quand même compris de quoi je
parlais, ce qui est un signe que certains de mes interlocuteurs donnent
encore son sens à ce que je dis.

Merci, de ne plus relever quand je parlerais encore de classe, donc, parceq ue
je ne me gènerais pas de continuer à utiliser le terme,
;)

++, MATT

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/DebFrFrenchLists
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact

Yves Rutschle

15/01/2009 à 12:00

On Wed, Jan 14, 2009 at 08:48:30AM +0100, Mathieu JANIN wrote:

Je suis peut être un admin réseau obsolète, mais il se trouve que même si ce
que je disais est dépassé dans la forme, tu as quand même compris de quoi je
parlais, ce qui est un signe que certains de mes interlocuteurs donnent
encore son sens à ce que je dis.

Le problème n'est pas de parler de classe A, on comprend ce
que ça veut dire ; le problème est de construire des outils
basés dessus: dans ta solution, tu ne peux faire des extracts
*que* de schémas qui tiennent dans des classes. Le jour où
tu as besoin d'un autre schéma, tu peux jeter tous tes
outils.

Merci, de ne plus relever quand je parlerais encore de classe, donc, parceque
je ne me gènerais pas de continuer à utiliser le terme,

Bon, je retourne perforer mes cartes.

Y.

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/DebFrFrenchLists
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact

antoine

15/01/2009 à 12:50

Le jeudi 15 janvier 2009 11:40, Yves Rutschle a écrit :

On Wed, Jan 14, 2009 at 08:48:30AM +0100, Mathieu JANIN wrote:
> Je suis peut être un admin réseau obsolète, mais il se trouve que même si ce
> que je disais est dépassé dans la forme, tu as quand même compris de quoi je
> parlais, ce qui est un signe que certains de mes interlocuteurs donnent
> encore son sens à ce que je dis.
Le problème n'est pas de parler de classe A, on comprend ce
que ça veut dire ; le problème est de construire des outils
basés dessus: dans ta solution, tu ne peux faire des extracts
*que* de schémas qui tiennent dans des classes. Le jour où
tu as besoin d'un autre schéma, tu peux jeter tous tes
outils.
> Merci, de ne plus relever quand je parlerais encore de classe, donc, pa rceque
> je ne me gènerais pas de continuer à utiliser le terme,
Bon, je retourne perforer mes cartes.

------------

Après moultes réponses, (certes intéressantes),
je n'ai toujours pas la réponse, à savoir le type de champ (son nom exa ct)
int, blob, char et l'option : binary, unsigned ...

antoine

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/DebFrFrenchLists
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact

François Cerbelle

15/01/2009 à 13:10

a écrit :

Après moultes réponses, (certes intéressantes),
je n'ai toujours pas la réponse, à savoir le type de champ (son nom exact)
int, blob, char et l'option : binary, unsigned ...

Peut être parce qu'il n'y a pas de réponse universelle. Plusieurs
solutions sont possible, c'est à toi et uniquement à toi de choisir
celle qui sera la meilleure pour ton besoin.

Il faut que tu connaisses précisément ton besoin et précisément les
avantages/inconvénient/possibilités offerts par chaque type/format
d'enregistrement des colonnes. La meilleure source reste le site
officiel de mySQL, sur lequel tu trouveras exactement les particularités
de chaque type.

Sinon, tu peux demander à l'intervenant chargé des formations à Starinux
! ;-)

Fanfan

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/DebFrFrenchLists
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact

mouss

17/01/2009 à 14:40

Stephane Bortzmeyer a écrit :

On Mon, Jan 12, 2009 at 05:05:54PM +0100,
wrote
a message of 17 lines which said:

Il s'agit d'adresses IP (IPV4) enregistrées avec les points :
A.B.C.D

Drôle d'idée d'utiliser la forme texte, d'autant plus qu'elle est mal
normalisée en IPv4 (A.B.C.D n'est pas la seule notation
possible).
Pourquoi ne pas plutôt stocker la forme binaire, qui permet
des comparaisons et du masquage ?

la forme texte a un interet: pas besoin de inet_aton/inet_pton lorsqu'on
veut chercher une IP qu'on a en format texte. et si on utilise un format
binaire, il faut faire attention à la representation (endian) si le
serveur mysql et la machine cliente sont différentes (une big endian et
une little endian).

donc, si la table est petite, et si on fait que de la recherche
"exacte", la représentation "texte" est très acceptable.

Quant à la normalisation, il suffit de mettre les "contraintes":
- il y a exactement 4 parties (pas de 127.1 pour dire 127.0.0.1, etc. de
toute façon, ces formes ne marchent plus comme avant, puisque dans une
table d'accès sendmail, 127.1 est vue comme 127.1.0.0/16).

- chaque "partie" est un nombre entre 0 et 255, utilisant la notation
"normale" des entiers: pas de "0" au début sauf pour le nombre 0
lui-même. En gros, pas de "012" ni de "01".

Cela dit, je suis d'accord que la représentation binaire est préférable.
et on peut utiliser un trigger pour la conversion au moment de
l'insertion, une view pour "la lisibilité", ... etc.

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/DebFrFrenchLists
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact

type d'un champ mysql

8 réponses

Veuillez sélectionner un problème