Víc než databáze

🌐 K dispozici také v 29 jazycích

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 · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

Obrázek vytvořený pomocí AI

Přeloženo pomocí AI. Komunita překlad zatím nezkontrolovala. Číst anglicky

Modul 1 z 10 kapitoly Datová architektura Salesforce, kapitoly 3 kurzu Data Architect. Každý modul stojí sám o sobě. Další: Dívejte se na mateřskou loď: standardní datové modely

Otázka, na kterou tento modul odpovídá: V čem se Salesforce liší od tradiční databáze?

Pokud jste nějakou dobu administrátorem Salesforce, víte, jak vytvořit objekt. Setup, Object Manager, New Custom Object. Dejte mu název, přidejte pár polí, postavte rozvržení stránky a za deset minut s ním uživatelé mohou pracovat.

Co se ale ve skutečnosti stalo, když jste klikli na Save?

Pokud přicházíte z databázového světa, nejspíš si představujete, že Salesforce šel a vytvořil novou tabulku. Nevytvořil. A pochopit proč je jedno z míst, kde se začnete posouvat od myšlení administrátora nebo vývojáře k myšlení architekta.

Salesforce samozřejmě ukládá data; pod tím jsou databáze. Salesforce ale není databáze s hezkou obrazovkou navrchu. Je to aplikační platforma řízená metadaty a toto rozlišení ovlivňuje téměř každé rozhodnutí v tomto kurzu.

Platforma má tvar

V kapitole 2 jsme postavili model, aniž bychom se o Salesforce vůbec starali. Bylo to záměrné: naslouchali jsme podstatným jménům, postavili konceptuální model, přidali atributy, klíče a vztahy a teprve pak se ptali, jak by to měl Salesforce implementovat. Teď musíme porozumět tomu, na čem to implementujeme.

Používám pro to jednoduchou větu: platforma má tvar. Salesforce nám dává objekty, pole, vztahy, zabezpečení, automatizaci, API, transakce, sestavy a vyhledávání a všechno je to propojené. Když vytvořím objekt, nevytvářím jen místo pro řádky. Vytvářím něco, co se účastní modelu zabezpečení, na co může působit automatizace, co zpřístupňují API, co mohou používat sestavy, k čemu se mohou vázat jiné objekty a na čem budou záviset uživatelé, integrace a čím dál víc i agenti. To je mnohem víc než tabulka.

Metadata jsou plán

Představte si budovu. Je tu budova samotná a je tu plán, který ji popisuje: kde jsou zdi, kam vedou dveře, jak spolu místnosti souvisejí. Salesforce funguje stejně. Definice objektu jsou metadata. Definice pole jsou metadata. Vztah jsou metadata. Většina toho, co konfigurujeme v Setupu, jsou metadata a platforma je za běhu čte, aby dala našemu orgu jeho strukturu a chování.

Salesforce popisuje srdce platformy jako multitenantní a zároveň řízené metadaty: když definujeme objekt nebo pole, definice se uloží jako metadata, ne jako nová fyzická tabulka nebo sloupec pro náš org (Platform Multitenant Architecture (otevře se v nové kartě)).

Když tohle učím, otevřu kapotu. Salesforce pro vás nevytváří novou databázi pokaždé, když přidáte objekt. Přidává záznam do svých vlastních tabulek: tabulky objektů, tabulky polí, tabulky dat a pomocných tabulek pro indexy a vztahy, všechno klíčované identifikátorem orgu, který drží data vašeho orgu odděleně od dat všech ostatních. Přidání pole je tedy jen přidání záznamu. Proto ho můžete vytvořit za pochodu, v poledne, v produkci.

Vysvětluje to i něco, na čem lidé klopýtají. Když napíšete SELECT Id, Name, Special__c FROM Account, vypadá to jako jedna tabulka. Pod tím čtete standardní objekt a jeho vlastní pole z různých struktur, takže platforma dělá join, který jste nikdy nenapsali. Indexy existují, ale nefungují tak jako index v tradiční databázi. Vnitřnosti ke zkoušce znát nemusíte. Musíte ale vědět, že to, co vidíte v Object Manageru, není obraz fyzických tabulek jedna k jedné, a že tato abstrakce je zároveň silou platformy i důvodem, proč se chová tak, jak se chová.

