Każda struktura to zobowiązanie
Dostępne także w 28 językach
English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)
Rozdział 3 kursu Data Architect, część 1: Jak zostać architektem danych. Wstecz: Modelowanie danych, które coś znaczą.
Oto pytanie, które zadaję na każdych zajęciach. Jeśli ktoś mówi „pracuję z Salesforce”, jaka jest nazwa API obiektu produktu?
To Product2. To mój pierwszy test. Gdzieś po drodze Salesforce zbudował obiekt produktu, zorientował się, że się nie sprawdza, i musiał go zostawić. Nie mógł go po prostu usunąć, więc dodał Product2. Nawet Salesforce żyje ze swoimi starymi strukturami.
Salesforce zostawił sobie też miejsce na wzrost. Jego obiekty standardowe nie mają prefiksu ani sufiksu, a my, ludzie dostosowujący orgi, nigdy nie możemy zająć tej przestrzeni. Dzięki temu Salesforce może dodawać kolejne obiekty i nigdy nie zderzyć się z niczym, co zbudujemy.
Lekcja jest taka: utworzenie obiektu zajmuje dziesięć minut. Życie z nim zajmuje lata. Każdy obiekt i każde pole, które dodajesz, to zobowiązanie. Zajmuje przestrzeń. Podlega limitom. Dostaje model udostępniania, czy go zaprojektowano, czy nie. Wymaga licencji dla każdej osoby, która go dotyka. A teraz czyta go także AI, więc to, jak go nazwiesz i opiszesz, decyduje o tym, co agent rozumie z twoich danych. Dodawanie jest łatwe. Usuwanie jest trudne.
Ten rozdział zamienia klocki Salesforce w decyzje.
Obraz wygenerowany przez AI.
Struktury w skrócie
Dział zatytułowany „Struktury w skrócie ”Salesforce daje ci sześć miejsc na dane. Umieszczam je na jednym slajdzie, bo pierwsze zadanie to wiedzieć, że wszystkie istnieją:
| Struktura | Do czego służy | Haczyk |
|---|---|---|
| Obiekty standardowe | Własny model Salesforce: konto, kontakt, szansa sprzedaży, zgłoszenie, zasób i reszta | Używaj ich zgodnie z przeznaczeniem, inaczej z tobą walczą |
| Obiekty niestandardowe | Twoje własne dane biznesowe | Łatwo je utworzyć, trudno wycofać |
| Obiekty zewnętrzne | Dane, które mieszkają w innym systemie, pokazywane w Salesforce | Każde dotknięcie to wywołanie zewnętrzne |
| Big objects | Ogromne wolumeny, które trzeba trzymać, ale rzadko się je otwiera | Brak standardowego interfejsu i raportowania; zapytania idą przez indeks |
| Pliki | Dokumenty, zdjęcia i inna treść | Przestrzeń na pliki szybko rośnie |
| Załączniki | Stary sposób przechowywania plików | Przestarzałe: używaj plików |
Wybór jednej z nich to jednak tylko część sprawy. Przed strukturą przychodzi pytanie, gdzie dane w ogóle powinny mieszkać: w core, wskazywane tam, gdzie już są, czy zarchiwizowane.
Droga przez ten rozdział
Dział zatytułowany „Droga przez ten rozdział ”Ten rozdział jest duży, więc ma dziesięć części. Każda jest samodzielna. W rozdziale 2 zdecydowaliśmy, jaki powinien być model; tu decydujemy, jak powinien żyć w Salesforce.
- Platforma danych Salesforce: więcej niż baza danych. Czym wyróżnia się Salesforce i dlaczego platforma ma kształt.
- Patrz na statek-matkę: standardowe modele danych. Modele Sales i Service, które Salesforce już zbudował, pliki, przestrzeń dyskowa i konta osób.
- Zbuduj własny: obiekty niestandardowe. O czym decyduje ekran New Custom Object (nowy obiekt niestandardowy), pola, których nie utworzono, i jak czytać dowolną nazwę API: standardową, niestandardową czy z pakietu zarządzanego.
- Gdzie mieszkają te dane? W core, wskazywane czy zarchiwizowane: decyzja przed utworzeniem jakiegokolwiek obiektu.
- Wybierz właściwy obiekt. Test czystego dopasowania, bagaż, który przynoszą obiekty standardowe, konta osób i licencje, które decydują, czego ludzie mogą używać.
- Pola to też architektura. Typ pola po typie pola, zachowania, które zaskakują ludzi, i dlaczego każde pole dostaje opis.
- Relacje mają konsekwencje. Lookup czy master-detail, trzy poziomy w głąb i dwóch rodziców wszerz, logiczny obiekt łączący i obiekt łączący Salesforce (Junction Object) oraz limity, które gryzą.
- Własność i cykl życia. Kto jest właścicielem rekordu, tabela udostępniania, w której własność staje się dostępem, i co dzieje się z rekordem przez całe życie.
- Spójność danych. Drabina spójności: każda warstwa ma koszt i nigdy nie „naprawia się” historii, żeby zadowolić nową regułę.
- Zaprojektuj fizyczny model w Salesforce. Wycinek Steve Trucking, od modelu logicznego do Salesforce, budowany krok po kroku, z rozumowaniem.
Na koniec sprawdź się z przewodnikiem do nauki do tego rozdziału: lista kontrolna na egzamin, nawyki wykraczające poza niego, słowa do zapamiętania i kilka pytań.
Co tu decyduje architekt
Dział zatytułowany „Co tu decyduje architekt ”- Co Salesforce już modeluje, zanim cokolwiek się wymyśli: patrz na statek-matkę.
- Gdzie mieszka każdy rodzaj danych, w core, wskazywane czy zarchiwizowane, zanim wybierze się strukturę.
- Która struktura je przechowuje, ze świadomością, z czego każda rezygnuje.
- Jak obiekty są ze sobą powiązane, kto jest właścicielem rekordów i co to oznacza dla dostępu i skali.
- Od jakich licencji zależy model, sprawdzonych przed zaprojektowaniem obiektów, a nie po nim.
- Jak dane pozostają spójne i ile kosztuje każda warstwa spójności.
Poza egzaminem: budowanie wspomagane przez AI potrafi tworzyć obiekty i pola w kilka minut. Gdy dodawanie jest prawie darmowe, zasada „każda struktura to zobowiązanie” ma większe znaczenie, a nie mniejsze. Każdy moduł kończy się tym, co AI zmienia w danej decyzji.
Do zgłębienia
Dział zatytułowany „Do zgłębienia ”- Salesforce Data Storage: Estimated Record Size by Object Type (opens in a new tab), Pomoc Salesforce (po angielsku)
- Standard User Licenses (opens in a new tab), Pomoc Salesforce (po angielsku)