5.1 Panimula

Ang Internet ay puno ng dogmatic precepts tungkol sa kung paano dapat piliin at gamitin ang mga key sa relational database. Minsan nagiging holivars ang mga hindi pagkakaunawaan: dapat bang natural o artipisyal na mga susi ang gamitin? Auto-increment integer o UUID?

Matapos basahin ang animnapu't apat na artikulo, pag-ikot sa mga seksyon ng limang libro, at pagtatanong ng napakaraming tanong sa IRC at StackOverflow, ako (Joe "begriffs" Nelson, ang may-akda ng orihinal na artikulo) ay tila pinagsama-sama ang mga piraso ng puzzle at maaari na ngayong makipagkasundo sa mga kalaban. Maraming mga pangunahing pagtatalo ang aktwal na nagmumula sa hindi pagkakaunawaan ng pananaw ng ibang tao.

Hatiin natin ang problema at ibalik ito sa dulo. Una, itanong natin - ano ang "susi"?

Kalimutan natin sandali ang tungkol sa mga pangunahing key, interesado tayo sa isang mas pangkalahatang ideya. Ang susi ay isang column (column) o mga column na walang mga duplicate na value sa mga row . Gayundin, ang mga column ay dapat na irreducibly unique, ibig sabihin, walang subset ng mga column ang may ganitong uniqueness.

Ngunit una, ilang teorya:

pangunahing susi

Pangunahing susidirektang ginagamit upang tukuyin ang mga hilera sa isang talahanayan. Dapat itong sumunod sa mga sumusunod na paghihigpit:

  • Ang pangunahing susi ay dapat na natatangi sa lahat ng oras.
  • Dapat itong palaging naroroon sa talahanayan at may halaga.
  • Hindi nito dapat madalas na baguhin ang halaga nito. Sa isip, hindi nito dapat baguhin ang halaga .

Karaniwan, ang isang pangunahing key ay kumakatawan sa isang solong column ng isang talahanayan, ngunit maaari rin itong maging isang composite key na binubuo ng maraming mga column.

Composite key

Custom Key- isang kumbinasyon ng mga katangian (column) na natatanging tumutukoy sa bawat hilera ng talahanayan. Maaari itong maging lahat ng column, at marami, at isa. Sa kasong ito, ang mga linya na naglalaman ng mga halaga ng mga katangiang ito ay hindi dapat ulitin.

Potensyal na Susi

susi ng kandidato- kumakatawan sa pinakamababang composite key ng kaugnayan (talahanayan), iyon ay, isang hanay ng mga katangian na nakakatugon sa isang bilang ng mga kundisyon:

  • Irreducibility : Hindi ito maaaring bawasan, naglalaman ito ng pinakamababang posibleng hanay ng mga katangian.
  • Kakaiba : Dapat itong magkaroon ng mga natatanging halaga anuman ang pagbabago ng row.
  • Presence ng isang value : Hindi ito dapat magkaroon ng null value, ibig sabihin, dapat itong may value.

5.2 Ang kakaibang kaso ng mga pangunahing susi

Ang tinatawag naming "mga susi" sa nakaraang seksyon ay karaniwang tinutukoy bilang "mga susi ng kandidato." Ang terminong "kandidato" ay nagpapahiwatig na ang lahat ng naturang mga susi ay nakikipagkumpitensya para sa honorary na tungkulin ng "pangunahing susi" (pangunahing susi), at ang iba ay itinalagang "mga alternatibong susi" (mga alternatibong susi).

Nagtagal bago ang mga pagpapatupad ng SQL upang malampasan ang hindi pagkakatugma sa pagitan ng mga susi at ng relational na modelo, at ang pinakaunang mga database ay nakatuon sa mababang antas ng konsepto ng isang pangunahing susi. Ang mga pangunahing key sa naturang mga database ay kinakailangan upang matukoy ang pisikal na lokasyon ng isang row sa sequential storage media. Narito kung paano ito ipinaliwanag ni Joe Celko:

