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

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

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

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

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)