Jokainen rakenne on sitoumus
Saatavilla myös 28 kielellä
English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Español (México) · Français (Canada) · Deutsch (Schweiz)
Luku 3 kurssilla Data Architect, Osa 1: Tietoarkkitehdiksi. Edellinen: Tietojen mallintaminen merkityksen kautta.
Tässä on kysymys, jonka esitän jokaiselle ryhmälle. Jos joku sanoo ”työskentelen Salesforcen parissa”, mikä on tuoteobjektin API-nimi?
Se on Product2. Se on ensimmäinen lakmustestini. Jossain vaiheessa Salesforce rakensi tuoteobjektin, huomasi, ettei se toiminut, ja joutui jättämään sen taakseen. Sitä ei voinut vain ottaa pois, joten he lisäsivät Product2:n. Jopa Salesforce elää vanhojen rakenteidensa kanssa.
Salesforce antoi myös itselleen tilaa kasvaa. Sen vakio-objekteilla ei ole etu- eikä jälkiliitettä, emmekä me, orgeja mukauttavat ihmiset, voi koskaan vallata sitä tilaa. Salesforce voi siis jatkaa objektien lisäämistä törmäämättä koskaan mihinkään, mitä me rakennamme.
Tässä on siitä opetus: objektin luominen vie kymmenen minuuttia. Sen kanssa eläminen vie vuosia. Jokainen lisäämäsi objekti ja kenttä on sitoumus. Se vie tallennustilaa. Se kerää rajoja. Se saa jakamismallin, suunnittelitpa sellaisen tai et. Se vaatii lisenssin jokaiselle ihmiselle, joka koskee siihen. Ja nyt tekoälykin lukee sitä, joten se, miten nimeät ja kuvaat sen, ratkaisee, mitä agentti ymmärtää tiedoistasi. Lisääminen on helppoa. Poistaminen on vaikeaa.
Tämä luku muuttaa Salesforcen rakennuspalikat päätöksiksi.
Kuva on luotu tekoälyllä.
Rakenteet yhdellä silmäyksellä
Osio nimeltä “Rakenteet yhdellä silmäyksellä ”Salesforce antaa sinulle kuusi paikkaa tietojen säilyttämiseen. Laitan ne yhdelle dialle, koska ensimmäinen tehtävä on tietää, että ne kaikki ovat olemassa:
| Rakenne | Mihin se on tarkoitettu | Mikä on koukku |
|---|---|---|
| Vakio-objektit | Salesforcen oma malli: tili (Account), yhteyshenkilö (Contact), myyntimahdollisuus (Opportunity), tapaus (Case), omaisuuserä (Asset) ja muut | Käytä niitä siihen, mihin ne on tarkoitettu, tai ne taistelevat vastaan |
| Mukautetut objektit | Omat liiketoimintatietosi | Helppo luoda, vaikea poistaa käytöstä |
| Ulkoiset objektit | Tiedot, jotka asuvat toisessa järjestelmässä ja näytetään Salesforcessa | Jokainen kosketus on kutsu (callout) |
| Big objectit | Valtavat määrät, jotka on säilytettävä mutta joita avataan harvoin | Ei vakiokäyttöliittymää eikä -raportointia; kyselyt tehdään indeksin kautta |
| Tiedostot (Files) | Dokumentit, valokuvat ja muu sisältö | Tiedostotallennustila kasvaa nopeasti |
| Liitteet (Attachments) | Vanha tapa tallentaa tiedostoja | Vanhentunut: käytä Filesia |
Yhden valitseminen on vain osa asiaa. Ennen rakennetta tulee kysymys siitä, missä tietojen ylipäätään pitäisi asua: coressa, viitattuina sieltä, missä ne jo ovat, vai arkistoituina.
Polku tämän luvun läpi
Osio nimeltä “Polku tämän luvun läpi ”Tämä luku on iso, joten se tulee kymmenessä osassa. Jokainen on itsenäinen. Luvussa 2 päätimme, millainen mallin pitäisi olla; tässä päätämme, miten sen pitäisi elää Salesforcessa.
- Salesforcen tietoalusta: enemmän kuin tietokanta. Mikä tekee Salesforcesta erilaisen ja miksi alustalla on muoto.
- Katso emoalukseen: vakiotietomallit. Myynti- ja palvelumallit, jotka Salesforce on jo rakentanut, tiedostot, tallennustila ja henkilötilit.
- Rakenna omasi: mukautetut objektit. Mitä New Custom Object -näyttö päättää, kentät, joita et luonut, ja miten luet minkä tahansa API-nimen: vakio, mukautettu tai hallittu paketti (managed package).
- Missä nämä tiedot asuvat? Coressa, viitattuina vai arkistoituina, päätettynä ennen kuin yhtään objektia luodaan.
- Valitse oikea objekti. Sopivuustesti, vakio-objektien mukanaan tuoma painolasti, henkilötilit ja lisenssit, jotka ratkaisevat, mitä ihmiset voivat käyttää.
- Kentätkin ovat arkkitehtuuria. Kenttätyyppi kerrallaan, ihmisiä yllättävät käyttäytymiset ja miksi jokainen kenttä saa kuvauksen.
- Suhteilla on seurauksia. Lookup vai master-detail, kolme tasoa syvä ja kaksi päätietuetta leveä, looginen liitosobjekti ja Salesforcen liitosobjekti (Salesforce Junction Object), ja rajat, jotka puraisevat.
- Omistajuus ja elinkaari. Kuka omistaa tietueen, jakamistaulu, jossa omistajuudesta tulee pääsyä, ja mitä tietueelle tapahtuu sen elinkaaren aikana.
- Tietojen pitäminen johdonmukaisina. Johdonmukaisuuden tikkaat: jokaisella kerroksella on hintansa, etkä koskaan ”korjaa” historiaa täyttääksesi uuden säännön.
- Suunnittele Salesforcen fyysinen malli. Leike Steve Truckingista loogisesta mallista Salesforceen, rakennettuna askel askeleelta perusteluineen.
Kun olet valmis, testaa itsesi luvun opiskeluoppaalla: tarkistuslista koetta varten, tavat kokeen jälkeen, tärkeät termit ja muutama kysymys.
Mitä arkkitehti tässä päättää
Osio nimeltä “Mitä arkkitehti tässä päättää ”- Mitä Salesforce jo mallintaa, ennen kuin keksit mitään: katso emoalukseen.
- Missä kukin tietolaji asuu, coressa, viitattuna vai arkistoituna, ennen rakenteen valitsemista.
- Mikä rakenne sitä säilyttää, tietäen, mistä kukin niistä luopuu.
- Miten objektit liittyvät toisiinsa, kuka omistaa tietueet ja mitä se tarkoittaa pääsylle ja mittakaavalle.
- Mistä lisensseistä malli riippuu, tarkistettuna ennen objektien suunnittelua, ei jälkeenpäin.
- Miten tiedot pysyvät johdonmukaisina ja mitä kukin johdonmukaisuuden kerros maksaa.
Kokeen jälkeen: tekoälyavusteinen rakentaminen voi luoda objekteja ja kenttiä minuuteissa. Kun lisääminen on lähes ilmaista, ”jokainen rakenne on sitoumus” on tärkeämpää, ei vähemmän tärkeää. Jokainen moduuli päättyy siihen, mitä tekoäly muuttaa kyseisessä päätöksessä.
Lue lisää
Osio nimeltä “Lue lisää ”- Salesforce Data Storage: Estimated Record Size by Object Type (opens in a new tab), Salesforce Help (englanniksi)
- Standard User Licenses (opens in a new tab), Salesforce Help (englanniksi)
Seuraava: Yrityksen tietojen ymmärtäminen