Ang terminong "key" ay nangangahulugang isang file sort key, na kinakailangan upang maisagawa ang anumang mga operasyon sa pagpoproseso sa isang sequential file system. Isang set ng mga punched card ang binasa sa isa at isang order lamang; imposibleng bumalik. Ginaya ng mga maagang tape drive ang parehong gawi at hindi pinapayagan ang bidirectional na pag-access. Iyon ay, kinakailangan ng orihinal na Sybase SQL Server na "i-rewind" ang talahanayan sa simula upang basahin ang nakaraang hilera.

Sa modernong SQL, hindi mo kailangang tumuon sa pisikal na representasyon ng impormasyon, mga relasyon sa modelo ng mga talahanayan, at ang panloob na pagkakasunud-sunod ng mga hilera ay hindi mahalaga. Gayunpaman, kahit ngayon ang SQL server bilang default ay lumilikha ng isang clustered index para sa mga pangunahing key at, ayon sa lumang tradisyon, pisikal na inaayos ang pagkakasunud-sunod ng mga hilera.

Sa karamihan ng mga database, ang mga pangunahing key ay isang bagay ng nakaraan, at nagbibigay ng kaunti pa kaysa sa isang pagmuni-muni o pisikal na lokasyon. Halimbawa, sa isang talahanayan ng PostgreSQL, ang pagdedeklara ng pangunahing key ay awtomatikong nagpapatupad ng isang hadlang NOT NULLat tumutukoy sa isang default na foreign key. Bilang karagdagan, ang mga pangunahing key ay ang mga gustong column para sa operator JOIN.

Ang pangunahing key ay hindi override ang posibilidad ng pagdedeklara ng iba pang mga susi. Kasabay nito, kung walang susi ang nakatalaga bilang pangunahin, gagana pa rin ang talahanayan ng maayos. Ang kidlat, sa anumang kaso, ay hindi tatama sa iyo.

Java webinar

5.3 Paghahanap ng mga natural na susi

Ang mga susi na tinalakay sa itaas ay tinatawag na "natural" dahil ang mga ito ay mga katangian ng modelong bagay na kawili-wili sa kanilang sarili, kahit na walang gustong gumawa ng susi mula sa mga ito.

Ang unang bagay na dapat tandaan kapag sinusuri ang isang talahanayan para sa mga posibleng natural na susi ay subukang huwag maging masyadong matalino. Ang user sqlvogel sa StackExchange ay nagbibigay ng sumusunod na payo:

Ang ilang mga tao ay nahihirapang pumili ng isang "natural" na susi dahil sila ay may mga hypothetical na sitwasyon kung saan ang isang partikular na susi ay maaaring hindi natatangi. Hindi nila naiintindihan ang mismong kahulugan ng gawain. Ang kahulugan ng susi ay upang tukuyin ang panuntunan ayon sa kung saan ang mga katangian sa anumang oras ay dapat at palaging magiging natatangi sa isang partikular na talahanayan. Ang talahanayan ay naglalaman ng data sa isang tiyak at mahusay na nauunawaan na konteksto (sa "paksa na lugar" o "lugar ng diskurso"), at ang tanging kahulugan ay ang paggamit ng paghihigpit sa partikular na lugar.

Ipinapakita ng pagsasanay na kinakailangang magpakilala ng isang pangunahing hadlang kapag ang column ay natatangi sa mga available na halaga at mananatili ito sa mga malamang na sitwasyon. At kung kinakailangan, ang paghihigpit ay maaaring alisin (kung ito ay nakakaabala sa iyo, pagkatapos ay sa ibaba ay pag-uusapan natin ang tungkol sa pangunahing katatagan.)

Halimbawa, ang isang database ng mga miyembro ng hobby club ay maaaring magkaroon ng uniqueness sa dalawang column - first_name, last_name. Sa isang maliit na halaga ng data, ang mga duplicate ay hindi malamang, at bago lumitaw ang isang tunay na salungatan, ito ay lubos na makatwiran na gumamit ng gayong susi.

