[Symfony]Baza danych zależna od _locale Opcje

[athabus]

Hej czy w Symfony dałoby się zrobić coś takiego aby framework zmieniał bazę danych w zależności od pramateru _locale? Czyli przyładowo jesli jesteśmy w www.example.com/en to wybierze inną bazę danych niż www.example.com/pl

W skrócie tworze aplikację, która będzie co prawda stała na jednej domenie, ale treść dla każdej wersji językowej jest zupełnie inna. Stałe w szablonach sobie ładnie przetłumaczę, żeby nie utrzymywać 10 wersji językowych, ale chciałbym aby bazy były różne dla każdego języka. Każda wersja będzie miała osobnych użytkowników itp.

[athabus]

Ok przespałem się z tym problemem.

To może ja sobie pozwolę podsumować wady i zalety tak jak do tej pory to zrozumiałem. Tak jak pisałem to mój pierwszy serwis kierowany na wiele lokalizacji, więc temat dla mnie zupełnie nowy. Dodam, że apka będzie stała na jednej domenie (wszystkie lokalizacje).

Wyjścia:
1. Osobne bazy na każdą lokalizację
Zalety:
- w kodzie mogę praktyczie pominąć kwestie lokalizacji (poza szablonami oczywiście). Cała zmiana sprowadza się do zmodyfikowania parametrów bazy po odczytaniu lokalizacji.
- bazy dla poszczególnych lokalizacji są rozdzielone więc w razie kłopotów z wydajnością, po prostu ustawiam bazy na różnych serwerach (problem odległy bo raczej celuję w obciążenie, które pociągnie przyzwoity vps, więc jeszcze zapas wydajności do osiągnięcia przez 1 maszynę spory, ale zawsze jest to jakaś zaleta).
- w czasie developerki oszczędzam na czasie, bo mogę wykorzystywać wbudowane mechanizmy doctrine do updetowania schematu bazy.
Wady:
- jakoś wydaje mi się to mało eleganckie rozwiązanie
- ewentualne rozjechanie się baz w czasie updatu oprogramowania. Niby nic nie powinno się stać, ale wystarczy jakiś głupi błąd typu zapomnę zaktualizować jedną z 4 baz i zonk

2. 1 baza danych a w niej tabele osobne dla każdej lokalizacji. Za pomocą filtrów zmieniamy w zapytaniu tabelę np. z Article_pl na Article_de.
W zasadzie rozwiązanie podobne do powyższego, ale jest jedna baza danych, zawsze trochę łatwiejsza do ogarnięcia i trochę bardziej elegancie rozwiązanie. Do tego można wykorzystać część tabel, które nie muszą być lokalizowane - np. użytkownik itp.

3. 1 baza danych, w tabelach każdy rekord zawiera informację jakiej lokalizacji dotyczy. Tutaj również używamy filtrów, żeby dotrzeć jedynie do rekordów z danej lokalizacji.
Zalety:
- zdecydowanie najbardziej elegancki rozwiązanie
- jest jedna baza, którą łatwo utrzymać
Wady:
- większe obciążenie dla bazy - każde zapytanie musi jednak zawierać informację o lokalizacji
- używając filtrów prawdopodobnie będę zapytania nieoptymalne przykładowo pobierając artykulu wraz z autorami będę miał zapytania typu
article join author ... where article.locale=en and author.locale=en, gdzie tak na prawdę w tym przypadku nie ma sensu filtrować dodatkowo tabeli author skoro już same artykuły pochodzą z wersji en.

Im więcej o tym myślę tym większy mam mętlik w głowie. W zasadzie dla mnie najwięcej przemawiałoby za wersją z osobnymi bazami, ale trochę obawiam się, że kiedyś będę chciał część danych mieć wspólnych (przykładowo użytkowników) i odetnę sobie taką możliwość. Wersja druga trochę przeraża mnie jeśli chodzi o utrzymanie tych tabel, ale daje ciekawą elastyczność. Wersja trzecia oznacza tak na prawdę komplikowanie nawet prostych zapytań.

Każda rada na wagę złota.