** Marek <m...@s...interia.pl> wrote:

>> 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.

Widzisz - cały czas patrzysz na treść i wiążesz ją z tabelami w bazie danych co
jest zupełnie bez sensu. I od tego musisz wyjść aby zrozumieć o co mi Chodzi. W
dobrym CMS to Ciebie modelując treść w ogóle nie obchodzi co się dzieje w bazie
danych pod spodem. Baza danych to jest niskopoziomowy storage dla obiektów i
jak tam jest to zorganizowane to mnie to średnio boli używając dajmy na to eZ
Publish.

(ciach o tabelach)

>> 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?

No np. - tzn. jak wyżej, cały czas operujesz na tabelach - popatrz szerzej.

A i gwoli ścisłości to ja stosuję do wyszukiwania dedykowany mechanizm
indeksujący (Lucene), który przelatuje mi content i robi indeksy po swojemu (i
również nie obchodzi mnie jak on sobie te indeksy organizuje - nie mój
problem).

Funkcje wyszukiwania pełnotekstowego w bazie danych to jest w zasadzie marna
namiastka dobrego engine do wyszukiwania.

> A tak na marginesie - to parser treści realizowałbym na poziomie aplikacji a
> nie bazy.

Bez sensu. Wiesz bazy danych się PROGRAMUJE aby właśnie takie rzeczy robiły po
swojej stronie bo po to są. Baza danych robi to wydajniej.

> 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ć.

Jaka by to składnia nie była dla oznaczenia tagów to jest ona deterministyczna
i wycięcie znaczników z treści to jest jakby nie było prosty regexp, a nie
złożone operacje.

--
+ ' .-. .
, * ) )
http://kosmosik.net/ . . '-' . kK