eGospodarka.pl
eGospodarka.pl poleca

eGospodarka.plGrupypl.comp.wwwCMSy - jak przechowywać treść?
Ilość wypowiedzi w tym wątku: 23

  • 1. Data: 2010-03-16 13:49:40
    Temat: CMSy - jak przechowywać treść?
    Od: "Marek" <m...@s...interia.pl>

    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?


  • 2. Data: 2010-03-16 16:28:51
    Temat: Re: CMSy - jak przechowywać treść?
    Od: "Radek N." <n...@g...pl>

    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.


  • 3. Data: 2010-03-16 17:56:26
    Temat: Re: CMSy - jak przechowywać treść?
    Od: "Marek" <m...@s...interia.pl>

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


  • 4. Data: 2010-03-16 19:16:11
    Temat: Re: CMSy - jak przechowywać treść?
    Od: takeshin <a...@g...com>

    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


  • 5. Data: 2010-03-16 21:12:26
    Temat: Re: CMSy - jak przechowywać treść?
    Od: "Marek" <m...@s...interia.pl>


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


  • 6. Data: 2010-03-17 22:46:21
    Temat: Re: CMSy - jak przechowywać treść?
    Od: Konrad Kosmowski <k...@k...net>

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


  • 7. Data: 2010-03-18 10:56:58
    Temat: Re: CMSy - jak przechowywać treść?
    Od: "Marek" <m...@s...interia.pl>

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


  • 8. Data: 2010-03-18 17:06:27
    Temat: Re: CMSy - jak przechowywać treść?
    Od: Konrad Kosmowski <k...@k...net>

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


  • 9. Data: 2010-03-19 09:41:27
    Temat: Re: CMSy - jak przechowywać treść?
    Od: "Marek" <m...@s...interia.pl>

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


  • 10. Data: 2010-03-19 18:00:20
    Temat: Re: CMSy - jak przechowywać treść?
    Od: Konrad Kosmowski <k...@k...net>

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

strony : [ 1 ] . 2 . 3


Szukaj w grupach

Szukaj w grupach

Eksperci egospodarka.pl

1 1 1

Wpisz nazwę miasta, dla którego chcesz znaleźć jednostkę ZUS.

Wzory dokumentów

Bezpłatne wzory dokumentów i formularzy.
Wyszukaj i pobierz za darmo: