W dniu 2010-03-19 19:00, Konrad Kosmowski pisze:
> 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.
>

Ok, więc tym bardziej interesuje mnie ta koncepcja. Możesz coś więcej
napisać jak fizycznie zrealizowałbyś struktury w bazie dla obiektu o
nazwie "dokument" posiadającego, dla uproszczenia, tytuł i treść?

do góry

Dnia Tue, 16 Mar 2010 22:12:26 +0100, Marek napisał(a):

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

Bardzo prosto, przeczytaj dokumentację. Zend_Search_Lucene ma mnóstwo
opcji.

--
Borys Pogoreło
borys(#)leszno,edu,pl

do góry

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

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

> Ok, więc tym bardziej interesuje mnie ta koncepcja. Możesz coś więcej napisać
> jak fizycznie zrealizowałbyś struktury w bazie dla obiektu o nazwie
> "dokument" posiadającego, dla uproszczenia, tytuł i treść?

No przecież już piszę bodajże trzeci raz - zobacz jak to jest zrobione w eZ
Publish. To produkt open source, więc możesz sobie wszystko obkumać.

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

do góry

> No przecież już piszę bodajże trzeci raz - zobacz jak to jest zrobione w eZ
> Publish. To produkt open source, więc możesz sobie wszystko obkumać.

Ahhh... rozumiem. Rozwiązujesz problem poza bazą danych, programowo,
bazując na CMS EZ Publish. Zrozumiałem to nieco inaczej.

Jestem na ich stronie. Trochę trudno będzie mi analizować cudze
oprogramowanie aby ideę wyłapać w sensie zasad tworzenia struktur bazy
danych. To bardzo obszerny materiał.

do góry

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

>> No przecież już piszę bodajże trzeci raz - zobacz jak to jest zrobione w eZ
>> Publish. To produkt open source, więc możesz sobie wszystko obkumać.

> Ahhh... rozumiem. Rozwiązujesz problem poza bazą danych, programowo, bazując
> na CMS EZ Publish. Zrozumiałem to nieco inaczej.

Nie rozwiązuje żadnego problemu bo go nie ma. Baza danych jest zorganizowana w
ten sposób aby przechowywać obiekty:

http://share.ez.no/var/community/storage/images/medi
a/images/simplified_ez_publish_database_model_large2
/317811-1-eng-GB/simplified_ez_publish_database_mode
l_large.png

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

do góry

> Nie rozwiązuje żadnego problemu bo go nie ma.

Problem = zagadnienie. Teraz lepiej ? :->

Baza danych jest zorganizowana w
> ten sposób aby przechowywać obiekty:
>
> http://share.ez.no/var/community/storage/images/medi
a/images/simplified_ez_publish_database_model_large2
/317811-1-eng-GB/simplified_ez_publish_database_mode
l_large.png
>

Jak rozumiem definicjami obiektów jest kolumna "content class". Gdy
powstaje jakaś konkretna treść to wypełniane są struktury z kolumny
"instance"? Czyli gdy np. mamy dokument, który ma tytuł, streszczenie i
treść, to powstają 3 instancje z 3 różnymi content_class_id (oddzielne
ID dla tytułu, streszczenia i treści). Treść tych sekcji mieści się w
polu data. Czy dobrze interpretuję schemat?

Skąd jednak wiadomo w takim przypadku, że te 3 obiekty to skład jednego
dokumentu?

do góry

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

>> http://share.ez.no/var/community/storage/images/medi
a/images/simplified_ez_publish_database_model_large2
/317811-1-eng-GB/simplified_ez_publish_database_mode
l_large.png

> Jak rozumiem definicjami obiektów jest kolumna "content class".

To jest definicja klasy obiektu - tak. Klasa to jest dajmy na to:
- artykuł posiadający atrybuty tytuł i treść (uproszczenie)
- recenzja książki posiadająca atrybuty tytuł, treść i ISBN

> Gdy powstaje jakaś konkretna treść to wypełniane są struktury z kolumny
> "instance"?

Tak - powstaje instancja obiektu.

> Czyli gdy np. mamy dokument, który ma tytuł, streszczenie i treść, to
> powstają 3 instancje z 3 różnymi content_class_id (oddzielne ID dla tytułu,
> streszczenia i treści).

Nie. Powstaje jedna instancja obiektu, którego atrybuty odpowiadają klasie
obiektu.

> Treść tych sekcji mieści się w polu data. Czy dobrze interpretuję schemat?

Do momentu atrybutów obiektu tak.

http://ez.no/doc/ez_publish/technical_manual/4_x/con
cepts_and_basics/content_management/the_content_obje
ct

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

do góry

Naprawdę bardzo podoba mi się ta koncepcja choć nie jestem w 100%
przekonany czy to co w swoim CMS'ie stosuję nie jest wydajniejsze.
Chodzi o przechowywanie podstawowej informacji o dokumencie (tytuł,
słowa kluczowe, streszczenie, treść podstawowa plus jeszcze jakieś
drobiazgi) w jednej tabeli. Ułatwia to wyszukiwanie bez obciążających
joinów. Przy zastosowaniach CMS w portalach o dużej odwiedzalności
znacznie ułatwia to również tworzenie cache podstawowych struktur
(=zawsze wyświetlanych podczas dostępu do konkretnych dokumentów). W
efekcie udało mi się doprowadzić do sytuacji, w której odczyt dokumentu
nie angażuje bazy danych a liczba operacji IO też jest minimalna. Przy
takim rozdrobnionym podejściu obawiam się, że albo bazę zajedziemy albo
obciążenie IO serwera da nam po kieszeni gdy spróbujemy to cache'ować.

Z drugiej zaś strony takie totalnie quasi-obiektowe podejście daje
elastyczność w szerokim zakresie. Chyba nie ma kompromisu...

do góry

W dniu 2010-03-22 21:05, Marek pisze:
> Naprawdę bardzo podoba mi się ta koncepcja choć nie jestem w 100%
> przekonany czy to co w swoim CMS'ie stosuję nie jest wydajniejsze.
> Chodzi o przechowywanie podstawowej informacji o dokumencie (tytuł,
> słowa kluczowe, streszczenie, treść podstawowa plus jeszcze jakieś
> drobiazgi) w jednej tabeli.

Kolejny raz napiszę, że to bzdurne podejście. Przyznaj się, że gubisz
się w kodzie przy ilości tabel > 1, a nie teorie sobie dorabiasz.
Szczególnie, że dalej twierdzisz, że wrzucasz kontent do cache, co
powinno dodatkowo niwelować narzut na bazę. Tak w ogóle, MySQL też
potrafi keszować sobie zapytania, czyli oszczędzasz co najwyżej na
czasie generowania treści.

artur

do góry

> Kolejny raz napiszę, że to bzdurne podejście.

To prawda - lecz nie rozwijasz wątku. Bzdurne bo Ty stosujesz inne
rozwiązanie? To słaby argument.

> Przyznaj się, że gubisz
> się w kodzie przy ilości tabel > 1, a nie teorie sobie dorabiasz.

Po pierwsze tabel mam 96 i jakoś nie gubię się w tym, po drugie
chciałbym abyś wykazał iż tyle samo czasu CPU zajmie zapytanie
składające się z SELECT * FROM tabela oraz SELECT * FROM tabela JOIN
inna_tabela JOIN jeszcze_inna JOIN kolejna. Nie wiem na czym opierasz
swoje twierdzenie, że takie rozbudowywanie zapytań SQL w niczym nie
szkodzi. Otrzymałem skrajnie odmienne wyniki pomiarów.

> Szczególnie, że dalej twierdzisz, że wrzucasz kontent do cache, co
> powinno dodatkowo niwelować narzut na bazę. Tak w ogóle, MySQL też
> potrafi keszować sobie zapytania, czyli oszczędzasz co najwyżej na
> czasie generowania treści.

Akurat nie stosuję MySQL'a aby wypowiadać się w sprawie tej bazy lecz
wydaje mi się ciekawym zagadnienie cache'owania zapytań przez samą bazę.
Nie wyobrażam sobie jak taki mechanizm może funkcjonować jeśli baza "nie
wie" co najczęściej będzie czytane i jak dalej przetwarzane i w związku
z tym co należy cacheować. W innych bazach: PostgreSQL, M$ SQL nie
zaobserwowałem takiego mechanizmu o jakim piszesz dla zapytań typu
SELECT * FROM tabela WHERE tabela_id=losowy_id (bo nie można przewidzieć
o jaki ID będzie zapytanie). Zapytanie pochłania znacznie więcej taktów
CPU niż odczyt z cache tych samych informacji a już nie wspomnę o danych
przetworzonych wstępnie - głównie to jest przedmiotem cacheowania w moim
CMS a nie same zapytania SQL. Są to np. wyniki rekurencyjnych zapytań
SQL często powtarzanych przy odwiedzaniu serwisu WWW - np. dla struktur
menu, kategorii i innych hirerchii, wstępnie przetworzone fragmenty
stron WWW, które nie muszą być dynamicznie aktualizowane itp.

do góry