Návrh databáze pro vícejazyčné aplikace

I když některé softwarové systémy používá omezený počet uživatelů mluvících stejným jazykem, většina organizací potřebuje sjednotit a centralizovat své aplikace, aby je mohli používat lidé mluvící různými jazyky po celém světě. Vícejazyčné databáze představují další úroveň obtížnosti při navrhování a implementaci datových modelů. V tomto článku navrhujeme několik přístupů, jak se s touto výzvou vypořádat.

Jaké informace potřebujeme ukládat ve více jazycích?

Na první pohled se všechny informace o řetězcích mohou zdát věrohodné pro překlad do více jazyků. Obvykle tomu tak však není. Informace související se zákazníkem, jako je CompanyName nebo Address může být přeloženo, ale to nemusí být dobrý nápad.

Vezměte si obchodního zákazníka ve Spojeném království jménem „Riverside Trucks“ s kanceláří na „123 Upper Castle Road“. Nechcete, aby španělsky mluvící uživatel vytiskl a poslal dopis „Camiones Orilla“ na adrese „123 Calle Castillo Superior“. Royal Mail (britská poštovní služba) to nenajde! Pravděpodobně budete chtít přeložit pouze sloupce obsahující popisné informace, nikoli vlastní jména.

Při navrhování systému pro zpracování překladů není vždy předem přesně známo, které sloupce jsou přeložitelné a které překlad nevyžadují. Volba flexibilního přístupu ušetří spoustu času při návrhu a vývoji. Podívejte se na článek „Jak navrhnout systém připravený na lokalizaci“, kde najdete některé příklady.

Jaké přístupy zvažujeme?

V tomto článku popisujeme tři přístupy k návrhu vícejazyčné databáze. Začneme tou nejjednodušší, která není tak flexibilní, a poté přejdeme ke zvážení dalších možností a vysvětlíme pro každou z nich výhody a nevýhody.

Syntaxe i databázové modely (dostupné na webovém datovém modeláři Vertabelo) použité v tomto článku jsou pro SQL Server. Lze je však snadno přizpůsobit jakémukoli databázovému stroji.

Přístup 1:Vytváření dalších sloupců pro uložení přeloženého obsahu

Toto je nejjednodušší přístup k implementaci, i když ne příliš flexibilní. Skládá se z přidání sloupce pro každý sloupec a jazyk, který potřebujeme v našem systému používat, jak ukazuje následující diagram Vertabelo:

I když se to může zdát jako velmi jednoduché řešení, má některé nevýhody. Vysvětlíme níže.

Con:Složitost kódu

Tento přístup dělá kód složitější. Vyžaduje to, abychom buď napsali jiný dotaz pro každý jazyk, nebo použili CASE konstrukt pro získání překladu pro příslušný jazyk na základě uživatelské konfigurace. Viz například následující kód:

SELECT ProductID, CASE @Language WHEN 'ES' THEN ProductName_ES WHEN 'DE' THEN ProductName_DE WHEN 'FR' THEN ProductName_FR ELSE ProductName KONEC JAKO ProductName, CASE @Language WHEN 'ES' THEN ProductDescription'ES WHEN_DEHENDE' FR' THEN ProductDescription_FR ELSE ProductDescription END AS ProductDescription, Cena, Hmotnost, ProductCategoryIDFROM ProductWHERE …

Poznámka: V příkladu používáme proměnnou @Language, abychom zachovali jazyk, který chceme používat. Můžete zvážit použití SESSION_CONTEXT() (nebo Application Context v Oracle) k nastavení a čtení jazyka pro každého uživatele.

Con:Nedostatek flexibility

Tento přístup postrádá flexibilitu. Pokud potřebujeme implementovat nový jazyk, musíme upravit náš datový model přidáním sloupce pro nový jazyk pro každý přeložitelný sloupec v našem systému. Potřebujeme také vytvořit nový jazykový dotaz pro každou tabulku (nebo upravit stávající přidáním nového CASE WHEN klauzule, která používá nový jazyk pro každý přeložitelný sloupec).

Con:Výzvy při nakládání s neznámými informacemi

