Ik kom van MySQL en in MySQL kun je AUTOINCREMENT gebruiken voor de unieke id van een rij als de primaire sleutel.
Ik vind dat er geen AUTOINCREMENT is in Postgresql, alleen SEQUENCE of UUID. Ik heb ergens gelezen dat we UUID kunnen gebruiken als de primaire sleutel van een tabel. Dit heeft als bijkomend voordeel dat het de ID van andere gebruikers maskeert (omdat ik API’s wil bouwen die de ID als parameter opnemen). Welke moet ik gebruiken voor Postgresql?
Antwoord 1, autoriteit 100%
Een sequencein PostgreSQL doet precies hetzelfde als AUTOINCREMENTin MySQL. Een sequenceis efficiënter dan een uuidomdat deze 8 bytes is in plaats van 16 voor de uuid. U kunt een uuidals primaire sleutel gebruiken, net als de meeste andere gegevenstypen.
Ik zie echter niet in hoe dit zich verhoudt tot het maskeren van een gebruikers-ID. Als u de ID van een bepaalde gebruiker wilt maskeren voor andere gebruikers, moet u de tabelrechten zorgvuldig beheren en/of de ID hashen met – bijvoorbeeld – md5().
Als je een tabel met gebruikersgegevens wilt beschermen tegen snuffelende hackers die andere ID’s proberen te raden, dan is het type uuideen uitstekende keuze. Pakket uuid-osspheeft verschillende smaken. De versie 4 is dan de beste keuze aangezien deze 122 willekeurige bits heeft (de andere 6 worden gebruikt voor identificatie van de versie). U kunt een primaire sleutel als volgt maken:
id uuid PRIMARY KEY DEFAULT uuid_generate_v4()
en dan heb je er nooit meer omkijken naar.
PostgreSQL 13+
Je kunt nu de ingebouwde functie gebruiken gen_random_uuid()om een willekeurige UUID van versie 4 te krijgen.
Antwoord 2, autoriteit 26%
U kunt UUID als primaire sleutel in uw tabel gebruiken, omdat deze uniek is. Houd er echter rekening mee dat UUID iets meer ruimte inneemt in vergelijking met SEQUENCE. En ze zijn ook niet erg snel. Maar ja, ze zijn zeker uniek en daarom krijgt u gegarandeerd consistente gegevens.
U kunt ook verwijzen naar:
Antwoord 3, autoriteit 21%
Ik heb jarenlang applicaties voor databases ontwikkeld met PK’s en FK’s als numerieke sequentiële waarden. Dit heeft perfect gewerkt, maar de afgelopen jaren realiseerden we ons dat het gebruik van sequentiële ID’s in onze API’s bij het maken van cloudapplicaties waarbij informatie tussen applicaties wordt uitgewisseld en we integraties tussen verschillende applicaties zullen laten ontwikkelen, een inspanning kost.
In sommige applicaties moeten we de ID (van de doelapplicatie) vinden die via de API-aanroep moet worden verzonden, aan de andere kant hebben onze databasetabellen, in al onze applicaties, naast de sequentiële PK / FK-kolom, een UUID-kolom, die niet werd gebruikt in API-aanroepen. In dit scenario hebben we besloten om de API’s te herschrijven, zodat de UUID-kolom werd gebruikt.
Dit loste een aantal van de problemen op omdat de gegevens van een van onze desktopapplicaties naar een andere cloudapplicatie zouden worden gemigreerd. Deze cloudapplicatie gebruikte ook PK/FK-kolommen. Bij het migreren van deze gegevens moesten we de waarden van de PK’s / FK’s wijzigen voor nieuwe reeksen omdat de reeksen konden botsen tussen de waarden van de desktop-applicatie en de waarden van de cloud-applicatie. Met dit in gedachten hebben we ervoor gekozen om de PK’s / FK’s van de cloud-applicatie naar UUID te schakelen, aangezien gegevens afkomstig van de desktop-applicatie een UUID-kolom hadden.
Het probleem was toen om de cloudtoepassingstabellen te converteren door de INT-kolommen (PK’s en FK’s) in UUID-kolommen te veranderen zonder de tabelinformatie te verliezen. Dat was een grote taak, maar het werd gemakkelijker gemaakt omdat ik uiteindelijk een applicatie heb gebouwd die deze verandering gemakkelijker maakt. De applicatie verandert elke PK / FK integer-kolom in UUID, waarbij de gegevens en relaties behouden blijven. Geïnteresseerden volgen de link: