Non, ça n'a rien de monstrueux.
Pour une base de données qui ne sera vraisemblablement jamais fusionnée avec une autre, de dimension moyenne, le type serial (4bit, ou bigserial à 8) vaut largement les UUID (qui ne sont pas supportés comme type de données par défaut dans postgresql me semble t il d'ailleurs).
Pour rappel, un entier naturel sur 4bit, ça couvre environ 4,3.10^9 déjà.
Les UUID sont des Universal Unique ID, ce qui signifie qu'ils sont universellement uniques. 2 enregistrements ne devraient jamais avoir le même ID dans le temps et l'espace. Ce qui permet de fusionner (entre autres hein) des bases sans craindre des problèmes de perte de données, de cohérence.
Les UUID sont généralement codés sur 16 bit, mais est ce vraiment utile pour des gens qui veulent utiliser OpenOffice pour faire un petit formulaire rapidos ?
Pour moi, ce bug est clairement un point gênant, compte tenu du type de base de données que l'on utilise avec OpenOffice.
[^] # Re: OOo
Posté par jerome . En réponse au journal MS Access pour linux?. Évalué à 2.
Pour une base de données qui ne sera vraisemblablement jamais fusionnée avec une autre, de dimension moyenne, le type serial (4bit, ou bigserial à 8) vaut largement les UUID (qui ne sont pas supportés comme type de données par défaut dans postgresql me semble t il d'ailleurs).
Pour rappel, un entier naturel sur 4bit, ça couvre environ 4,3.10^9 déjà.
Les UUID sont des Universal Unique ID, ce qui signifie qu'ils sont universellement uniques. 2 enregistrements ne devraient jamais avoir le même ID dans le temps et l'espace. Ce qui permet de fusionner (entre autres hein) des bases sans craindre des problèmes de perte de données, de cohérence.
Les UUID sont généralement codés sur 16 bit, mais est ce vraiment utile pour des gens qui veulent utiliser OpenOffice pour faire un petit formulaire rapidos ?
Pour moi, ce bug est clairement un point gênant, compte tenu du type de base de données que l'on utilise avec OpenOffice.