Představte si toto:uživatel přidá produkt, ale neví, jak ho přeložit, a nechá přeložené sloupce prázdné. Uživatelé hovořící těmito jazyky vidí NULL nebo prázdné informace ve sloupcích, které mohou být vyžadovány.

Přístup 2:Izolace přeložitelných sloupců v samostatné tabulce

Tento přístup seskupuje sloupce v tabulce do přeložitelných a nepřeložitelných sloupců. Nepřeložitelné sloupce zůstanou v původní tabulce. Oproti tomu ty přeložitelné jsou v samostatné tabulce, s cizím klíčem k původní tabulce a indikátorem jazyka. Viz níže:

Diagram ukazuje původní tabulky (bez přeložitelných dat) bílou barvou. Tabulky obsahující překlady jsou světle modré a hlavní tabulka obsahující jazykové informace je žlutá.

To má obrovské výhody flexibility ve srovnání s použitím více sloupců, jak bylo uvedeno výše. Tato metoda nevyžaduje změnu datového modelu, když je potřeba nový jazyk. Také syntaxe dotazu na informace je jednodušší:

SELECT p.ProductID, pt.ProductName, pt.ProductDescription, p.Price, p.Weight, p.ProductCategoryIDFROM Product pLEFT JOIN ProductTranslation pt ON pt.ProductID =p.ProductID AND pt.LanguageID =@LanguageWHERE … 

 Stále však existují určité nevýhody, jak diskutujeme níže.
 
Con:Výzvy, když je třeba přeložit další sloupce
 

 Pokud potřebujeme převést nepřeložitelný sloupec na přeložitelný (nebo naopak), musíme upravit náš datový model a přesunout sloupec z jedné tabulky do druhé. To obvykle znamená vyšší náklady, jakmile je systém implementován a používán.
 
Con:Výzvy při nakládání s neznámými informacemi
 

 Stejně jako první přístup má tento přístup problémy při práci s neznámými informacemi. Opět platí, že pokud uživatel přidá produkt, ale neví, jak jej přeložit, a nechá přeložené sloupce prázdné, uživatelé hovořící těmito jazyky uvidí NULL nebo prázdné informace ve sloupcích, které mohou být vyžadovány. Dotaz také vyžaduje LEFT JOIN v případě, že překlad pro jazyk aktuálního uživatele ještě nebyl vytvořen, takže nepřeložitelná data jsou stále zobrazena.
 
Přístup 3:Přidání překladového subsystému
 

 Překlad lze považovat za vlastnost, která je zcela nezávislá na datovém modelu vyžadujícím překlad. V ideálním systému můžeme povolit nebo zakázat překlad pro jakýkoli sloupec bez nutnosti úpravy datového modelu. Bohužel se to snadněji řekne, než udělá.
 

 Představujeme metodu, která nemá vliv na stávající datový model a je zcela flexibilní. Ačkoli to přidává na složitosti v době dotazování na data, kromě několika tabulek nevyžaduje žádné další změny v datovém modelu. To může být skvělá volba, pokud potřebujete přidat schopnost uchovávat překlady do existujícího datového modelu.
 

 Podívejme se na model a uvidíme, jak funguje:
 

 První věc, kterou si všimnete, je, že původní datový model se vůbec nezměnil. Také neexistuje žádný přímý vztah mezi tímto modelem a překladovým subsystémem.
 

 Překladový subsystém obsahuje malý datový slovník s tabulkami a sloupci vyžadujícími překlad. Tento datový slovník lze upravit pouhým přidáním/odebráním řádků beze změny datového modelu. Překlady jsou uloženy v samostatné tabulce, přičemž každá hodnota je označena následujícími 3 sloupci:
 
 
ColumnID :Jednoznačně identifikuje sloupec (a tabulku), který překládáme.
 
KeyID :Ukládá ID (primární klíč) konkrétního řádku, který překládáme.
 
LanguageID :Identifikuje jazyk překladu.
 
 

 Tento design umožňuje zadávat a ukládat data do původních tabulek a přidávat překlady pouze v případě potřeby. Přeložené informace se používají při získávání dat, přičemž původní data (v původním jazyce) zůstávají nedotčena.
 

 Data lze dotazovat pomocí složitější syntaxe než výše uvedené příklady. Vyžaduje další JOIN pro každý přeložitelný sloupec, jak je uvedeno níže:
 