Habang lumalaki ang database at tumataas ang dami ng impormasyon, maaaring maging mas mahirap ang pagpili ng natural na susi. Ang data na iniimbak namin ay isang pagpapasimple ng panlabas na katotohanan, at hindi naglalaman ng ilang aspeto na nagpapakilala sa mga bagay sa mundo, gaya ng kanilang mga coordinate na nagbabago sa paglipas ng panahon. Kung ang isang bagay ay walang anumang code, paano mo masasabi ang dalawang lata ng inumin o dalawang kahon ng oatmeal bukod sa kanilang spatial arrangement o bahagyang pagkakaiba sa timbang o packaging?

Iyon ang dahilan kung bakit ang mga katawan ng standardisasyon ay gumagawa at naglalapat ng mga natatanging marka sa mga produkto. Ang mga sasakyan ay nakatatak ng Vehicle Identification Number (VIN) , ang mga aklat ay naka-print gamit ang mga ISBN , at ang food packaging ay may mga UPC . Maaari kang tumutol na ang mga numerong ito ay tila hindi natural. Kaya bakit ko sila tinatawag na natural na mga susi?

Ang pagiging natural o artificiality ng mga natatanging katangian sa isang database ay nauugnay sa labas ng mundo. Ang isang susi na artipisyal noong ito ay nilikha sa isang pamantayang katawan o ahensya ng gobyerno ay nagiging natural sa atin, dahil ito ay nagiging pamantayan sa buong mundo at/o nakalimbag sa mga bagay.

Maraming industriya, pampubliko, at internasyonal na pamantayan para sa iba't ibang paksa, kabilang ang mga pera, wika, instrumento sa pananalapi, kemikal, at medikal na diagnosis. Narito ang ilan sa mga halaga na kadalasang ginagamit bilang natural na mga susi:

  • ISO 3166 country code
  • ISO 639 na mga code ng wika
  • Mga code ng pera ayon sa ISO 4217
  • Mga simbolo ng stock ISIN
  • UPC/EAN, VIN, GTIN, ISBN
  • mga pangalan sa pag-login
  • mga email address
  • mga numero ng silid
  • mac address ng network
  • latitude, longitude para sa mga punto sa ibabaw ng Earth

Inirerekomenda ko ang pagdedeklara ng mga susi hangga't maaari at makatwiran, marahil kahit na maramihang mga susi sa bawat talahanayan. Ngunit tandaan na ang lahat ng nasa itaas ay maaaring may mga pagbubukod.

  • Hindi lahat ay may email address, bagama't ito ay maaaring katanggap-tanggap sa ilalim ng ilang kundisyon ng database. Gayundin, binabago ng mga tao ang kanilang mga email address paminsan-minsan. (Higit pa sa key stability mamaya.)
  • Ang mga simbolo ng stock ng ISIN ay nagbabago paminsan-minsan, halimbawa, ang mga simbolo na GOOG at GOOGL ay hindi tumpak na naglalarawan sa muling pagsasaayos ng kumpanya mula sa Google patungo sa Alphabet. Minsan maaaring lumitaw ang pagkalito, tulad ng sa TWTR at TWTRQ, ang ilang mga mamumuhunan ay nagkamali na binili ang huli sa panahon ng Twitter IPO.
  • Ang mga numero ng Social Security ay ginagamit lamang ng mga mamamayan ng US, may mga paghihigpit sa privacy, at muling ginagamit pagkatapos ng kamatayan. Bilang karagdagan, pagkatapos ng pagnanakaw ng mga dokumento, ang mga tao ay makakakuha ng mga bagong numero. Sa wakas, ang parehong numero ay maaaring makilala ang parehong tao at isang income tax identifier.
  • Ang mga zip code ay isang mahirap na pagpipilian para sa mga lungsod. Ang ilang mga lungsod ay may isang karaniwang index, o vice versa, mayroong ilang mga index sa isang lungsod.

5.4 Mga artipisyal na key

Dahil ang susi ay isang haligi na may mga natatanging halaga sa bawat hilera, ang isang paraan upang malikha ito ay ang mandaya - maaari kang magsulat ng mga gawa-gawang natatanging halaga sa bawat hilera. Ito ay mga artipisyal na key: inimbentong code na ginamit upang sumangguni sa data o mga bagay.

