Blogi · 14. syyskuuta 2023 · Steve Simpson · Data-arkkitehtuuri

Steve Data Modeling: valintaluetteloista äärettömyyteen ja sen yli

Johdanto:

Tervetuloa uuteen opettavaiseen tietomallinnuksen jaksoon Steve’s Data Modeling -sarjassa! Tässä blogissa tutkimme valintaluetteloiden monipuolista käyttöä ja pohdimme tilanteita, joissa kehittyneempiin tietomallinnuksen tarpeisiin kannattaa harkita vaihtoehtoja.

Valintaluetteloiden ymmärtäminen

Valintaluettelot ovat ihanteellisia, kun kentällä on oltava joukko kiinteitä arvoja. Ne tarjoavat siistin käyttökokemuksen, mutta niillä on rajoituksensa:

Arvojen lisääminen vaatii korotetut ylläpito-oikeudet.
Uudet arvot on käyttöönotettava sandboxien kautta.

Tietojen validointivirheitä syntyy, jos kolmansien osapuolten integraatioiden arvoja ei ole lisätty Salesforceen etukäteen.

Valintaluetteloiden vaihtoehdot

Tässä joitakin harkittavia vaihtoehtoja:

Vaihtoehto 1: yleiset arvojoukot

Tämä on Salesforcen vakiovaihtoehto, ja samaa luetteloa voi käyttää useissa objekteissa.

Vaihtoehto 1, valintaluettelot ja yleiset arvojoukot. Etu: siisti käyttökokemus. Haitat: ylläpitäjän on lisättävä arvot, muutokset on otettava käyttöön sandboxeihin, ulkoiset järjestelmät aiheuttavat ongelmia, eikä arvolla voi olla liittyviä kenttiä

Yleiset arvojoukot sopivat parhaiten arvoille, joita käytetään useissa paikoissa. Sinulla voi olla esimerkiksi kaksi yleistä arvojoukkoa, ”putken koko” ja ”putken paksuus”, jotka tarjoavat käyttäjille siistin käyttöliittymän arvojen valintaan.

[caption id="" align=“alignnone” width=“1372”] Esimerkkiarvojoukot [/caption] [caption id="" align=“alignnone” width=“1814”] Esimerkkiarvot [/caption] [caption id="" align=“alignnone” width=“676”] Valinta luettelosta [/caption]

Vaihtoehto 2: tekstikentät

Tämä on pelkkä tekstikenttä ilman validointia.

Vaihtoehto 2, tekstikentät. Etu: ne hyväksyvät minkä tahansa arvon. Haitat: ei tietojen validointia ja huono käyttökokemus

Jos tietoarvot tuodaan integraatioiden kautta, voit harkita tekstikenttiä. Tällöin kuitenkin menetät validoinnin, ja käyttäjät voivat syöttää mitä tahansa, mikä voi johtaa epäjohdonmukaisuuteen.

Tämä voi olla vaihtoehto, jos kentät ovat Salesforcessa vain luku -tilassa ja vain näytät arvot.

[caption id="" align=“alignnone” width=“678”] Ei validointia [/caption]

Vaihtoehto 3: jaettu viiteobjekti

Vaihtoehto 3, jaettu viiteobjekti tietuetyypeillä ja tietuetyypin mukaan suodatetuilla hakusuhteilla. Edut: tietoja lisätään dynaamisesti, ja joitakin liittyviä kenttiä. Haitat: tietojen lataukset sandboxeissa, ja lähdeobjektissa on avain arvon sijaan

Tietojen latauksiin voi käyttää jaettua viiteobjektia, jolla on useita tietuetyyppejä. Tällä tavalla pääobjektiin luodaan kaksi hakusuhdetta, jotka viittaavat viiteobjektiin varsinaisten arvojen sijaan. Voit myös lisätä uusia arvoja dynaamisesti ilman ylläpito-oikeuksia, mikä lisää joustavuutta.

[caption id="" align=“alignnone” width=“1462”] Tietuetyyppien käyttö [/caption] [caption id="" align=“alignnone” width=“1700”] Käytä suodatettua hakua [/caption] [caption id="" align=“alignnone” width=“1434”] Arvojen lisääminen [/caption] [caption id="" align=“alignnone” width=“658”] Tältä arvon valinta näyttää. Lajittelu ei ole oikein, eikä kaikkia arvoja näytetä ensimmäisellä latauskerralla, vaan käyttäjän on haettava niitä. Muista myös poistaa ”Luo” profiileista ja käyttöoikeusjoukoista, jotta käyttäjät eivät luo lisää tietueita lennosta. [/caption]

Osa 3: kehittyneet vaihtoehdot

Kehittyneempiin skenaarioihin voit harkita näitä vaihtoehtoja:

Vaihtoehto 4: mukautetut näkymät ja viiteobjekti

Vaihtoehto 4, viiteobjekti ja tekstikenttä sekä Lightning-verkkokomponentti, joka lukee valintaluettelon arvot viiteobjektista. Edut: tietoja lisätään dynaamisesti, ja lähdeobjekti säilyttää arvot. Haitta: vaatii LWC-kehitystä ja mukautettuja sivuja

Jos käytät muokkausnäkymissäsi mukautettuja Lightning-verkkokomponentteja (LWC), voit käyttää viiteobjektia arvojen lukemiseen ja näyttämiseen ja tallentaa varsinaiset arvot hakusuhteiden sijaan.

Vaihtoehto 5: erilliset objektit

Vaihtoehto 5, erilliset viiteobjektit, yksi luetteloa kohden. Edut: tietoja lisätään dynaamisesti, siisti tietomalli ja monta liittyvää kenttää. Haitat: tietojen lataukset sandboxeissa, avaimia arvojen sijaan ja paljon objekteja

Jos hakuarvojen merkitys kasvaa, harkitse erillisen objektin luomista kullekin ja erillisiä hakusuhteita. Tämä mahdollistaa tietojen dynaamisen lisäämisen, pitää tietomallin siistinä ja tukee lisää liittyviä kenttiä kussakin objektissa.

Käytännön esimerkkejä

Tässä käytännön esimerkkejä kustakin vaihtoehdosta:

Tavalliset valintaluettelot: Siisti käyttöliittymä kiinteillä arvoilla.

Tekstikentät ilman validointia: Joustavuutta, mutta ei tietojen validointia.

Haku viiteobjekteihin: Käyttää samaa objektia suodatetuilla tietuetyypeillä joustavuuden vuoksi.

Erilliset objektit: Käyttää erillisiä objekteja kullekin haulle, mikä antaa siistin ja joustavan tietomallin.

Lopuksi

Valintaluetteloiden ja niiden vaihtoehtojen vivahteiden ymmärtäminen on ratkaisevaa tehokkaassa tietomallinnuksessa. Tavallisista valintaluetteloista erillisiin objekteihin jokaisella vaihtoehdolla on omat etunsa tiettyihin tietomallinnuksen tarpeisiin.

Tule pian takaisin!

Lisää näkemyksiä ja vinkkejä löydät täältä www.SteveTechArc.com-sivustolta ja YouTube-kanavalta @SteveTechArc (opens in a new tab). Tilaa kanava ja hio tietomallinnustaitojasi kanssamme!

Autamme muuttamaan maailmaa jakamalla hienoja ajatuksia muille arkkitehdeille ja kaikille, jotka ovat matkalla arkkitehdiksi!

Litterointi tekoälyn avulla

STA 2.2