SELECT p.ProductID, ISNULL(t1.TranslationValue, p.ProductName) AS ProductName, ISNULL(t2.TranslationValue, p.ProductDescription) AS ProductDescription, p.Price, p.Weight, p.ProductCategoryIDFROM Product pLEFT JOIN Translation t1 ON t1.ColumnID =<> AND t1.Key =p.ProductID AND t1.LanguageID =@LanguageLEFT JOIN Překlad t2 ON t2.ColumnID =<> AND t2.Key =p.ID2ProductID =@LanguageWHERE …;
 

 Poznámka: “<<ProductName_ColumnID>> “ a „<<ProductDescription_ColumnID>> ” musí být nahrazeno ID sloupců, které mají být přeloženy, jak jsou uloženy v ColumnInformation  stůl. Zvažte generování zobrazení překladu pro každou tabulku vyžadující překlad, abyste skryli složitost spojení JOIN pro koncové uživatele. Tento krok můžete dokonce automatizovat pomocí skriptu, který generuje každý pohled. Tento skript může dotazovat datový slovník databáze, aby vybral tabulky a sloupce a přidal logiku překladu pro sloupce, které existují v ColumnInformation  tabulka.
 

 Tip navíc č. 1 
 

 Můžete také zjednodušit syntaxi. Nahraďte každý JOIN voláním funkce, která zpracovává (a skrývá) aspekt překladu, jak je znázorněno níže:
 
SELECT p.ProductID, ISNULL(fn_translate('Product','ProductName',ProductID), p.ProductName) AS ProductName, ISNULL(fn_translate('Product','ProductDescription',ProductID), p.ProductDescription) AS ProductName, p.Price, p.Weight, p.ProductCategoryIDFROM Product pWHERE …;
 

 Funkce může číst požadovaný jazyk z kontextu, nebo jej můžete přidat jako další parametr. V tomto příkladu funkce používá názvy tabulek a sloupců poskytnuté jako parametry plus klíč řádku (také poskytnutý jako parametr) k vyhledání a vrácení požadovaného překladu.
 

 Volání funkce znamená další dopad na výkon kvůli přepínání kontextu mezi SQL a procedurálním jazykem. Může to však být jednodušší řešení pro databáze nebo tabulky, kde to množství překládaných dat umožňuje.
 

 Oba příklady – jeden s JOIN a jeden s funkcí – používají funkci ISNULL() SQL Server. Pokud tedy překlad do požadovaného jazyka neexistuje, stále zobrazuje původní hodnotu uloženou ve sloupcích ProductName a ProductDescription namísto mezer nebo NULL.
 
Obecné úvahy
 

 Třetí přístup je obvykle nejlepší pro implementaci větších návrhů. Umožňuje flexibilitu jak při návrhu, tak při používání systému. Existují však specifické úvahy, které mohou učinit ostatní přístupy užitečnými. Bez ohledu na vaši volbu zvažte následující, abyste ušetřili čas jak při návrhu, tak při vývoji/implementaci.
 
Přidat vrstvu abstrakce
 

 Jak již bylo zmíněno dříve, zvažte vytvoření pohledů, které se starají o logiku překladu, např. výběr jednoho sloupce z více sloupců překladu nebo spojení s konkrétními řádky. To udržuje konkrétní detaily implementace skryté před programátory. Jednoduše používají tato zobrazení, než aby museli vytvářet složité SQL věty pokaždé, když potřebují získat přístup k tabulce s přeložitelnými informacemi.
 
Použijte kontext k filtrování dat
 

 Jak je uvedeno v prvním příkladu, zvažte použití kontextových funkcí dostupných ve většině databázových strojů. Použijte je k uložení informací o jazyce uživatele, jakmile se přihlásíte do systému, a poté automaticky filtrujte výsledky v pohledech, které se starají o překlad.
 
Automatizovat
 

 Moderní systémy mohou mít stovky a dokonce tisíce tabulek. Udělejte si čas na automatizaci generování překladových pohledů místo psaní dotazů jeden po druhém. Může vám chvíli trvat, než se dostanete ke skriptu, který funguje, ale pak můžete vždy vytvořit nové pohledy nebo znovu vytvořit ty stávající za méně než sekundu!