![]() |
![]() |
![]() ![]()
Post
#1
|
|
Grupa: Zarejestrowani Postów: 375 Pomógł: 20 Dołączył: 28.07.2006 Ostrzeżenie: (0%) ![]() ![]() |
Temat dotyczy rozmieszczenia danych w bazie SQL. Chodzi o to, aby umożliwić jak największą współpracę i elastyczność poszczególnych elementów (artów, plików, newsów...), a za razem zachować niezależność i wydajność (np. nie ładować zbyt wielu plików przy odczycie z powodu różnic). Wypowiedzcie się na ten temat.
Teraz mam taką strukturę: artykuły, pliki, obrazy, linki i nowości są przechowywane w swoich tabelach, np. "arts", "files"... Można je przypisać do 1 kategorii o ustalonym typie (!). Nie można więc zamieścić np. linków w katalogu przeznaczonym dla artykułów. Przykład adresów: /file/50, /art/20 Każdy typ kategorii ma też oddzielny plik, wyświetlający listę znajdujących się w niej elementów. Domyślnie w szablonach dla artykułów jest to tylko tabela, zaś dla obrazów - widok typowy dla galerii. Inne spojrzenie Taka zmiana nie każdemu może odpowiadać, gdyż wiążą się z nią zarówno: większa elastyczność oraz ograniczenia. Podstawowe dane o wszystkich elementach znalazłyby się w 1 tabeli, np. "items" z polami: - tytuł - kategoria, do której należy - opis - autor / dodał - ocena - dostęp (1 - włączony, 0 - wyłączony) - opcje [być może] - ilość komentarzy [prawdopodobnie] Spowoduje to zwiększenie elastyczności. Stanie się możliwe umieszczenie w 1 kategorii elementów różnego typu, np. plików, grafiki... Wszystkie typy będą zawierać powyższe dane, a więc komentarze i oceny zagoszczą nawet pod informacjami o odnośniku (na osobnej stronie). W ustawieniach kategorii pojawi się opcja: "widok elementów", np. "miniatury" (jak w galerii), "lista". Adresy mogą przybrać formę jak obecnie lub: /item/50, /view/50 Operacje typu: sortowanie wg oceny, pokazywanie / liczenie ilości komentarzy... prawdopodobnie staną się łatwiejsze i mniej skomplikowane. Zmiana niesie za sobą również ograniczenia. Zmniejszy się niezależność każdego typu kategorii na rzecz większej integracji i spójności. Generalnie wyświetlanie dodatkowych informacji o plikach na liście (np. jak w PHP-Fusion) będzie niemożliwe, chyba że pozwoli na to specjalny dla plików widok (wstawienie np. linku może spowodować problem!). (*) Pozostaje pytanie, czy jest sens tworzyć dodatkową tabelę dla linków, aby trzymać tam jedynie adres URL, ilość kliknięć i opcje (otwórz w nowym oknie). Ten post edytował WebCM 21.05.2008, 15:50:35 |
|
|
![]() |
![]()
Post
#2
|
|
Grupa: Zarejestrowani Postów: 149 Pomógł: 12 Dołączył: 3.03.2008 Skąd: łódzkie Ostrzeżenie: (0%) ![]() ![]() |
Niejaki SasQ na grupie pl.comp.lang.php dał Ci już linka do bardzo wartościowego Bloga sześciu Geeków z Sioux Falls, South Dakota, USA (IMG:http://forum.php.pl/style_emoticons/default/smile.gif)
Ja również podam to co on i dwa artykuły więcej, bo cały dzień siedzę i czytam od deski do deski tego bloga. Jest tam super wyłożona problematyka CMSów. Polecam dogłębnie przestudiować tego bloga. Jest kategoria o CMSach. Postów jest sporo i niektóre już są stare, ale myślę, że wciąż aktualne. Autor bardzo wychwala architecture eZ Publish. Co do Twoich rozważań to przeczytaj sobie w kolejności jak podaje: 1) http://www.gadgetopia.com/post/259 (Open and Closed Content Management) 2) http://www.gadgetopia.com/post/4203 (The Envelope Pattern of Content Management) 3) http://www.gadgetopia.com/post/4237 (The Content Tree) Ten post edytował jarek_bolo 23.05.2008, 13:07:09 |
|
|
![]() ![]() |
![]() |
Aktualny czas: 4.10.2025 - 03:22 |