Witam,

Chciałbym podpytać się Was odnośnie tematu przechowywania treści w systemach
typu CMS - jak to w praktyce realizujecie? Załóżmy w uproszczeniu, że CMS to
zbiór dokumentów. Każdy z nich posiada treść, którą chcemy przeszukiwać.
Jęsli treść zawiera kod HTML to w tym momencie on też staje się
automatycznie elementem wyszukiwania, czego chciałbym uniknąć. Nie chcę aby
w wewnętrznej wyszukiwarce można było znajdować dokument po frazie np.
<table>. Czy w związku z tym stosujecie dwa pola: jedno dla treści
renderowanej a drugie z treścią bez znaczników HTML? A może zupełnie
inaczej?

do góry

W dniu 2010-03-16 14:49, Marek pisze:
> Chciałbym podpytać się Was odnośnie tematu przechowywania treści w
> systemach typu CMS - jak to w praktyce realizujecie? Załóżmy w
> uproszczeniu, że CMS to zbiór dokumentów. Każdy z nich posiada treść,
> którą chcemy przeszukiwać. Jęsli treść zawiera kod HTML to w tym
> momencie on też staje się automatycznie elementem wyszukiwania, czego
> chciałbym uniknąć. Nie chcę aby w wewnętrznej wyszukiwarce można było
> znajdować dokument po frazie np. <table>. Czy w związku z tym stosujecie
> dwa pola: jedno dla treści renderowanej a drugie z treścią bez
> znaczników HTML? A może zupełnie inaczej?

W moim przypadku jest to faktycznie osobna tabela w bazie dla potrzeb
wyszukiwania. Nie wynika to nawet z problemów ze znacznikami HTML, ale
raczej z rodzaju bazy jaką stosuję. Aby korzystać z Full-Text Search w
MySQL muszę mieć tabelę utworzoną jako MyISAM. Z perspektywy całości
CMSa zdecydowanie potrzebuję jednak tabel InnoDB (klucze obce).
Ostatecznie dubluję więc dane - to z kolei pozwala na wycinanie
znaczników dla tej tabelki przeznaczonej do wyszukiwania.
Nie wiem, czy to dobrze :)

--
Radek N.

do góry

> W moim przypadku jest to faktycznie osobna tabela w bazie dla potrzeb
> wyszukiwania. Nie wynika to nawet z problemów ze znacznikami HTML, ale
> raczej z rodzaju bazy jaką stosuję. Aby korzystać z Full-Text Search w
> MySQL muszę mieć tabelę utworzoną jako MyISAM. Z perspektywy całości CMSa
> zdecydowanie potrzebuję jednak tabel InnoDB (klucze obce).
> Ostatecznie dubluję więc dane - to z kolei pozwala na wycinanie znaczników
> dla tej tabelki przeznaczonej do wyszukiwania.
> Nie wiem, czy to dobrze :)

Dzięki za informacje :-)
W Twoim przypadku jest tak, że ograniczenia bazy zmuszają Ciebie do
określonych konstrukcji. Osobiście Postgresa używam - tam nie ma takich
ograniczeń. Nawet nie zdawałem sobie sprawy, że tak może być w innych
bazach. Moje pytanie w zasadzie koncepcji wyszukiwania tekstowego przy
założeniu, że baza nie narzuca nam jej.

do góry

On 16 Mar, 14:49, "Marek" <m...@s...interia.pl> wrote:
> <table>. Czy w związku z tym stosujecie dwa pola: jedno dla treści
> renderowanej a drugie z treścią bez znaczników HTML? A może zupełnie
> inaczej?

A co ze składnią typu Markup, Textile? Jeszcze jedno, dwa pola?

A może by tak Zend_Search_Lucene zamiast jakichś pseudo full text
search?

--
takeshin
http://lipsum.pl

do góry

> A co ze składnią typu Markup, Textile? Jeszcze jedno, dwa pola?

A w jakim celu? Jedno pole z tekstem formatowanym (obojętnie jak) a drugie
dla wyszukiwania. Tak więc nie więcej jak dwa pola będą miały ewentualne
zastosowanie. Dlatego właśnie spytałem jak to się robi w praktyze.

>A może by tak Zend_Search_Lucene zamiast jakichś pseudo full text
>search?

Czemu piszesz "pseudo" ? Czy w Postgresie to nie działa tak jak powinno?
Takie dostawki jak Zend_Search_Lucene nie spełniają roli. No bo jak odszukać
dokumenty zawierające jakieś słowo, które mają włączoną opcję A a wyłączoną
B (nie wspominając o bardziej złożonych typach pól) ?

