Więcej niż baza danych

🌐 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)

Obraz wygenerowany przez AI

Przetłumaczone przez AI. Jeszcze niesprawdzone przez społeczność. Czytaj po angielsku

Moduł 1 z 10 w rozdziale Architektura danych Salesforce, rozdziale 3 kursu Data Architect. Każdy moduł jest samodzielny. Dalej: Patrz na statek-matkę: standardowe modele danych

Pytanie, na które odpowiada ten moduł: czym Salesforce różni się od tradycyjnej bazy danych?

Jeśli od jakiegoś czasu pracujesz jako administrator Salesforce, wiesz już, jak utworzyć obiekt. Konfiguracja, Menedżer obiektów, Nowy obiekt niestandardowy. Nadaj mu nazwę, dodaj kilka pól, zbuduj układ strony, a dziesięć minut później użytkownicy mogą z nim pracować.

Ale co właściwie się stało, gdy kliknięto Zapisz?

Jeśli przychodzisz ze świata baz danych, pewnie wyobrażasz sobie, że Salesforce utworzył nową tabelę. Nie utworzył. A zrozumienie dlaczego to jedno z miejsc, w których zaczyna się przejście od myślenia jak administrator albo programista do myślenia jak architekt.

Salesforce oczywiście przechowuje dane; pod spodem są bazy danych. Ale Salesforce to nie baza danych z ładnym ekranem na wierzchu. To platforma aplikacyjna sterowana metadanymi, a to rozróżnienie kształtuje niemal każdą decyzję w tym kursie.

Platforma ma kształt

W rozdziale 2 zbudowaliśmy model, w ogóle nie martwiąc się o Salesforce. To było celowe: wsłuchaliśmy się w rzeczowniki, zbudowaliśmy model konceptualny, dodaliśmy atrybuty, klucze i relacje i dopiero wtedy zapytaliśmy, jak Salesforce powinien to zaimplementować. Teraz musimy zrozumieć to, na czym implementujemy.

Używam do tego prostego zdania: platforma ma kształt. Salesforce daje nam obiekty, pola, relacje, bezpieczeństwo, automatyzację, API, transakcje, raportowanie i wyszukiwanie, a wszystko to jest ze sobą połączone. Kiedy tworzę obiekt, nie tworzę po prostu miejsca na wiersze. Tworzę coś, co bierze udział w modelu bezpieczeństwa, na czym może działać automatyzacja, co udostępniają API, czego mogą używać raporty, z czym mogą się wiązać inne obiekty i od czego będą zależeć użytkownicy, integracje, a coraz częściej agenci. To dużo więcej niż tabela.

Metadane to plan budynku

Pomyśl o budynku. Jest sam budynek i jest plan, który go opisuje: gdzie są ściany, gdzie drzwi, jak łączą się pomieszczenia. Salesforce działa tak samo. Definicja obiektu to metadane. Definicja pola to metadane. Relacja to metadane. Większość tego, co konfigurujemy w Konfiguracji, to metadane, a platforma czyta je w czasie działania, żeby nadać naszemu orgowi strukturę i zachowanie.

Salesforce opisuje serce platformy jako jednocześnie wielodzierżawne (multitenant) i sterowane metadanymi: gdy definiujemy obiekt albo pole, definicja jest przechowywana jako metadane, a nie jako nowa fizyczna tabela czy kolumna dla naszego orgu (Platform Multitenant Architecture (opens in a new tab), po angielsku).

Ucząc tego, otwieram maskę. Salesforce nie tworzy dla ciebie nowej bazy danych za każdym razem, gdy dodajesz obiekt. Dodaje rekord do własnych tabel: tabeli obiektów, tabeli pól, tabeli danych oraz tabel pomocniczych dla indeksów i relacji, a wszystko to jest kluczowane identyfikatorem orgu, który oddziela dane twojego orgu od danych wszystkich innych. Dodanie pola to więc po prostu dodanie wpisu. Dlatego można je utworzyć w locie, w porze lunchu, na produkcji.

To wyjaśnia też coś, na czym ludzie się potykają. Gdy piszesz SELECT Id, Name, Special__c FROM Account, wygląda to jak jedna tabela. Pod spodem czytasz obiekt standardowy i jego pole niestandardowe z różnych struktur, więc platforma wykonuje złączenie, którego nigdy nie napisano. Indeksy istnieją, ale nie działają tak jak indeks w tradycyjnej bazie danych. Na egzamin nie musisz znać tych wnętrzności. Musisz wiedzieć, że to, co widzisz w Menedżerze obiektów, to nie odwzorowanie jeden do jednego fizycznych tabel, i że ta abstrakcja jest zarówno siłą platformy, jak i powodem, dla którego zachowuje się ona tak, a nie inaczej.