Kliknutím zvětšíte

Dívejte se na mateřskou loď

Jedna z věcí, které ve třídě říkám, je dívejte se na mateřskou loď. Než vymyslíte nějaký složitý způsob, jak něco v Salesforce udělat, podívejte se, jak to dělá Salesforce sám.

Vezměte účet (Account). Nevytvořili jste ho vy; vytvořil ho Salesforce. Můžete do něj ale přidávat pole, automatizovat kolem něj, měnit jeho rozvržení, zpřístupnit ho přes API a vázat na něj jiné objekty. Vlastní objekty běží na stejném stroji, a proto působí standardní a vlastní objekty při stavění tak podobně. V Apexu mají dokonce společnou základní třídu, sObject.

To je návyk, na kterém tato kapitola staví, a v dalším modulu se podíváme pořádně: na standardní datové modely, které pro vás Salesforce už postavil.

Nestavíme vedle Salesforce. Rozšiřujeme ho.

Vaše API přišlo s objektem

Vytvořte tabulku v tradiční databázi a máte tabulku. Pokud s ní potřebuje pracovat jiná aplikace, má někdo další práci. Vytvořte objekt v Salesforce a platforma mu už rozumí ve svých aplikačních a integračních vrstvách: stejná metadata používá k poskytování svých API REST a SOAP, takže záznamy objektu lze přes ně vytvářet, číst, aktualizovat a mazat, jakmile objekt existuje (Platform Multitenant Architecture (otevře se v nové kartě)).

Nenavrhl jsem API proto, že jsem vytvořil objekt. Platforma zná objekt, jeho pole, jejich typy, jeho vztahy i jeho zabezpečení. To je jeden z důvodů, proč vývoj v Salesforce postupuje tak rychle. Je to také důvod, proč je vytvoření objektu větší rozhodnutí, než vypadá: zapojujete strukturu do celé aplikační platformy. A platí to i obráceně. Lidé ze SQL Serveru nebo Oraclu se mě někdy ptají, jak nahrát data rovnou do databáze. Nejde to. Všechno přichází přes API.

Činžovní dům

Teď slovo, které slýcháte pořád: multitenance. Představuji si ji jako činžovní dům.

Máte svůj byt. Váš nábytek je váš a váš klíč by neměl otevřít moje dveře. Dům ale sdílíme: elektřinu, vodu, výtahy, vstupní halu. Váš org působí jako vaše vlastní prostředí, s vašimi daty, vašimi objekty, vaší automatizací. Pod tím Salesforce popisuje každý org jako nájemníka (tenant), přičemž data, metadata a logiku každého nájemníka izoluje, zatímco infrastruktura a služby se sdílejí (Platform Multitenant Architecture (otevře se v nové kartě)). Tak dokáže dát každému zákazníkovi tak přizpůsobitelnou platformu, aniž by pro každého provozoval samostatný stack.

Sdílení domu má ale důsledky. Když si jeden nájemník koupí obrovskou klimatizaci a pustí fén i troubu najednou, vyhodí jistič a celé patro je potmě.

Výtah si nemůžete zabrat

Zůstaňte v domě ještě chvíli. Představte si, že jeden obyvatel oznámí: „Výtah potřebuji od osmi do poledne. Nikdo jiný ho používat nemůže.“ To ve sdíleném domě nefunguje a v Salesforce také ne. Jednomu nájemníkovi nelze dovolit spotřebovávat sdílené zdroje bez omezení a zhoršovat platformu všem ostatním.

Odtud pocházejí governor limits (limity platformy). Pokud jste v Salesforce vyvíjeli, nejspíš jste je potkali jako seznam čísel k zapamatování. Nechci, abyste o nich takhle přemýšleli. Salesforce uplatňuje limity na úrovni transakce a orgu, aby zátěž jednoho nájemníka nemonopolizovala sdílený výpočetní výkon (Architecture Basics (otevře se v nové kartě)). To je ta architektura; každý jednotlivý limit je jen její implementací. Později v kurzu nám bude záležet na konkrétních limitech, protože mění návrh. Prozatím si pamatujte dům: máte obrovskou svobodu přestavět si byt. Výtah si zabrat nesmíte.