Napakahalaga na ang code ay nabuo mula sa database mismo at hindi alam ng sinuman maliban sa mga gumagamit ng database. Ito ang pinagkaiba ng mga artipisyal na key mula sa standardized na natural na mga key.

Bagama't may kalamangan ang mga natural na key sa pagprotekta laban sa mga duplicate o hindi pare-parehong mga row sa isang table, ang mga artipisyal na key ay kapaki-pakinabang dahil ginagawang mas madali para sa mga tao o iba pang mga system na sumangguni sa row, at pinapabilis nila ang mga paghahanap at pagsali dahil hindi sila gumagamit. string (o multi-column) na paghahambing. mga key.

Mga kahalili

Ang mga artipisyal na key ay ginagamit bilang mga anchor - gaano man ang pagbabago ng mga panuntunan at column, palaging makikilala ang isang row sa parehong paraan. Ang artipisyal na susi na ginamit para sa layuning ito ay tinatawag na "kapalit na susi" at nangangailangan ng espesyal na atensyon. Isasaalang-alang namin ang mga kahalili sa ibaba.

Ang mga non-surrogate na artipisyal na key ay kapaki-pakinabang para sa pagtukoy ng isang row mula sa labas ng database. Ang isang artipisyal na key ay panandaliang kinikilala ang isang data o bagay: maaari itong tukuyin bilang isang URL, naka-attach sa isang invoice, idinikta sa telepono, nakuha mula sa isang bangko, o naka-print sa isang plaka ng lisensya. (Ang plaka ng lisensya ng sasakyan ay isang natural na susi para sa amin, ngunit dinisenyo ng pamahalaan bilang isang artipisyal na susi.)

Dapat piliin ang mga sintetikong key na may pagsasaalang-alang para sa mga posibleng paraan ng paghahatid upang mabawasan ang mga typo at error. Dapat tandaan na ang susi ay maaaring bigkasin, basahin ang naka-print, ipadala sa pamamagitan ng SMS, basahin ang sulat-kamay, i-type mula sa keyboard at i-embed sa isang URL. Bukod pa rito, ang ilang mga artipisyal na key, gaya ng mga numero ng credit card, ay naglalaman ng checksum upang kung mangyari ang ilang partikular na error, makikilala man lang ang mga ito.

Mga halimbawa:

  • Para sa mga plaka ng lisensya ng US, may mga panuntunan tungkol sa paggamit ng mga hindi maliwanag na character, gaya ng O at 0.
  • Ang mga ospital at parmasya ay dapat na maging maingat lalo na, dahil sa sulat-kamay ng mga doktor.
  • Nagpapadala ka ba ng confirmation code sa pamamagitan ng text message? Huwag lumampas sa GSM 03.38 character set.
  • Hindi tulad ng Base64, na nag-e-encode ng arbitrary na byte na data, ang Base32 ay gumagamit ng limitadong set ng character na maginhawa para sa mga tao na gamitin at pangasiwaan sa mas lumang mga computer system.
  • Ang mga proquint ay nababasa, nasusulat, at nabibigkas na mga identifier. Ang mga ito ay PRO-nouncable QUINT-uplets ng mga consonant at vowel na hindi malinaw na naiintindihan.

Tandaan na sa sandaling ipakilala mo ang iyong artipisyal na susi sa mundo, kakaibang magsisimulang bigyan ito ng espesyal na atensyon ng mga tao. Tingnan lamang ang mga plaka ng "mga magnanakaw" o sa sistema para sa paglikha ng mga nabigkas na pagkakakilanlan, na naging kasumpa-sumpa na automated curse generator.

Kahit na limitahan natin ang ating sarili sa mga numerical key, may mga bawal tulad ng ikalabintatlong palapag. Habang ang mga proquint ay may mas mataas na density ng impormasyon sa bawat binibigkas na pantig, ang mga numero ay maayos din sa maraming paraan: sa mga URL, pin-keyboard, at sulat-kamay na tala, hangga't alam ng tatanggap na ang susi ay mga numero lamang.