do góry

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

> Chciałbym podpytać się Was odnośnie tematu przechowywania treści w systemach
> typu CMS - jak to w praktyce realizujecie?

Zobacz jak to jest zrobione w eZ Publish.

> Załóżmy w uproszczeniu, że CMS to zbiór dokumentów.

Bardziej myśl o zbiorze *obiektów* treści. Każdy obiekt jest zdefiniowany przez
klasę (np. folder, artykuł, produkt, plik, użytkownik, klient itd.), na klasę
składa się wiele rodzajów pól (np. identyfikator, nazwa, opis, relacja do
innego obiektu itd.).

Dodatkowo każdy obiekt posiada instancje czyli wersje oraz tłumaczenia.

> Każdy z nich posiada treść, którą chcemy przeszukiwać. Jęsli treść zawiera
> kod HTML

Nie ograniczaj się do HTML, wykorzystuj dla takich pól ogólnie XML (czyli coś
szerszego niż HTML).

> to w tym momencie on też staje się automatycznie elementem wyszukiwania,
> czego chciałbym uniknąć.

Ależ dlaczego? Wystarczy taki blok XML przetworzyć przy tworzeniu indeksu do
wyszukiwania ogołacając go z tagów i przeszukiwać po tym polu bez tagów. To
najprostsze rozwiązanie - generalnie porządne systemy bazodanowe mają coś
takiego jak funkcje do obsługi XML natywnie.

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

do góry

> Dodatkowo każdy obiekt posiada instancje czyli wersje oraz tłumaczenia.

Ten sposób przechowywania danych zarzuciłem już kiedyś. Prawie nigdy nie
zdarzałao się, że serwis WWW w wersjach jezykowych był choćby zbliżony
funkcjonalnie i pod względem treści do wersji polskiej. Wersje językowe
traktuję jako niezależne zbiory obiektów - jak to nazwałeś. Jednakże celowo
użyłem słowa "dokument" aby nie rozwodzić się nad systemami menu, obsługą
sklepów internetowych, programów lojalnościowych, forów itp. W ten sposób
byłoby 100% gwarancji, że właściwy wątek: czyli przechowywanie treści tak
aby była dobrze wyszukiwalna, uciekłby.

> Ależ dlaczego? Wystarczy taki blok XML przetworzyć przy tworzeniu indeksu
> do
> wyszukiwania ogołacając go z tagów i przeszukiwać po tym polu bez tagów.
> To
> najprostsze rozwiązanie - generalnie porządne systemy bazodanowe mają coś
> takiego jak funkcje do obsługi XML natywnie.

No to może inaczej sformułuję pytanie. Mamy tabelę "dokument" z polem
tekstowym "tresc". W treści może być wszystko: tekst + tagi (obojętne czy
HTML, XML, czy zupełnie coś innego). W jaki sposób zbudować mechanizm
wyszukujący treść z pominięciem tagów wszelkiego typu ewentualnie z
pominięciem przynajmniej XML i HTML? Czy robi się to na poziomie bazy w
sensie tworzenia w jakiś specyficzny sposób indeksów czy to np. PHP powinno
ogołocić pole z tagów i taką treść zdublować w innym polu? A może jeszcze
inaczej?

do góry

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

> Ten sposób przechowywania danych zarzuciłem już kiedyś. Prawie nigdy nie
> zdarzałao się, że serwis WWW w wersjach jezykowych był choćby zbliżony
> funkcjonalnie i pod względem treści do wersji polskiej. Wersje językowe
> traktuję jako niezależne zbiory obiektów - jak to nazwałeś.

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

(...)

>> Ależ dlaczego? Wystarczy taki blok XML przetworzyć przy tworzeniu indeksu do
>> wyszukiwania ogołacając go z tagów i przeszukiwać po tym polu bez tagów. To
>> najprostsze rozwiązanie - generalnie porządne systemy bazodanowe mają coś
>> takiego jak funkcje do obsługi XML natywnie.

> No to może inaczej sformułuję pytanie. Mamy tabelę "dokument" z polem
> tekstowym "tresc". W treści może być wszystko: tekst + tagi (obojętne czy
> HTML, XML, czy zupełnie coś innego). W jaki sposób zbudować mechanizm
> wyszukujący treść z pominięciem tagów wszelkiego typu ewentualnie z
> pominięciem przynajmniej XML i HTML?

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.

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

do góry

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

do góry

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

do góry