Best practices voor het ontwerpen van meertalige databases

FilmID

Originele titel

Vertalingen

1

Die Hard

[

{"language":"sp", "title":"Duro de matar"},

{"language":"it", "title":"Trappola di cristallo"},

{"language":"fr", "title":"Piège de cristal"}

]

2

Terug naar de toekomst

[

{"language":"sp", "title":"Volver al futuro"},

{"language":"it", "title":"Ritorno al futuro"},

{"language":"fr", "title":"Terug naar de toekomst"}

]

3

Jurassic Park

[

{"language":"sp", "title":"Parque jurásico"},

{"language":"it", "title":"Giurassico parco"},

{"language":"fr", "title":"Parc jurassique"}

]

Deze optie vereist geen extra kolommen, maar voegt complexiteit toe. De gegevensquery's moeten nu in staat zijn om de gegevensstructuur die wordt gebruikt voor meertalige ondersteuning correct te verwerken en te interpreteren. Als bijvoorbeeld JSON of XML wordt gebruikt om vertalingen op te slaan, moeten SQL-query's een SQL-versie gebruiken die het gekozen gegevenstype ondersteunt.

De volgende SQL-opdracht gebruikt de MS SQL Server OPENJSON() functie om de inhoud van de Translations . te gebruiken veld als een ondergeschikte tabel:

SELECT
	m.MovieId,
	m.OriginalTitle,
	t.TranslatedTitle
FROM
	Movies AS m
	CROSS APPLY OPENJSON(m.Translations)
		WITH (
			language char(2) '$.language',
		TranslatedTitle varchar(100) '$.title’
		) AS t
WHERE t.language = 'fr';

Aangezien er geen functies of operators zijn om JSON- of XML-geformatteerde gegevens in standaard SQL te manipuleren, bent u genoodzaakt om uw query's voor een bepaald RDBMS te schrijven als u deze techniek wilt gebruiken om vertaalde teksten op te slaan. De vorige query wordt bijvoorbeeld niet ondersteund door MySQL. Als u de JSON-gegevens in de Movies tabel met MySQL, zou u deze vraag schrijven:

SELECT
	m.MovieId,
	m.OriginalTitle,
	JSON_EXTRACT(m.Translations, '$.title') AS TranslatedTitle
FROM Movies AS m
WHERE JSON_EXTRACT(m.Translations. '$.language') = 'fr';

Vertaalde tekst opslaan in verschillende records

U kunt er ook voor kiezen om voor elke taal verschillende records te gebruiken. U moet zich echter neerleggen bij het verliezen van normalisatie:dezelfde gegevens worden herhaald in verschillende records, waarbij alleen de vertaling varieert.

Met deze optie kunt u weergaven van elke tabel maken die alleen de rijen in een bepaalde taal retourneren:

CREATE VIEW Movies_en AS
SELECT MovieId, Title
FROM Movies
WHERE LanguageId = 'en';

CREATE VIEW Movies_sp as
SELECT MovieId, Title
FROM Movies
WHERE LanguageId = 'sp';

Om vervolgens de tabel te doorzoeken, kunt u een andere weergave gebruiken, afhankelijk van de doeltaal van de vertaling. Maar de normalisatie van het model gaat verloren en het tafelonderhoud is onnodig complex.

Vertaalde tekst in aparte tabellen opslaan

Een manier om de vertaalde teksten op te slaan zonder het relationele model te verbreken, is door een detailtabel te hebben voor elke tabel met teksten die vertaald moeten worden. De ondergeschikte tabel met de vertalingen moet dezelfde sleutelvelden hebben als de moedertabel, plus een veld dat de vertaaltaal aangeeft.

Een ondergeschikte tabel met vertalingen moet dezelfde sleutelvelden hebben als de moedertabel, plus een veld dat de vertaaltaal aangeeft.

Met deze optie kunt u nieuwe talen opnemen zonder de tabelstructuur te wijzigen. Het vereist geen overbodige informatie genereren of de modelnormalisatie doorbreken.

Het nadeel van deze optie is dat er voor elke tabel een ondergeschikte tabel moet worden gemaakt waarin tekstuele gegevens worden opgeslagen die moeten worden vertaald. Het idee om vertalingen op te slaan in gerelateerde tabellen brengt ons echter dichter bij de meest aanbevolen manier om een ​​meertalige database te ontwerpen.