Gayunpaman, pakitandaan na hindi ka dapat gumamit ng sunud-sunod na pagkakasunud-sunod sa mga pampublikong numeric key, dahil nagbibigay-daan ito sa iyong maghanap ng mga mapagkukunan (/videos/1.mpeg, /videos/2.mpeg, at iba pa) at naglalabas din ng impormasyon tungkol sa numero datos. Maglagay ng Feistel net sa isang sequence ng mga numero at panatilihin ang uniqueness habang itinatago ang pagkakasunod-sunod ng mga numero.

Ang tanging argumento laban sa pagdedeklara ng mga karagdagang susi ay ang bawat bago ay nagdadala ng isa pang natatanging index at pinapataas ang halaga ng pagsulat sa talahanayan. Siyempre, depende ito sa kung gaano kahalaga sa iyo ang kawastuhan ng data, ngunit, malamang, ang mga susi ay dapat pa ring ipahayag.

Ito rin ay nagkakahalaga ng pagdedeklara ng ilang mga artipisyal na susi, kung mayroon man. Halimbawa, ang isang organisasyon ay may mga kandidato sa trabaho (Mga Aplikante) at mga empleyado (Mga Empleyado). Ang bawat empleyado ay dating isang kandidato, at tumutukoy sa mga kandidato sa pamamagitan ng kanilang sariling identifier, na dapat ding maging susi ng empleyado. Isa pang halimbawa, maaari mong itakda ang employee id at login name bilang dalawang key sa Employees.

5.5 Mga kahaliling susi

Tulad ng nabanggit na, ang isang mahalagang uri ng artipisyal na susi ay tinatawag na "kapalit na susi". Hindi ito kailangang maging maigsi at madadaanan tulad ng iba pang mga artipisyal na key, ngunit ginagamit ito bilang panloob na label na palaging nagpapakilala sa string. Ginagamit ito sa SQL, ngunit hindi ito tahasang ina-access ng application.

Kung pamilyar ka sa mga column ng system ng PostgreSQL, maaari mong isipin ang mga kahalili halos bilang parameter ng pagpapatupad ng database (tulad ng ctid), na, gayunpaman, ay hindi nagbabago. Ang kahalili na halaga ay pinipili nang isang beses bawat hilera at hindi na nagbago pagkatapos noon.

Ang mga surrogate key ay mahusay bilang mga foreign key, at ang mga cascading constraints ay dapat na tukuyin ON UPDATE RESTRICTupang tumugma sa immutability ng surrogate.

Sa kabilang banda, ang mga dayuhang key sa mga pampublikong ibinahaging key ay dapat na markahan ng ON UPDATE CASCADE, upang magbigay ng maximum na kakayahang umangkop. Ang isang cascading update ay tumatakbo sa parehong antas ng paghihiwalay gaya ng nakapaligid na transaksyon, kaya huwag mag-alala tungkol sa mga isyu sa concurrency - magiging maayos ang database kung pipili ka ng mahigpit na antas ng paghihiwalay.

Huwag gawing "natural" ang mga surrogate key. Kapag ipinakita mo na ang halaga ng kahalili na susi sa mga end user, o mas masahol pa, hayaan silang gumana sa halagang iyon (lalo na sa pamamagitan ng paghahanap), epektibo mong binibigyang halaga ang susi. Pagkatapos ang ipinapakitang susi mula sa iyong database ay maaaring maging natural na susi sa database ng ibang tao.

Ang pagpilit sa mga external na system na gumamit ng iba pang mga artipisyal na key na partikular na idinisenyo para sa paghahatid ay nagbibigay-daan sa amin na baguhin ang mga key na iyon kung kinakailangan upang matugunan ang pagbabago ng mga pangangailangan, habang pinapanatili ang panloob na integridad ng referential sa mga kahalili.

Auto-increment INT/BIGINT

Ang pinakakaraniwang gamit para sa mga surrogate key ay ang awtomatikong pagdaragdag ng "bigserial" na column , na kilala rin bilang IDENTITY . (Sa katunayan, sinusuportahan na ngayon ng PostgreSQL 10 ang konstruksyon ng IDENTITY, tulad ng Oracle, tingnan ang GUMAWA NG TABLE.)

