Wielojęzyczna baza danych: która metoda jest lepsza?

Mam stronę internetową w 3 językach.Wielojęzyczna baza danych: która metoda jest lepsza?

Jaki jest najlepszy sposób struktury DB?

1) Tworzenie tabeli 3, po jednym dla każdego języka (np Product_en, Product_es, Product_de) i odbierać dane z tabeli identyfikatorem:

np na stronie php Mam ciąg:

$language = 'en'

więc uzyskać dane tylko

SELECT FROM Product_$language

2) Utwórz 1 stół z:

ID LANGUAGE NAME DESCR

i umieszczać na stronie tylko

WHERE LANGUAGE = '$language'

3) Utwórz 1 stół za pomocą:

ID NAME_EN DESCR_EN NAME_ES DESCR_ES NAME_DE DESCR_DE

Dziękujemy!

Źródło

2013-04-16 user2120569

Opcja 4: posiadanie jednej tabeli z opisami w języku angielskim. Mieć kolejną tabelę, która tłumaczy zwroty. Jeśli fraza już istnieje, masz tłumaczenie. Jeśli nie, dodaj go. Tworzy to "słownik". Czy to jest bardziej wydajne? Zależy od tego, czy użyjesz wielu ciągów, czy nie (dużo, nigdy ...) - co z kolei zależy od tego, jak duża jest baza danych. Wydaje mi się, że to sprawia, że rzeczy są odrobinę bardziej możliwe do utrzymania. – Floris

Wolę wybrać drugą opcję .

Pierwsza opcja wydaje mi się niewystarczająco elastyczna do wyszukiwania rekordów. Co jeśli potrzebujesz wyszukać dwa języki? Najlepszym sposobem, aby to zrobić, jest UNION wynik dwóch instrukcji SELECT. Trzeci wydaje się mieć nadmiarowość danych. Czujesz, że musisz mieć język na każde imię.

Drugi bardzo elastyczny i poręczny. Możesz wykonywać dowolne operacje bez dodawania specjalnych metod, chyba że chcesz przestawić rekordy.

Źródło

2013-04-16 23:56:13

# 2 jest drogą do zrobienia. Pamiętaj, aby utworzyć oddzielną tabelę produktów dla atrybutów, które nie są specyficzne dla danego języka, np. Cena, ilość, UPC, ... Ta tabela będzie główną tabelą produktów. – Cano64

Wybrałbym opcję jedną lub dwie. Który naprawdę zależy od Twojej aplikacji i od tego, jak planujesz uzyskać dostęp do swoich danych. Kiedy zrobiłem podobną lokalizację w przeszłości, użyłem podejścia z pojedynczą tabelą.

Moja preferencja dla tego podejścia polega na tym, że nie trzeba w ogóle zmieniać schematu DB w przypadku dodawania dodatkowych lokalizacji. W takim przypadku nie powinieneś także zmieniać swojego powiązanego kodu, ponieważ identyfikator języka staje się inną wartością, która jest używana w zapytaniu.

Źródło

2013-04-16 23:52:28

Dziękuję, pójdę po drugie – user2120569

W ten sposób zabicie bazy danych w mgnieniu oka.

Wystarczy zrobić tabelę jak:

TABLE languages with fields: 

-- product name 
-- product description 
-- two-letter language code

Pozwoli to pozwolić, nie tylko mieć usystematyzowane bazy danych, ale można nawet mieć produkty, które mają tylko jedno tłumaczenie. Jeśli chcesz, możesz nawet wyświetlić domyślny język, jeśli nie podano innych. Oczywiście, że programujesz, ale myślę, że wpadłeś na ten pomysł.

Źródło

2013-04-16 23:52:59

To jest to, co napisałem na drugiej metodzie! Dziękuję – user2120569

Dla mnie jest to najbardziej zoptymalizowana metoda :) pozwoli ci to obsłużyć, jak naprawdę chcesz. Ty decydujesz o kodzie i zachowujesz nienaruszoną czystą bazę danych :) –

Wielojęzyczna baza danych: która metoda jest lepsza?

Odpowiedz

Powiązane problemy