Paghihiwalay
Ang hangganang pinapanatili ng database, hindi ng code
Bawat CRM ay nagmamalaking multi-tenant. Murang sabihin ang paghahabol; ang mahalaga ay kung aling layer ang humahawak ng hangganan. Kung ang sagot ay "lagyang idadagdag ng aming application ang tamang filter", ang garantiya ay kasing-ganda lamang ng pinakapagod na developer na minsang sumulat ng query.
Ang iKonekt ay multi-tenant mula pa sa unang migration at hindi idinagdag pagkatapos — tila pagmamalaki ito ngunit sa totoo ay pag-amin: halos imposibleng gawin nang kapani-paniwala ang pagdaragdag nito pagkatapos, at bawat sumubok ay may kwento.
Nasa database ang paghihiwalay. Bawat isa sa dalawampu't-anim na talahanayan ay may taglay na tenant na pinag-aari nito, at ang patakarang sumusuri dito ay tumatakbo sa bawat pagbasa at pagsulat, nasa ibaba nang lubos ng application. Ang query na nakalimot sa hangganan ay hindi nagbabalik ng mga customer ng iba. Walang itong ibinabalik.
Row-level security, sapilitan
Hindi kaugalian, hindi patakaran sa code review. Tinatanggihan ito ng database. Pitumpu't-dalawang patakaran, isinulat isa-isa sa halip na ginawa nang awtomatiko — dahil ang awtomatikong patakaran ay patakarang walang nagbasa.
Mga composite key
Ang isang child record ay tumutukoy sa tenant nito at sa parent nito nang magkasama, bilang pares. Ang ligaw na identifier mula sa maling kompanya ay hindi malulutas — hindi lamang ito wastong sanggunian.
Walang default tenant, kailanman
Ang kahilingang walang saklaw ay hindi tahimik na nagiging kahilingan para sa tenant zero. Nagtatapon ito bago pa umabot sa database. Walang mode na "unscoped" na maaaring makalimutang i-off.
Ang bug na hindi makapagpakilala ng sarili
Habang ginagawa ang trabaho sa tenancy, ang karamihan sa mga pagkakamali ay maingay. Bigyan ng parehong customer domain ang dalawang kompanya at agad tututol ang database, may error code at stack trace; aayusin mo ito bago magtanghalian.
May isang hindi tumutol. Ang talahanayan ng mga nababagong prompt override ay naka-key sa uri lamang ng prompt — hindi sa uri at tenant. Ang pangalawang kompanya na mag-e-edit ng sarili nilang kopya ay tahimik na mapapalitan ang sa una, sa pamamagitan ng lubos na wastong SQL, walang error, walang babala, at walang bumabagsak na test. Natukoy ito sa pamamagitan ng pagbasa sa bawat natitirang unique index pagkatapos baguhin ang isang key, isa-isa, sa hinala na may kapares ang maingay na mga ito.
Binabanggit namin ito dahil ito ang tapat na hugis ng gawaing ito. Ang paghihiwalay ay hindi feature na io-on lang; ito ay gawain ng pagbasa sa mga nakakabagot na bahagi ng schema sa palagay na mayroong hindi sang-ayon sa iyo roon.
Ang mga test, para sa tala: 942 sa kanila, pinapatakbo laban sa database na muling binuo mula sa wala sa bawat pagbabago. Wala sila upang patunayang matalino ang disenyo. Naroroon sila dahil ang mode ng pagkabigo ng partikular na disenyo na ito ay tahimik, at ang mga tahimik na pagkabigo ay kailangan ng taong sumisigaw para sa kanila.
Ano ang napapala ng karaniwang tao sa paghihiwalay
- Ang isang grupo ay maaaring magpatakbo ng ilang kompanya mula sa isang install, at ang isang nagbebenta sa isa ay hindi kailanman makakakita ng customer ng iba — hindi sa pamamagitan ng patakaran, kundi sa mismong disenyo.
- Ang partner programme, isang set ng prompts, isang pag-angkin sa isang customer: lahat ay naka-scope kada kompanya, kaya't ang configuration ng isang tenant ay hindi maaaring maging sa lahat.
- Ang isang kahilingan sa pagbura ay iginagalang sa loob ng isang hangganan sa halip na sa isang pinagsasamang tambak, at iyon ang nagpapadali sa tapat na pagsagot.
- At walang kailangang tandaan ang alinman dito. Iyon ang punto — ang isang garantiya na nakadepende sa pag-alala ay hindi garantiya.
Isa pang linya na hindi tungkol sa mga database
Bawat kapatid na serbisyo sa pamilya ay may sariling pinangalanang credential. Walang nakikipag-usap gamit ang pinagsasamang credential, kaya't walang serbisyo na maaaring aksidenteng kumilos bilang iba — isang maliit na disiplina na nagmula nang direkta sa pagkakaroon noon ng pinagsasamang token at hindi nasiyahan dito.
Ito ang parehong instinct ng patakaran sa database. Gawing imposible ang mali sa halip na hindi hinihikayat, at gagastusin mo ang iyong atensyon sa mga customer sa halip na sa pag-iingat.
- 126 na talahanayanBawat isa ay may dala nitong tenant, na naka-force ang check.
- 272 na patakaranIsinulat nang isa-isa, kaya't nabasa ng isang tao ang bawat isa.
- 3942 na pagsubokLaban sa isang database na muling itinayo mula sa wala, sa bawat pagbabago.
- 40 na default na tenantAng isang kahilingan na walang scope ay hindi kailanman umaabot sa data.
Sinukat sa live na build
“Palaging nag-fi-filter ang aming application ayon sa kompanya.”
Maraming ginagawa ang salitang “palagi” sa pangungusap na iyon.
Ilipat ang hangganan pababa sa database at ang nakalimutang WHERE clause ay magbabalik ng wala sa halip na mga customer ng iba. Ang isang walang lamang screen ay mas mabuting pagkabigo kaysa sa isang hindi komportableng pagpapakilala.
Para sa mga grupong nagpapatakbo ng ilang brand →