ID Salesforce jsou součástí abstrakce

Každý záznam v Salesforce má identifikaci, které platforma rozumí, ID záznamu, a ta funguje napříč všemi schopnostmi: v rozhraní, v API, v sestavách, v automatizaci.

V kapitole 2 jsme řekli, že dobrý klíč je jedinečný, neměnný, bez významu a nikdy nejsou osobní údaje. ID Salesforce to pro Salesforce splňuje. Není to ale totéž co obchodní klíč. Vaše firma může mít pořád zákaznické číslo z ERP, osobní číslo zaměstnance nebo číslo objednávky partnera, které něco znamená napříč systémy. Nepleťte si „Salesforce ví, který záznam to je“ s „podnik ví, která obchodní věc to je“. To jsou různé problémy identifikace a ten druhý se vrátí u integrace a kmenových dat.

Objekty jsou víc než úložiště

Tady je posun, který chci, abyste udělali před zbytkem této kapitoly. Objekt není jen místo, kam ukládat data. Pole není jen sloupec a vztah není jen cizí klíč. Databázová přirovnání při výuce používám, protože navazují na to, co lidé už znají. Pokud se ale zastavíme u nich, uniká nám architektura.

Objekt, který zvolíme, rozhoduje o tom, jaké schopnosti s ním přicházejí. Typ pole ovlivňuje ověřování, integraci, vyhledávání, sestavy i to, jak data čtou jiné systémy. Vztah rozhoduje o životním cyklu, vlastnictví, sdílení a mazání. Kam data dáme, ovlivňuje úložiště, výkon a měřítko. A protože to všechno běží na sdílené platformě, volba, která je se stovkou záznamů neškodná, se může se sto miliony chovat úplně jinak. Tato rozhodnutí probereme jedno po druhém.

Nad rámec zkoušky: co mění AI. Dobré názvy a popisy roky pomáhaly dalšímu administrátorovi nebo vývojáři pochopit, co jsme postavili. Teď ten kontext čtou i stroje. Systém AI, který pracuje s polem Flag2__c, má stejný problém jako nový vývojář: co ta věc znamená? Metadata už nejsou ozdoba; jsou součástí toho, jak stroje aplikaci rozumějí.

Co tady rozhoduje architekt

• Navrhuji pro platformu, na které skutečně jsem, nebo zacházím se Salesforce jako s obecnou databází?
• Které části mého návrhu jsou obchodní pojmy a které jsou implementační volby v Salesforce?
• Jaké chování platformy přichází se strukturou, kterou se chystám vytvořit?
• Které limity jsou výrazem sdílené architektury a které z nich ovlivní tento návrh?
• Pokud bude tuto strukturu těžké později změnit, zacházím s ní jako s architektonickým rozhodnutím?

V kapitole 2 jsme řekli: nenavrhujte ze Setupu. Teď znáte další důvod. Kliknutí na New Custom Object vám nedá jen tabulku; připojí další kus vaší architektury k multitenantní platformě řízené metadaty. Než ale rozhodnete, jaký objekt vytvořit, je tu základnější otázka: mají tato data vůbec žít tady? To přijde příště.

K prozkoumání

• Salesforce Architects, Platform Multitenant Architecture (otevře se v nové kartě), ověřeno 2026-10-17: definice objektů a polí se ukládají jako metadata, ne jako nové tabulky; sdílené tabulky (MT_Objects, MT_Fields, MT_Data, MT_Indexes) klíčované podle OrgID; stejná metadata poskytují API REST a SOAP.
• Salesforce Architects, Architecture Basics (otevře se v nové kartě), ověřeno 2026-10-17: limity platformy a provádění, aby kód a transakce „don’t monopolize shared compute resources“ (nemonopolizovaly sdílené výpočetní zdroje).