Gayunpaman, naniniwala ako na ang isang auto-incrementing integer ay isang hindi magandang pagpipilian para sa mga surrogate key. Ang opinyon na ito ay hindi sikat, kaya hayaan mo akong magpaliwanag.

Mga disadvantages ng mga serial key:

  • Kung magsisimula ang lahat ng sequence sa 1 at unti-unting tumataas, magkakaroon ng parehong mga key value ang mga row mula sa iba't ibang talahanayan. Ang pagpipiliang ito ay hindi perpekto, mas mainam pa rin na gumamit ng magkakahiwalay na hanay ng mga susi sa mga talahanayan, upang, halimbawa, ang mga query ay hindi aksidenteng malito ang mga constant JOINat magbalik ng mga hindi inaasahang resulta. (Bilang kahalili, upang matiyak na walang mga intersection, maaaring buuin ng isa ang bawat sequence mula sa multiple ng iba't ibang prime, ngunit ito ay magiging mahirap.)
  • Ang tawag nextval() upang makabuo ng isang pagkakasunud-sunod sa ipinamahagi na SQL ngayon ay nagreresulta sa buong sistema na hindi maayos ang pag-scale.
  • Ang pagkonsumo ng data mula sa isang database na gumamit din ng mga sequential key ay magreresulta sa mga salungatan dahil ang mga sequential na halaga ay hindi magiging kakaiba sa mga system.
  • Mula sa isang pilosopikal na pananaw, ang sunud-sunod na pagtaas ng mga numero ay nauugnay sa mga lumang sistema kung saan ang pagkakasunud-sunod ng mga linya ay ipinahiwatig. Kung gusto mo na ngayong mag-order ng mga row, gawin ito nang tahasan gamit ang column ng timestamp o isang bagay na may katuturan sa iyong data. Kung hindi, ang unang normal na anyo ay nilabag.
  • Mahina ang dahilan, ngunit ang mga maiikling identifier na ito ay nakakatuksong sabihin sa isang tao.

UUID

Tingnan natin ang isa pang opsyon: gamit ang malalaking integer (128-bit) na nabuo ayon sa isang random na pattern. Ang mga algorithm para sa pagbuo ng mga unibersal na natatanging identifier (UUIDs) ay may napakababang posibilidad na pumili ng parehong halaga nang dalawang beses, kahit na tumatakbo sa dalawang magkaibang processor sa parehong oras.

Sa kasong iyon, ang mga UUID ay tila isang natural na pagpipilian upang gamitin bilang mga kahalili na susi, hindi ba? Kung gusto mong lagyan ng label ang mga row sa kakaibang paraan, walang tatalo sa kakaibang label!

Kaya bakit hindi lahat ay gumagamit ng mga ito sa PostgreSQL? Mayroong ilang mga contrived dahilan para dito at isang lohikal na isa na maaaring magtrabaho sa paligid, at ako ay magpapakita ng mga benchmark upang ilarawan ang aking punto.

Una, pag-uusapan ko ang tungkol sa malayong mga dahilan. Iniisip ng ilang tao na ang mga UUID ay mga string dahil nakasulat ang mga ito sa tradisyonal na hexadecimal notation na may gitling: 5bd68e64-ff52-4f54-ace4-3cd9161c8b7f. Sa katunayan, ang ilang mga database ay walang compact (128-bit) na uri ng uuid, ngunit ang PostgreSQL ay mayroon at may sukat na dalawa bigint, ibig sabihin, kumpara sa dami ng iba pang impormasyon sa database, ang overhead ay bale-wala.

Ang mga UUID ay hindi rin patas na inaakusahan ng pagiging mahirap, ngunit sino ang magbibigkas sa kanila, mag-type ng mga ito, o magbabasa ng mga ito? Sinabi namin na makatuwiran para sa mga artipisyal na key na ipakita, ngunit walang sinuman (sa kahulugan) ang dapat makakita ng kahalili na UUID. Posible na ang UUID ay haharapin ng isang developer na nagpapatakbo ng mga SQL command sa psql upang i-debug ang system, ngunit hanggang doon na lang. At ang developer ay maaari ding sumangguni sa mga string gamit ang mas maginhawang mga key, kung ibinigay ang mga ito.

