> No i? A kto Ci broni mieć różne obiekty w różnych językach?

Skoro brniesz w ten temat, to jako niezależny wątek też mnie on interesuje.
Więc trudno: dam się tu wciągnąć. :-)

Jeśli o moje podejście do wersji językowych, to preferuję przechowywanie
wersji językowych treści w obrębie jednej tabeli. Jeśli np. mamy sobie
tabelę "dokument" a w niej "tytuł" i "treść" to dodatkowo załączam ID wersji
językowej. Tak więc jeden rekord to dokument w języku X, a drugi rekord to
dokument w wersji Y. Łatwo w takim przypadku tworzyć wyszukiwarki dla
konkretnej wersji językowej bez konieczności JOIN'owania wielu innych tabel.
Wydaje mi się to optymalnym podejściem. Dzięki temu łatwo jest też
jednoznacznie definiować również wersje funkcjonalne (tzw. skórki serwisu).
Jeden tylko parametr (ID wersji językowej) określa z jaką skórką należy
wyświetlić dany dokument. Gdybym łączył np. 10 tabel aby każde z pól zassać
w odpowiedniej wersji to powstałoby z tego SQLowe monstrum.Trzeba też uważać
aby każdy z JOINów odwoływał się do tego samego ID. A co z tabelami, które
mają 100 pól tekstowych? 100 Joinów ?

Tyle tytułem moich przemyśleń. Chętnie wysłucham jak na przykładzie prostej
tableli z 2 polami tekstowymi w jaki sposób realizujesz takie zagadnienie:
Mamy 2 dokumenty (u mnie byłyby to 2 rekordy w tej samej tabeli o nazwie
"dokument"), każdy z nich występuje tylko w 1 wersji językowej i każdy z
nich w innej. Nie ma czegoś takiego, że dany dokument ma odpowiednik w
innych wersjach. Jakie rozwiązanie zastosowałbyś aby wylistować wszystkie
dostępne treści dokumentów w określonej wersji językowej?


> Tak niskopoziomowo to np. założyć na bazę danych trigger, który działa ON
> INSERT i UPDATE. Trigger ten aktualizuje rekord wyciągając dane, które
> wstawiłeś do tresc, przetwarza (usunięcie tagów to prosty regexp - funkcje
> wbudowane w każdą sensowną bazę danych) i zapisuje w dodatkowej kolumnie
> (czy
> nawet w ogóle w innej tabeli czy bazie) tresc_gola. Wyszukujesz po
> tresc_gola,
> wyświetlasz tresc.

A no właśnie: czyli dodatkowe pole. Wspominałeś coś o indeksach i mylnie
założyłem, że na nich coś można zdziałać bez pola "goła treść". Rozumiem, że
po w/w polu uruchamiasz full text search?
A tak na marginesie - to parser treści realizowałbym na poziomie aplikacji a
nie bazy. Tagi mogą być przeróżne. Np. stosuję w swoim CMS'ie obiekty
osadzane w treści. Może to być np. obiekt, który wyświetla imie usera, albo
dużo bardziej złożony: np. menu. Mają one specjalną składnię - nie
występującą w HTML itp. Owszem, i to da się zaimplementować w bazie lecz
wtedy trzeba dość złożone operacje wykonywać w triggerach. Jeden średnik w
złym miejscu może sporo pracy przysporzyć.