(tout est objet, tout a un identifiant unique (oid)[...])
C'est faux depuis les version 8, voir avant. Les OID sont maintenant optionnels et leurs utilisation est fortement déconseillée.
Historiquement les OID sont sur 32bits, soit environ 4G possibilitées, ce qui n'est pas assez pour garantir une valeur unique de tout les objets d'une base pour peu qu'elle soit un peu imposante. Les objets sont toujours tous identifiables de manières unique mais par d'autres moyens, plus robustes et moins limités. Les tuples dans les tables doivent être identifiés par une clef primaire, à l'utilisateur de bien la définir.
Pourquoi ne pas avoir étendu les OID sur 64 bits, je ne suis pas sûr mais je vois bien des raisons:
- problème de performance sur les systèmes 32bits
- cela n'aurait que repousser la limite
- problème de compatibilité ascendante (les librairies et clients attendent des valeurs 32bits)
- etc...
[^] # Re: Concrètement...
Posté par Olivier Thauvin . En réponse au journal Introduction à PostgreSQL. Évalué à 1.
C'est faux depuis les version 8, voir avant. Les OID sont maintenant optionnels et leurs utilisation est fortement déconseillée.
Historiquement les OID sont sur 32bits, soit environ 4G possibilitées, ce qui n'est pas assez pour garantir une valeur unique de tout les objets d'une base pour peu qu'elle soit un peu imposante. Les objets sont toujours tous identifiables de manières unique mais par d'autres moyens, plus robustes et moins limités. Les tuples dans les tables doivent être identifiés par une clef primaire, à l'utilisateur de bien la définir.
Pourquoi ne pas avoir étendu les OID sur 64 bits, je ne suis pas sûr mais je vois bien des raisons:
- problème de performance sur les systèmes 32bits
- cela n'aurait que repousser la limite
- problème de compatibilité ascendante (les librairies et clients attendent des valeurs 32bits)
- etc...