Wat is efficiënter smallint of character (10)?

Ik zou zeggen dat het toevoegen van een kunstmatige smallint primaire sleutel zou goedkoper zijn in termen van opslagruimte, als de tafel zorgvuldig is ontworpen.

Een smallint duurt 2 bytes, terwijl een character(10) (wat contra-intuïtief is, een varlena ) met ASCII-tekens, zal 14 bytes in beslag nemen.

In de tabel zouden de extra 2 bytes verspilling zijn, maar vergeet niet dat je een index hebt op de primaire sleutelkolom. De geïndexeerde waarde wordt dus eigenlijk twee keer opgeslagen:één keer in de tabel, één keer in de index.

Laten we omwille van de eenvoud tuple-headers en andere overhead negeren.

• Het gebruik van het ISBN als primaire sleutel kost 14 bytes extra per tabelrij.

• Een smallint toevoegen primaire sleutel voegt twee bytes toe aan de tabel en twee aan de index, waardoor er in totaal vier bytes worden toegevoegd.

Dus een smallint toevoegen primaire sleutel zou ruimte moeten besparen .

U moet problemen met de uitlijning niet negeren. Alle gegevenstypen worden opgeslagen op geheugenadressen die veelvouden zijn van bepaalde machten van twee. Dit wordt vereist door de architecturen van de processors. Een smallint heeft meestal uitlijning 2, character heeft uitlijning 1, terwijl bijvoorbeeld timestamp heeft uitlijning 8.

Dus als uw tabel is gedefinieerd als

CREATE TABLE book (
   id smallint PRIMARY KEY,
   issue_time timestamp with time zone,
   isbn character(10)
);

Dan zien de tabelgegevens er als volgt uit:

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |X|X|X|X|X|X| | | | | | | | | ... (ISBN omitted)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 id    padding     issue_time

De rij is uitgelijnd op een grens van 8 bytes en de zes bytes vanaf het einde als id naar het begin van issue_time zal leeg zijn "padding bytes".

Dus om er het beste van te maken, moet u overwegen in welke volgorde u de kolommen definieert.

Waarom dit alles in werkelijkheid niet erg relevant is:

Een tabel met 5000 of 10000 items is klein, wat er ook gebeurt.

Al het geld dat wordt besteed aan het optimaliseren van de ruimte hier, is op zijn best onnodige micro-optimalisatie.

Maar wat een slim idee op de planningstafel kan zijn, kan later gemakkelijk averechts werken:als je - anders dan je verwacht - 70000 boeken in de tafel wilt opslaan, zul je merken dat een smallint zal niet genoeg zijn, zelfs als u een negatieve id toestaat s. De pijn die u zult moeten doorstaan ​​wanneer u het gegevenstype van een primaire sleutel moet wijzigen en alle externe sleutels die ernaar verwijzen in een live systeem, zullen veel groter zijn dan het plezier dat u krijgt door zo'n 100 KB te besparen door slimme optimalisaties.