De universele oplossing:een subschema voor vertaling

Om een ​​applicatie en zijn database echt meertalig te laten zijn, moeten alle teksten een vertaling hebben in elke ondersteunde taal - niet alleen de tekstgegevens in een bepaalde tabel. Dit wordt bereikt met een vertaalsubschema waarin alle gegevens met tekstuele inhoud die de ogen van de gebruiker kunnen bereiken, worden opgeslagen.

In webapplicaties die bedoeld zijn voor gebruik in verschillende talen, is een vertaalsubschema een noodzaak, geen optie. Al het andere zal leiden tot complexiteiten die goed onderhoud van de applicatie onmogelijk maken.

De sleutel tot het bewaren van vertalingen in een apart schema is om een ​​geïndexeerde catalogus bij te houden met alle teksten die vertaald moeten worden, of het nu entiteitsbeschrijvingen, foutmeldingen of menu-opties zijn. Het idee is dat er geen tekst wordt opgeslagen die de ogen van de gebruiker kan bereiken in een tabel buiten dit subschema.

Een manier om de vertaalcatalogus te ordenen is door drie tabellen te gebruiken:

• Een hoofdtabel met talen.
• Een tabel met teksten in de originele taal.
• Een tabel met vertaalde teksten.

Schema voor een universele vertaalcatalogus.

In de hoofdtabel met talen voegen we eenvoudig een record in voor elke taal die door het gegevensmodel wordt ondersteund. Elk heeft een ID-code en een naam:

De teksttabel registreert alle teksten die vertaald moeten worden. Elk record heeft een willekeurige ID, de originele tekst en de ID van de originele taal.

In de TextContent tabel, de originele tekst en de ID van de originele taal zijn niet strikt noodzakelijk. Maar ze vereenvoudigen wel zoekopdrachten waarvoor geen vertaling nodig is. Als u bijvoorbeeld statistische analyses of beheercontroles uitvoert (die meestal alleen beschikbaar zijn voor gebruikers die de oorspronkelijke taal begrijpen), kunnen de zoekopdrachten worden vereenvoudigd door gebruik te maken van de standaard (niet-vertaalde) teksten.

De originele teksten zijn ook handig voor wie de tabel met vertaalde teksten moet vullen. Het invoeren van vertaalgegevens kan door middel van een mini-applicatie die de originele tekst en vertalingen in alle beschikbare talen toont. Het is ook mogelijk om informatie voor het vertaalsubschema te genereren via een automatisch proces met behulp van een vertaal-API.

Koppelen met het hoofdschema

In het hoofdschema van de applicatie worden kolommen met tekstwaarden die vertaald moeten worden vervangen door ID's die verwijzen naar de tabel met vertaalde teksten:

Het hoofdschema is gekoppeld aan het vertaalschema via tabellen met teksten die vertaald moeten worden.

U kunt het originele tekstveld in sommige van de hoofdschematabellen laten staan ​​om zoekopdrachten te vergemakkelijken waarbij vertaling niet vereist is, ook al genereert dit overbodige informatie. We kunnen bijvoorbeeld de ProductDescription . behouden veld in het Products tabel om statistische zoekopdrachten te vergemakkelijken of om de afmetingen van een datawarehouse te vullen, waarbij het vertaalsubschema buiten beschouwing wordt gelaten wanneer dit niet nodig is.

• Meertalige database-ontwerp:doe het één keer en doe het goed

We hebben verschillende alternatieven gezien voor het maken van een meertalig databaseontwerp. Sommige zijn eenvoudiger en sneller te implementeren. De laatste oplossing is wat complexer, maar geeft je veel meer flexibiliteit. Het bespaart u ook problemen als het tijd is om de applicatie en de database te onderhouden. Dus op de lange termijn zal het veel goedkoper zijn.

Soms verleidt de kortste weg bij het ontwerpen van databases u tot de overtuiging dat u tijd en moeite bespaart. Maar als je ervoor kiest, zie je over het hoofd dat je waarschijnlijk meerdere keren naar beneden moet. Als u de best practices voor het ontwerpen van meertalige databases negeert, zult u waarschijnlijk steeds weer hetzelfde werk doen.