Zákazník má kontakty. Objednávka má položky. Projekt má přiřazených několik lidí a každý z těch lidí zase pracuje na několika projektech. Firemní data drží pohromadě vazby, a platforma, která to nebere v potaz, tlačí každého buď k denormalizaci — tedy k tomu, aby opakující se údaje nacpal do jednoho širokého záznamu —, nebo k dobře známé bolesti ručního propojování dvou tabulek s nadějí, že to rozhraní nějak zvládne. Právě plnohodnotné vazby odlišují skutečnou datovou platformu od lepší tabulky.
Vazby na platformě mají dvě podoby, které byste čekali. Vazba jedna k mnoha — jeden Zákazník a k němu více Kontaktů — se na straně "mnoha" projeví jako odkazová vlastnost (každý Kontakt míří na svého Zákazníka) a na straně "jednoho" jako záložka s opačným pohledem (na stránce každého Zákazníka je seznam jeho Kontaktů). Vazba mnoho k mnoha — třeba Projekt ↔ Uživatel — se objeví jako vícenásobný odkaz na obou stranách a každá strana přirozeně nabízí tu druhou jako související seznam. Vazbu popíšete jednou a přizpůsobí se obě strany obrazovky.
Nastavit takovou vazbu je zhruba tak snadné, jak to zní. V editoru typu přidáte odkazovou vlastnost, vyberete typ, na který míří, zvolíte jednu nebo více hodnot a případně pojmenujete opačnou stranu. Tím je nastavení hotové. Jakmile uložíte, formuláře dostanou nové pole, na protějším typu se automaticky objeví záložka se souvisejícími záznamy, vyhledávání i filtrování o vazbě vědí a API ji vystaví na obou stranách. Žádné nasazování, žádné migrační skripty.
Jedna drobnost, která v každodenní práci znamená hodně: záložky s opačným pohledem vznikají automaticky. Otevřete záznam Zákazníka a uvidíte záložku Kontakty — ne proto, že ji někdo nezapomněl nastavit, ale protože ji předpokládá samotná vazba. Prokliknete se na seznam, seřadíte ho, vyfiltrujete a přidáte nový Kontakt, který má rovnou předvyplněného nadřazeného Zákazníka. Přesně tohle propojení by při vývoji od nuly spolklo týdny práce na rozhraní — tady vznikne prostě tím, že vazbu vyhlásíte.
Když na pořadí ve vazbě záleží — položky faktury musí jít za sebou ve správném sledu, kroky v kontrolním seznamu dávají smysl jen v určitém pořadí —, platforma pořadí trvale drží a uživatelé ho můžou přetažením měnit. Když na pořadí nezáleží, výchozí chování se nikam neplete. Typ může odkazovat i sám na sebe, což pokryje známé případy: nadřazené úkoly a podúkoly, organizační hierarchii lidí nebo vlákno souvisejících incidentů.
Kde se přínos vazeb projeví nejhmatatelněji, je filtrování napříč nimi. Tvůrce dotazů bere vlastnosti souvisejících typů jako plnohodnotné. Systému můžete zadat "faktury nad pět tisíc, u kterých je země zákazníka Německo", aniž byste psali jakékoli spojování tabulek — tvůrce dotazů projde vazbu za vás. Totéž platí pro řazení a seskupování. Pohled nad Fakturami se dá uspořádat podle pole Zákazník.Region stejně snadno jako podle vlastního pole.
Po stejných cestách putují i oprávnění. Platforma zvládá i choulostivé situace — uživatel vidí nadřazený záznam, ale ne podřízený, nebo naopak —, tak, že ukáže to, na co má právo, a zbytek nenápadně skryje. Z vazby se nestanou zadní vrátka k chráněným datům a uživatele nemate záznamy, které stejně nemůže otevřít.
Vazby patří mezi funkce, které zní jako formalita — dokud nezkusíte nástroj, který je zvládá špatně. Pak je jejich absence první věc, kvůli které chcete pryč. My je bereme jako základ a zbytek platformy — dotazy, pohledy, formuláře, API — se o něj všude opírá. Přirozeným dalším krokem je článek o tvůrci dotazů, protože právě tam se naplno ukáže, co skutečné vazby umožňují.