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.

Musisz sobie zalozyc event na requescie i podmieniac parametry z configa kiedy tam bedziesz potrzebował.

Poza wieloma bazami danych możesz też rozważyć użycie jednej bazy danych i dodawanie do każdej encji właściwości określającej język do jakiego przynależy, a do obsługi wykorzystać filtry w Doctrine.

Dzięki chłopaki oba rozwiązania fajne. Zanim pomyślałem o kilku bazach kombinowałem z tłumaczeniami, ale w moim przypadku nie miały one sensu (content się generalnie nie pokrywa) - rozwiązanie z filtrami jest o tyle ciekawe, bo ułatwiło by utrzymanie serwisu. Zarządzanie kilkoma bazami to jednak trochę zabawy. Muszę w przyszłym tygodniu wypróbować to rozwiązanie.

Jeszcze raz dzięki za pomoc.

A może http://propelorm.org/Propel/behaviors/i18n.html (Propel)

A widzisz, tylko cały problem rozbija się o to, że ja nie chcę tłumaczyć contentu, tylko mieć niezależny content. Przykładowo np. projektując serwis z wynajmem domów w Anglii będę miał inne domy niż w PL. Mi tu właśnie bardziej chodzi o coś takiego jak podał destroyer - czyli np. wersja angielska korzysta tylko z rekordów czy tabel które są lokalizowane jako angielskie. Serwis nad którym teraz pracuję ma właśnie taką charakterystykę, że tak na prawdę każda lokalizacja będzie miała zupełnie inny zestaw danych.
Można to było oczywiście załatwić dodając przy każdym rekordzie lokalizację i modyfikując zapytania doklejając wszędzie "where locale=pl", ale to takie mało eleganckie rozwiązanie i strasznie rozdmuchujące kod. Filtry (jeśli je dobrze rozumiem) pozwolą mi wyrzucić lokalizację z kodu i robić ją "w tle".

Ciekaw jestem, czy w praktyce to tak ładnie zadziała jak mi się teraz w głowie klaruje, ale jak będzie z tym za dużo zabawy, to wrócę do pomysłu z rozdzielnymi bazami i twoim pomysłem podmiany parametru.

Ale schematy baz danych masz takie same

Hej tak schemat bazy jest identyczny dla każdej lokalizacji. Podobnie interfejs jest jeden (tylko oczywiście lokalizowany za pomocą tłumaczeń).
Na razie nie chciałbym zdradzać pomysłu, ale przez podobieństwo dajmy na to, że prowadzę serwis wielojęzyczny w wordpresie.

Wersja pl i angielska mają zupełnie inne artykuły, zupełnie inne działy, tagi i kategorie itp.

Tak więc w zasadzie baza jest taka sama jeśli chodzi o schemat, ale powiedzmy dane nie są tłumaczone na różne języki, tylko każdy język ma swój zestaw danych (bazując na przykładzie - np. wersja angielska ma artykuły o lalkach barbie, a rosyjska o matrioszkach). Bardziej miałbym tutaj taki model, że Doctrine po prostu ma pomijać rekordy należące do innej niż wybrana lokalizacji we wszystkich swoich zapytaniach. Albo mógłby to być taki model, że każdy kraj ma osobny zestaw tabel np. na zasadzie tabela1_pl tabela1_de tabala1_gb i po prostu doctrine dynamicznie podminia postfix tabeli używanej w zapytaniu w zależności od lokalizacji użytkownika.

Dodam też, że jest to pierwszy serwis wielojęzyczny jaki robię, więc mogę coś źle rozumieć jeśli chodzi o idę, ale bardziej rozumiem, że zastosowanie tego co proponujesz z Propela sprawdzałoby się, gdybym miał wordpressa w którym pokrywałyby się kategorie, artykuły itp - tyle, że miałyby kilka wersji językowych.

IMO bardzo dobrze robisz dzieląc to na osobne bazy danych, najlepszy pomysł.

@skowron-line jakieś argumenty za tym, że osobne bazy to najlepszy pomysł?

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.

Wersja z jedną bazą jest chyba najbardziej optymalna, tym bardziej że BD byłby dokładną kopią innych.

Filtrowanie contentu na podstawie języka to jest normalne i ja osobiście nie widzę nic w tym złego bo dodawanie warunków na lokalizację zrobisz raz i potem masz elastyczność i dodajesz tylko kolejny język w jednym miejscu, a tak musiałbyś stawiać kolejną BD, czyścić, dbać o spójność.

Tak sobie jeszcze teraz myślę nad responsywnością aplikacji stojącej w Europie, a klient jest w USA. Aplikacja w dużej mierze będzie opierała się na AJAX i z tej przyczyny bardzo by mi zależało na dobrej responsywności - w przypadku php nie ma problemu, bo łatwo sobie przekieruje zapytania z USA na serwer stojący w tej lokalizacji, ale co się w takim przypadku robi z bazą?

Możesz postawić replikację master-master,