[Symfony] architektura aplikacji Opcje

[Foxx]

1. Załóżmy, że we frontendzie mam moduły "aktualności" i "artykuły".
Czy jeżeli nie różnią się niczym poza faktem, że aktualności są zwykle nieco krótsze to czy powinienem zrobić jedną tabelę "tekst" z polem mówiącym o typie (aktualność/artykuł) i rozdzielać je na poziomie zapytania SQL czy raczej stworzyć osobne dwie tabele?

2. Załóżmy, że mam we frontendzie moduły "regulamin", "polityka prywatności" i "współpraca" - które są tylko podstronami tekstowymi. Czy powinienem stworzyć dla nich osobne tabele z 1 rekordem ( (IMG:http://forum.php.pl/style_emoticons/default/worriedsmiley.gif) ) czy raczej jedną tabelę "tekst" z polem mówiącym o typie tekstu (regulamin/polityka/etc.) ?

3. Załóżmy, że chcę umożliwić userowi konfigurację pewnych elementów strony. Czy powinienem stworzyć tabelę z tyloma polami ile mam parametrów i jednym rekordem czy raczej tabelę z polami "klucz" i "wartość" i z rekordami w ilości równej ilości parametrów, czy może jeszcze coś innego?

4. Skąd czerpiecie tego typu wiedzę na temat prawidłowej architektury aplikacji w sf i nie tylko sf?

Ten post edytował Foxx 12.02.2009, 05:05:43

[Rafal Filipek]

1) zrob 2 osobne "moduły". Nie bedziesz musial kombinowac w modelach itp itd. Poza tym pozwoli ci to na łątwą ewentualną rozbudowę w przyszłości. Od dodatkowej tabeli w bazie jeszcze nikt nie umarł (IMG:http://forum.php.pl/style_emoticons/default/smile.gif)
2) Zastanów się czy chcesz aby treści na tych stronach były edytowane czy nie. Bo jak ma być to najzwyklejszy tekst to bym wpakował go do szablonu bezpośrednio i nie bawił się z bazami. Natomiast jeżeli chcesz mieć X stron których treść chcesz potem zmieniać to zrób sobie tabele pages i tam trzymaj wszystkie treści.
3) Zapewne możliwości konfiguracyjne są identyczne dla każdego użytkownika i nie zmieniają się wcale lub bardzo rzadko. W takim przypadku możesz zrobić to na 2 sposoby. Albo dodać pola konfiguracyjne bezpośrednio do tabeli użytkowników albo stworzyć osobną tabelę z konfiguracjami gdzie każdy rekord ma user_id. W 1 przypadku nie będziesz musiał klepąć nic nowego bo konfigurację będziesz miał już w formularzu użytkownika ( co może okazać się niepożądane ). W 2 przypadku rozdzielisz użytkownika od konfiguracji co przy większej ilości parametrów konfiguracyjnych moim zdaniem wydaje się lepszym rozwiązaniem.

[Foxx]

Ad 3) Użyłem złego słowa, pisząc "user" miałem na myśli administratora systemu. Jeżeli chodziłoby o zwykłego usera to oba Twoje rozwiązania można stosować w zależności o jakich danych i jakiej ich ilości jest mowa - tak jak piszesz. Ale moje pytanie jest bardziej przyziemne (IMG:http://forum.php.pl/style_emoticons/default/wstydnis.gif) Czy tworząc możliwość konfiguracji parametrów systemu (np. możliwość pisania postów przez niezarejestrowanych: off) praktykuje się raczej tabelę klucze -> wartości czy tabelę z 1 rekordem i z polami dla każdej opcji?
Czuję że rozwiązanie z 1 rekordem jest w jakiś sposób nieeleganckie a z drugiej strony klucz+wartość jest takie... niestałe (IMG:http://forum.php.pl/style_emoticons/default/smile.gif)

[dr_bonzo]

1. Jesli rozchodzi sie tylko o 2 moduly - to jak kolega pisze - zrob osobne tabele, bo chyba nie robisz mega uniwersalnego CMSa jak taki EZ gdzie wszystko jest w ... "jednej tabeli"
2. Info strony - 1 tabela, po rekordzie na strone i po problemie, ew. w templatkach edytujesz - jesli ci to wystarcza.

3. Konfiguracja

Czy tworząc możliwość konfiguracji parametrów systemu (np. możliwość pisania postów przez niezarejestrowanych: off) praktykuje się raczej tabelę klucze -> wartości czy tabelę z 1 rekordem i z polami dla każdej opcji?

A chcesz zmieniac format tabeli po kazdym dodaniu nowego klucza/wartosci?
I co to jest "takie niestale"? Ja mam u siebie rekordy [nazwa,wartosc] i sie sprawdza (uzywam notacji: 'podsystem.costam.cos' dla nazw,
np. 'forum.posting.unregistered_user_may_post' => zalety: czytelne, zapobiega kolizji nazw)