Click to enlarge

Patrz na statek-matkę

Jedna z rzeczy, które mówię na zajęciach, brzmi: patrz na statek-matkę. Zanim wymyślisz jakiś skomplikowany sposób zrobienia czegoś w Salesforce, zobacz, jak robi to sam Salesforce.

Weźmy konto. Nie tworzysz go; tworzy je Salesforce. Ale możesz dodawać do niego pola, budować wokół niego automatyzację, zmieniać jego układy, udostępniać je przez API i wiązać z nim inne obiekty. Obiekty niestandardowe działają na tej samej maszynerii i dlatego obiekty standardowe i niestandardowe są tak podobne, gdy na nich budujemy. W Apex mają nawet wspólną klasę bazową, sObject.

Na tym nawyku opiera się ten rozdział, a w następnym module przyjrzymy się porządnie standardowym modelom danych, które Salesforce już dla ciebie zbudował.

Nie budujemy obok Salesforce. Rozszerzamy go.

API przyszło razem z obiektem

Utwórz tabelę w tradycyjnej bazie danych i masz tabelę. Jeśli inna aplikacja ma z nią pracować, ktoś ma więcej roboty. Utwórz obiekt w Salesforce, a platforma już go rozumie przez swoje warstwy aplikacji i integracji: z tych samych metadanych udostępnia swoje API REST i SOAP, więc rekordy obiektu można przez nie tworzyć, odczytywać, aktualizować i usuwać, gdy tylko obiekt zaistnieje (Platform Multitenant Architecture (opens in a new tab), po angielsku).

Nie zaprojektowałem API dlatego, że utworzyłem obiekt. Platforma zna obiekt, jego pola, ich typy, relacje i zabezpieczenia. To jeden z powodów, dla których programowanie w Salesforce idzie tak szybko. To także powód, dla którego utworzenie obiektu to większa decyzja, niż się wydaje: podłączasz strukturę do całej platformy aplikacyjnej. I działa to też w drugą stronę. Ludzie z SQL Server albo Oracle czasem pytają mnie, jak załadować dane prosto do bazy danych. Nie da się. Wszystko przechodzi przez API.

Blok mieszkalny

Teraz słowo, które słyszysz bez przerwy: wielodzierżawność (multitenancy). Myślę o niej jak o bloku mieszkalnym.

Masz swoje mieszkanie. Twoje meble są twoje, a twój klucz nie powinien otwierać moich drzwi. Ale dzielimy budynek: prąd, wodę, windy, hol. Twój org wydaje się twoim własnym środowiskiem, z twoimi danymi, twoimi obiektami, twoją automatyzacją. Pod spodem Salesforce opisuje każdy org jako dzierżawcę i izoluje dane, metadane i logikę każdego dzierżawcy, a infrastruktura i usługi są współdzielone (Platform Multitenant Architecture (opens in a new tab), po angielsku). Tak może dać każdemu klientowi tak konfigurowalną platformę bez uruchamiania osobnego stosu dla każdego.

Ale dzielenie budynku ma konsekwencje. Jeśli jeden lokator kupi ogromny klimatyzator i jednocześnie włączy suszarkę do włosów i piekarnik, wybije korki, a całe piętro zgaśnie.

Nie możesz zająć windy

Zostańmy w budynku jeszcze chwilę. Wyobraź sobie, że jeden mieszkaniec ogłasza: „Potrzebuję windy od ósmej do południa. Nikt inny nie może z niej korzystać”. To nie działa we wspólnym budynku i nie działa też w Salesforce. Jednemu dzierżawcy nie można pozwolić zużywać wspólnych zasobów bez ograniczeń i pogarszać platformy wszystkim innym.

Stąd biorą się limity zarządcze (governor limits). Jeśli programujesz w Salesforce, pewnie znasz je jako listę liczb do zapamiętania. Nie chcę, żeby myśleć o nich w ten sposób. Salesforce stosuje limity na poziomie transakcji i orgu, żeby obciążenie jednego dzierżawcy nie zmonopolizowało wspólnej mocy obliczeniowej (Architecture Basics (opens in a new tab), po angielsku). To jest architektura; każdy pojedynczy limit to tylko jej implementacja. Później w kursie będą nas obchodzić konkretne limity, bo zmieniają projekt. Na razie pamiętaj o budynku: masz ogromną swobodę przebudowy swojego mieszkania. Nie możesz zająć windy.

