Vous n'êtes pas identifié(e).
Pages : 1
Bonjour,
je souhaitais savoir si dans la version 9 de PostgreSQL les entiers non signés sont gérés ?
est-ce uint? smallint unsigned ?
merci de m'aider rapidement,
Lise
Hors ligne
Bonjour,
cette page devrait t'aider 
http://docs.postgresql.fr/9.0/datatype.html
Pourquoi tu poses ta question dans la section Site postgresql.fr ?
Dernière modification par kenrio (02/05/2011 15:48:59)
Hors ligne
je connais cette page et je n'ai pas trouver réponse...
certes, pour il existe uint mais il concerne qui? les entiers non signés sur un octet seulement ou même sur 4 voir 8 octets...?
j'ai vu postgreSQL j'ai mi la discussion...
Hors ligne
merci tout de même
Hors ligne
je trouve ça :
smallint 2 octets entier de faible étendue de -32768 à +32767
integer 4 octets entier habituel de -2147483648 à +2147483647
bigint 8 octets grand entier de -9223372036854775808 à 9223372036854775807
donc entier signé
mais quel est l'interet d' avoir un entier non signé dans une base de données ? on s'en fou non ? je suis pas un maître en la matière mais qui peut le plus peut le moins non ?
Hors ligne
oui ça j'avais trouvé mais ce n'est pas ce que je recherche
un entier non signé sur 4 octets par exemple va de 0 à 4294967295 valeurs
l'intéret? on ne reserve pas de bit pour stocker le signe
tout dépend de ta base de données !
merci quand même! je crois que ça n'existe pas sous PostgreSQL
Hors ligne
Il n'y a pas d'entier non signé sous Postgresql.
Si vous avez besoin d'entiers si grands, utilisez des bigint. Ou bien stockez les signés avec un décalage, si c'est vraiment si important pour vous… ou encore définissez un nouveau type, mais ça devient plus sportif…
L'explication de pourquoi il n'y a pas d'unsigned int dans le message ci-dessous:
http://archives.postgresql.org/pgsql-ha … g01160.php
Marc.
Hors ligne
ok merci pour le lien d'explication!
mais j'ai laissé tomber les entiers non signés...
a bientot !
Lise
Hors ligne
Contrairement à MySQL, PostgreSQL est un SGBD relationnel fortement normatif. Il respecte donc les types SQL et parmi ces types de données il n'existe aucun entier non signé, car cela fait partie de la sémantique des données que l'on obtient par des contraintes, notamment de domaine.
Or MySQL implémente très mal les contraintes, certaines toujours pas, et les quelques unes que MySQL implémente, ce n'est que depuis peu.
Pour palier ces défauts, MySQL à rajouter des types de données spécifiques et farfelus comme les entiers non signés, qui n'ont pas leur place dans un SGBDR.
Pour faire ce que vous demandez il suffit de créer un DOMAIN SQL.
Exemple :
CREATE DOMAIN UNSIGNED_INT
AS INT
CONSTRAINT CK_POSITIVE
CHECK (VALUE >= 0 );Dès lors vous pouvez utiliser UNSIGNED_INT comme n'importe quel type SQL. Exemple :
CREATE TABLE T (I UNSIGNED_INT);test avec insertion d'une bonne valeur :
INSERT INTO T VALUES (25)test avec insertion d'une mauvaise valeur :
INSERT INTO T VALUES (-7)ERREUR: la valeur pour le domaine unsigned_int viole la contrainte de vérification « ck_positive »
Tout cela fait partit intégrante du langage SQL de base...
Bref, apprenez SQL... Mon lire comme mon site web peuvent vous y aider ! http://sqlpro.developpez.com/
A +
Dernière modification par SQLpro (06/05/2011 23:45:56)
Frédéric Brouard, alias SQLpro, ARCHITECTE DE DONNÉES, Expert langage SQL
Le site sur les SGBD relationnel et langage SQL : http://sqlpro.developpez.com/
Modélisation de données, conseil, expertise, audit, optimisation, tuning, formation
* * * * * Enseignant CNAM PACA, ISEN Toulon, CESI Aix en Provence * * * * *
Hors ligne
Dites, SQLPro, pourquoi ne pas mettre «Bref, apprenez SQL... Mon livre comme mon site web peuvent vous y aider ! http://sqlpro.developpez.com/» directement dans votre signature, puisque vous la mettez dans presque chacun de vos posts ? Vous gagneriez du temps ? 
Par ailleurs, comme expliqué dans mon post au dessus, la principale raison de l'absence d'entiers non signés dans PostgreSQL n'est pas le respect «bête et méchant» de SQL, c'est avant tout un problème de gestion des casts. Difficile de savoir, quand quelqu'un saisit un entier, s'il en veut un signé, ou un non-signé. Donc c'est tout le temps signé et on n'en parle plus, ça évite les problèmes d'interprétation. PostgreSQL n'a jamais été opposé à l'ajout de types qui ne sont pas dans le standard SQL (encore heureux…).
Marc.
Hors ligne
Dites, SQLPro, pourquoi ne pas mettre «Bref, apprenez SQL... Mon livre comme mon site web peuvent vous y aider ! http://sqlpro.developpez.com/» directement dans votre signature, puisque vous la mettez dans presque chacun de vos posts ? Vous gagneriez du temps ?
Parce que cela n'est pas systématique... :-) Tout n'est pas dit dans SQL. Par exemple les index ça n'existe pas en SQL !
Par ailleurs, comme expliqué dans mon post au dessus, la principale raison de l'absence d'entiers non signés dans PostgreSQL n'est pas le respect «bête et méchant» de SQL, c'est avant tout un problème de gestion des casts. Difficile de savoir, quand quelqu'un saisit un entier, s'il en veut un signé, ou un non-signé. Donc c'est tout le temps signé et on n'en parle plus, ça évite les problèmes d'interprétation. PostgreSQL n'a jamais été opposé à l'ajout de types qui ne sont pas dans le standard SQL (encore heureux…).
Non, vous faites fausse route. Rien n'empêche de tenter un cast de 'ABC' en INT et donc de recevoir une erreur...
Le respect des normes est plus important que l'ajout bête et méchant de fonctionnalités inopinées (ce genre de merde que l'on trouve systématiquement dans MySQL par exemple), car SQL le permet via d'autres moyens comme CREATE DOMAIN (depuis la norme SQL 2 de 1992) et comme le CREATE TYPE (de la norme SQL:1999).
De plus, sur la norme que PostGreSQL respecte assez bien (et depuis son origine que j'ai suivi dès la version 2 de 1990 avec les travaux de Michael Stonebraker), je suis toujours stupéfait de voir des commentaires "anti" norme, surtout de la part de ceux qui prônent le libre. N'oubliez pas que la première des libertés c'est avant tout de ne dépendre de rien... Or pour ne pas dépendre il faut que les choses soient interchangeable. C'est pourquoi les normes et les standards (ceux d'Internet à travers notamment les RFC) sont très importantes... Souvenez vous du klingonien (http://www.dicosmo.org/Piege/cybersnare/piege.html) !
Autrefois, il n'y avait pas de norme. Avant la révolution industrielle au 18e siècle, chaque seigneur imposait sur son territoire ses propres mesures de poids de volume que le commerçant devait acheter fort cher auprès du seigneur. C'était une forme d'impôt.
Les entreprises ont été obligée de se conformer à des standards et des normes, car cette situation à conduit à de nombreux accident mortels lors de l'avènement du chemin de fer :
- chaque région ayant ses pas de filetages, ses écrous et ses boulons, il a fallut dépenser trois fois plus pour adapter les éléments de structure au fur et à mesure de l'avancé des rails, ceci était contre productif....
- chaque village ayant son heure propre, les premiers trains se télescopaient et il en résultait des accidents mortels.
Aujourd'hui hélas on trouve de nombreuses personnes qui avance le soit disant carcan de la norme pour faire n’importe quoi. Je ne peut pas m'empêcher de penser que ces gens là feront d'excellent tyrans !
A +
Frédéric Brouard, alias SQLpro, ARCHITECTE DE DONNÉES, Expert langage SQL
Le site sur les SGBD relationnel et langage SQL : http://sqlpro.developpez.com/
Modélisation de données, conseil, expertise, audit, optimisation, tuning, formation
* * * * * Enseignant CNAM PACA, ISEN Toulon, CESI Aix en Provence * * * * *
Hors ligne
Bon, je dois dire que je ne suis fan ni des parallèles ferroviaires, ni des parallèles avec les voitures pour essayer d'expliquer des choses. Ni de parler de tyrannie pour si peu… on n'en est plus à l'uniformisation des poids et mesures en europe. Même si en plomberie ou en électricité, mais bon je m'égare…
En tout cas, le respect de la norme en lui même n'est pas vraiment quelque chose qu'on constate dans l'historique de développement des bases de données relationnelles. Entre autres quand la norme est en retard (l'exemple le plus flagrant est évidemment les jointures externes, qui ont eu autant de syntaxes que de moteurs l'implémentant, avant que ça ne soit enfin normalisé), ce qui a à peu près toujours été le cas à ma connaissance pour la normalisation. Et heureusement que le respect de la norme n'a pas empêché l'apparition initiale de ces syntaxes, les gens avaient des problèmes à résoudre à l'époque, que la norme ne permettait pas.
Évidemment, de là à rajouter un type non-signé à la base parce qu'on gaspille un bit de moins, il y a un pas que je ne franchirai pas. Mais l'argument principal des développeurs PostgreSQL (je ne l'invente pas, le lien est un mail de Tom Lane), ce n'est pas que l'entier non-signé n'est pas dans la norme. C'est que ça pose un problème syntaxique, lié à la détection des types castés automatiquement.
Implémenter quelque chose qui est déjà dans une norme sans respecter la norme c'est une chose (une chose lamentable, pour être précis). Implémenter quelque chose qui n'est pas dans la norme du tout, c'en est une autre à mon avis. À moins que respecter la norme SQL impose de n'utiliser que les types qu'elle n'a a défini, ce dont je doute fortement… mais vu la taille du pavé qu'est la norme SQL, il est toujours envisageable d'avoir raté quelque chose. Si vous voulez vraiment qu'on reprenne votre parallèle ferroviaire, avec votre façon de raisonner, personne n'aurait pu inventer le filetage du tout… puisqu'il n'y avait pas de norme pour en définir le pas. Évidemment, mon argument ne tient pas si la norme SQL impose que tous les nombres soient signés.
Mais on perd notre temps à discuter sur ce point de détail à mon avis. Je suis tout à fait d'accord sur le fait que les entiers non-signés ne servent à quasiment rien, puisqu'il suffit de les déclarer comme un domaine. C'est juste «pas de chance» quand on veut stocker du numérique inférieur à 2^32 mais supérieur à 2^31, on est obligés de doubler la taille de stockage de la colonne pour passer en entier long. Mais implémenter les entiers non-signés a un coût évidemment non justifié pour ce cas vraiment particulier. Mais je suis très content d'avoir quelques types de données non normalisés dans PostgreSQL, et qui me rendent bien service (cidr par exemple, pas tant pour le gain de place que pour les opérateurs). Et tant pis si je suis un tyran parce que ce n'est pas dans la norme.
Marc.
Hors ligne
En tout cas, le respect de la norme en lui même n'est pas vraiment quelque chose qu'on constate dans l'historique de développement des bases de données relationnelles. Entre autres quand la norme est en retard (l'exemple le plus flagrant est évidemment les jointures externes, qui ont eu autant de syntaxes que de moteurs l'implémentant, avant que ça ne soit enfin normalisé), ce qui a à peu près toujours été le cas à ma connaissance pour la normalisation.
Ta connaissance est donc mauvais, car il y a beaucoup de choses dans la norme qui ont mis des lustres à être implémenté. Quelques exemples :
1) le DATALINK (rnorme SQL 1999) apparait pour la première fois dans IBM DB2 en 2002, dans SQL Server en 2008
2) les contraintes defférables date de la norme de 1992... Elles ont été implémentée qu'a partir de la version 8 d'Oracle et très récemment dans PG (mais uniquement pour les FK)
3) les assertions, n'ont jamais été implémentées à ce jour, sauf dans certains SGBDR confidentiel (Ocelot de Peter Gulutzan).
...
Et heureusement que le respect de la norme n'a pas empêché l'apparition initiale de ces syntaxes, les gens avaient des problèmes à résoudre à l'époque, que la norme ne permettait pas.
Sauf que la plupart du temps les solutions était incomplètes ou ineptes. Exemple la récursivité avec CONNECT BY Prior dans Oracle qui ne permet pas le parcours de graphe, les jointures externe *= de Sybase qui sont mathématiquement fausses.
Mais je suis très content d'avoir quelques types de données non normalisés dans PostgreSQL, et qui me rendent bien service (cidr par exemple, pas tant pour le gain de place que pour les opérateurs). Et tant pis si je suis un
tyran parce que ce n'est pas dans la norme.
Intéressant, certes, mais parfaitement idiot... En effet puisqu'il y a le CREATE DOMAIN, alors autant s'en servir. Par exemple dans SQL Server il y a un domaine sysname qui est un NVARCHAR(128) pour représenter, conformément à la norme les noms des objets SQL.
Il aurait donc fallu simplement prévoir ces types en tant que domaine pré établis dans la base !
Encore une fois, la norme est beaucoup plus intelligente que la plupart des gens le suppose... C'est normal qu'elle soit très intelligente car ce sont l'ensemble des éditeurs des différents SGBDR qui y participent. Et non pas quelques savants dans leur tout d'ivoire. Et pour valider une syntaxe il faut en étudier tous les aspects ce qui est rarement fait par un seul éditeur, trop cotent de tirer la couverture à lui pour faire en sorte de ferrer le développeur !
A +
Dernière modification par SQLpro (08/05/2011 13:35:51)
Frédéric Brouard, alias SQLpro, ARCHITECTE DE DONNÉES, Expert langage SQL
Le site sur les SGBD relationnel et langage SQL : http://sqlpro.developpez.com/
Modélisation de données, conseil, expertise, audit, optimisation, tuning, formation
* * * * * Enseignant CNAM PACA, ISEN Toulon, CESI Aix en Provence * * * * *
Hors ligne
Merci pour la liste d'insultes. C'est toujours un plaisir de discuter avec quelqu'un de ton espèce. Je sais déjà que tu vas argumenter que tu n'as insulté personne, que ton expression est juste virile, comme tu l'as déjà fait. N'hésite pas à 'renforcer' encore ta 'pensée' avec une citation à deux balles ou bien une allégorie ferroviaire.
Trois contre-exemples n'invalident absolument pas ce que j'ai dit. Il y a pas mal de choses qui ont été implémentées avant d'entrer dans la norme. Quand on a besoin de la fonctionnalité et qu'elle n'est pas encore normalisée, on fait quoi ? On attend 5 ans pour la norme suivante ? Non, et encore heureux. Évidemment, les implémentations faites avant la norme sont moins bonnes que la norme, puisqu'elles ne bénéficient pas de l'expérience, justement souvent récoltée par ces implémentations de test. Le CONNECT BY en est un bon exemple. Il a permis de faire des requêtes récursives, à l'époque. Et même si c'étaiit incomplet, c'était mieux que rien (la preuve ? les utilisateurs s'en sont servi). Déclarer, du haut de sa propre tour d'ivoire, que les développeurs d'Oracle qui l'ont créé sont ineptes, c'est simplement grotesque.
Maintenant, je vais faire ce que tout le monde devrait à mon avis faire avec toi. Je vais t'ignorer. L'insulte n'est pas un mode d'expression, malgré ce que tu sembles penser. Et il y a suffisamment de personnes intéressantes sur ce forum pour que j'arrête de perdre mon temps avec toi. En espérant que tu ne fasses pas fuir toutes ces personnes.
Marc.
Hors ligne
Je ne vais pas rentrer dans cette conversation (entre SQLpro et Marc) car elle ne m'intéresse pas. Je viens juste corriger une erreur. Avec PostgreSQL, il est possible de différer les clés étrangères, les contraintes uniques et les clés primaires.
Guillaume.
Hors ligne
Je ne vais pas rentrer dans cette conversation (entre SQLpro et Marc) car elle ne m'intéresse pas. Je viens juste corriger une erreur. Avec PostgreSQL, il est possible de différer les clés étrangères, les contraintes uniques et les clés primaires.
Mea culpa, j'en étais pas encore à la version 9 ! (je ne l'ai installé que depuis quelques jours !).
A +
Frédéric Brouard, alias SQLpro, ARCHITECTE DE DONNÉES, Expert langage SQL
Le site sur les SGBD relationnel et langage SQL : http://sqlpro.developpez.com/
Modélisation de données, conseil, expertise, audit, optimisation, tuning, formation
* * * * * Enseignant CNAM PACA, ISEN Toulon, CESI Aix en Provence * * * * *
Hors ligne
Je viens de relire ce vieux post, et finalement ce qui m'étonne le plus, c'est qu'un tel échange provienne d'une question posée par ma stagiaire... qui a dû être bien étonnée des réactions suscitées par son innoncente question.
Cdlt, Arnaud.
Hors ligne
Pages : 1