Ang tunay na problema sa mga UUID ay ang mataas na randomized na mga halaga ay humahantong sa pagsulat ng amplification dahil sa buong pahinang pagsusulat sa write-ahead log (WAL) . Gayunpaman, ang pagkasira ng pagganap ay talagang nakasalalay sa algorithm ng pagbuo ng UUID.

Sukatin natin ang write amplification . Sa totoo lang, ang problema ay nasa mas lumang mga file system. Kapag sumulat ang PostgreSQL sa disk, binabago nito ang "pahina" sa disk. Kung i-off mo ang power ng computer, karamihan sa mga file system ay mag-uulat pa rin ng matagumpay na pagsulat bago ligtas na maimbak ang data sa disk. Kung ang PostgreSQL ay walang kabuluhang nakikita ang naturang aksyon bilang nakumpleto, kung gayon ang database ay masisira sa panahon ng susunod na pag-boot ng system.

Dahil hindi mapagkakatiwalaan ng PostgreSQL ang karamihan sa mga operating system/filesystem/mga configuration ng disk upang makapagbigay ng pagpapatuloy, sine-save ng database ang buong estado ng binagong pahina ng disk sa isang write-ahead log na magagamit upang mabawi mula sa isang posibleng pag-crash. Ang pag-index ng mataas na randomized na mga halaga tulad ng mga UUID ay karaniwang nagsasangkot ng isang bungkos ng iba't ibang mga pahina ng disk at nagreresulta sa buong laki ng pahina (karaniwan ay 4 o 8 KB) na isinusulat sa WAL para sa bawat bagong entry. Ito ang tinatawag na full-page write (full-page write, FPW).

Ang ilang mga algorithm ng henerasyon ng UUID (gaya ng "snowflake" ng Twitter o uuid_generate_v1() sa uuid-ossp extension ng PostgreSQL) ay bumubuo ng monotonically pagtaas ng mga halaga sa bawat makina. Pinagsasama-sama ng diskarteng ito ang mga pagsusulat sa mas kaunting mga pahina ng disk at binabawasan ang FPW.

5.6 Mga konklusyon at rekomendasyon

Ngayong nakita na natin ang iba't ibang uri ng mga susi at mga gamit ng mga ito, gusto kong ilista ang aking mga rekomendasyon para sa paggamit ng mga ito sa iyong mga database.

Para sa bawat talahanayan:

  • Tukuyin at ideklara ang lahat ng natural na susi.
  • Gumawa ng surrogate key <table_name>_idng uri ng UUID na may default na value na uuid_generate_v1(). Maaari mo ring markahan ito bilang pangunahing susi. Kung idaragdag mo ang pangalan ng talahanayan sa identifier na ito, ito ay magpapasimple JOIN, i.e. tumanggap JOIN foo USING (bar_id)sa halip na JOIN foo ON (foo.bar_id = bar.id). Huwag ipasa ang susi na ito sa mga kliyente at huwag ilantad ito sa labas ng database.
  • Para sa mga intermediate na talahanayan na dumadaan sa JOIN, ideklara ang lahat ng foreign key column bilang isang solong composite primary key.
  • Opsyonal, magdagdag ng artipisyal na key na maaaring gamitin sa URL o iba pang string reference indication. Gumamit ng isang Feistel grid o pg_hashids upang itago ang mga auto-incrementing integer.
  • Tumukoy ng cascading constraint ON UPDATE RESTRICTgamit ang mga kahalili na UUID bilang mga foreign key at para sa mga artipisyal na foreign key ON UPDATE CASCADE. Pumili ng mga natural na key batay sa iyong sariling lohika.

Tinitiyak ng diskarteng ito ang katatagan ng mga panloob na susi habang pinapayagan at pinoprotektahan pa nga ang mga natural na susi. Bilang karagdagan, ang mga nakikitang artipisyal na susi ay hindi nakakabit sa anumang bagay. Ang pagkakaroon ng naunawaan ang lahat ng tama, hindi ka maaaring mabitin lamang sa "pangunahing mga susi" at gamitin ang lahat ng mga posibilidad ng paggamit ng mga susi.