Identyfikatory Salesforce są częścią abstrakcji

Każdy rekord Salesforce ma tożsamość, którą rozumie platforma, identyfikator rekordu, i działa ona we wszystkich funkcjach: w interfejsie, w API, w raportach, w automatyzacji.

W rozdziale 2 powiedzieliśmy, że dobry klucz jest unikalny, niezmienny, bez znaczenia i nigdy nie jest danymi osobowymi. Identyfikator Salesforce spełnia to w Salesforce. Ale to nie to samo co klucz biznesowy. Twoja firma może nadal mieć numer klienta w ERP, numer pracownika albo numer zamówienia partnera, który coś znaczy w wielu systemach. Nie myl „Salesforce wie, który to rekord” z „przedsiębiorstwo wie, która to rzecz biznesowa”. To różne problemy tożsamości, a ten drugi wraca przy integracji i danych podstawowych.

Obiekty to więcej niż przechowywanie

Oto zmiana, którą chcę, żeby udało ci się zrobić przed resztą tego rozdziału. Obiekt to nie tylko miejsce przechowywania danych. Pole to nie tylko kolumna, a relacja to nie tylko klucz obcy. Ucząc, używam porównań z bazami danych, bo łączą się z tym, co ludzie już znają. Ale jeśli na tym poprzestaniemy, przegapimy architekturę.

Wybrany obiekt decyduje, jakie możliwości przychodzą razem z nim. Typ pola wpływa na walidację, integrację, wyszukiwanie, raportowanie i to, jak inne systemy czytają dane. Relacja decyduje o cyklu życia, własności, udostępnianiu i usuwaniu. Miejsce, w którym umieszczamy dane, wpływa na przestrzeń, wydajność i skalę. A ponieważ wszystko to działa na wspólnej platformie, wybór nieszkodliwy przy stu rekordach może zachowywać się zupełnie inaczej przy stu milionach. Zajmiemy się tymi decyzjami po kolei.

Poza egzaminem: co zmienia AI. Przez lata dobre nazwy i opisy pomagały następnemu administratorowi albo programiście zrozumieć, co zbudowaliśmy. Teraz ten kontekst czytają też maszyny. System AI pracujący z polem Flag2__c ma ten sam problem co nowy programista: co to właściwie znaczy? Metadane to już nie ozdoba; to część tego, jak maszyny rozumieją aplikację.

Co tu decyduje architekt

• Czy projektuję pod platformę, na której naprawdę jestem, czy traktuję Salesforce jak ogólną bazę danych?
• Które części mojego projektu to pojęcia biznesowe, a które to wybory implementacyjne w Salesforce?
• Jakie zachowanie platformy przychodzi razem ze strukturą, którą zaraz utworzę?
• Które limity są wyrazem wspólnej architektury i które z nich ukształtują ten projekt?
• Jeśli tę strukturę będzie trudno później zmienić, czy traktuję ją jak decyzję architektoniczną?

W rozdziale 2 powiedzieliśmy: nie projektuj z poziomu Konfiguracji. Teraz znasz kolejny powód. Kliknięcie Nowy obiekt niestandardowy nie daje ci tylko tabeli; podłącza kolejny element twojej architektury do sterowanej metadanymi, wielodzierżawnej platformy. Ale zanim zdecydujesz, jaki obiekt utworzyć, jest bardziej podstawowe pytanie: czy te dane w ogóle powinny tu mieszkać? O tym dalej.

Do zgłębienia

• Salesforce Architects, Platform Multitenant Architecture (opens in a new tab) (po angielsku), sprawdzono 2026-10-02, ponownie sprawdzono 2026-10-12: definicje obiektów i pól są przechowywane jako metadane, a nie jako nowe tabele; wspólne tabele (MT_Objects, MT_Fields, MT_Data, MT_Indexes) kluczowane identyfikatorem OrgID; te same metadane udostępniają API REST i SOAP.
• Salesforce Architects, Architecture Basics (opens in a new tab) (po angielsku), sprawdzono 2026-10-02, ponownie sprawdzono 2026-10-12: limity zarządcze i limity wykonania, żeby kod i transakcje „nie monopolizowały wspólnych zasobów obliczeniowych”.