[Symfony] "Rozproszona" aplikacja Opcje

[phpion]

Witam,
nie wiem czy tytuł tematu opisuje dobrze mój problem ale mam nadzieję, że tak właśnie jest.

Otóż przymierzamy się do pisania sklepu internetowego. Sklep będzie posiadał m.in. standardowe tabele typu użytkownicy, kategorie, produkty itd. Założenia są takie aby uruchomić sklep główny, a równocześnie móc prowadzić sklepy podrzędne (stojące na tym samym serwerze co sklep główny). Sklepy podrzędne miałyby wszystkie tabele własne poza tabelą produktów, która byłaby wspólna dla wszystkich sklepów (m.in. wspólne ceny, stany magazynowe itd). Jak to teraz najlepiej rozegrać?

Początkowo myśleliśmy aby każdy sklep posiadał własne tabele oraz tabele typu master (m.in. właśnie produkty). Wiem, że można w Symfony korzystać z kilku baz równocześnie (link). Jednak takie rozwiązanie wymusza duplikację kodów na poziomie PHP (nowy sklep = nowy projekt = przekopiowanie odpowiednich klas). Czy jest jakiś sprytny myk, dzięki któremu wszystkie te aplikacje korzystałyby z jednych zasobów kodów PHP?

Kolejnym pomysłem jest stworzenie jednej aplikacji, która w każdej tabeli w bazie danych przechowuje id typu aplikacji podrzędnej. W bootstrapie możnaby wówczas określać id aktualnie używanego sklepu (po adresie) i tworzyć odpowiednią wartość konfiguracyjną (chociażby zdefiniować stałą). Może nie w bootstrapie - to gdzie?

Reasumując: system powinien spełniać wymogi:
- wspólne źródła danych dla poszczególnych pod-aplikacji (typu produkty)
- osobne źródła danych dla poszczególnych pod-aplikacji (typu użytkownicy)
- korzystanie z jednych i tych samych plików klas, modeli, szablonów itd.

Miał ktoś podobny dylemat?

Pozdrawiam,
pion

Ten post edytował phpion 11.07.2008, 11:42:50

[LBO]

Propel bez probleemu coś takiego obsłuży, jeżeli nie chcesz pracować na generowanych obiektach dla różnych tabel, możesz zawsze pobawić się z samym dziedzczeniem, ustaw jakąś klasę bazową dla modeli Propela i w nim podstawiaj odpowiednie dane (np prefix tabel?). Propel to naprawdę narzędzie o ogromnych możliwościach.
Działałoby tak jak chcesz, transparentnie dla reszty aplikacji, gdyz modyfikujesz tylko logikę Modelu.

[phpion]

Czyli sugerujesz dublować tabele dodając do nich odpowiedni preffix? W sumie takie rozwiązanie również wchodziłoby w rachubę... W sumie mogłoby być nawet nie tak źle.
Jeśli ktoś miałby jakieś zdanie na ten temat to prosiłbym o opinię.

[LBO]

A jak inaczej to sobie wyobrażasz, jeżeli chcesz to załatwic na niższym poziomie to zaprojektuj odpowiednio (baaardzo relacyjnie) bazę danych.

Wydaje mi się nawet, że najlepszym sposobem byłaby hybryda dwóch powyższych pomysłów.

@phionie, przeczytałem Twojego drugiego posta i wydaje mi się, że drugie rozwiązanie było by najlepsze z uwzględnieniem moich powyższych rad (zawierałoby już przystosowanie struktury db)

Pytałeś sie gdzie okreslać identyfikator sklepu - i tu wchodzą możliwości Propela. Okresl to na poziomie modelu. W tym podmianę niektórych konfoguracji (typu foldery styli i zdjęć). Pełna transparentnośc dla aplikacji.
Jeżeli chodzi o podmianę skórek - najlepiej bedzie wykorzystać mocno nadmiarowe okodowanie XHTML, tak żeby mozna było wszystko za pomocą styli zrobić.

Ten post edytował LBO 11.07.2008, 12:46:50

[phpion]

Dzięki serdeczne za konkretną koncepcję. Coprawda na razie nie wiem jeszcze jak się za to wszystko zabrać ale będę próbował. W każdym bądź razie dzięki serdeczne za pomoc, w razie problemów będę pisał. Jeszcze raz dzięki.

PS: wydaje mi się, że rozwiązanie z identyfikatorem sklepu na poziomie poszczególnych tabel będzie faktycznie najlepsze. Zalety:
- brak duplikacji tabel; z czasem mogłoby być ich sporo
- ewentualna modyfikacja modelu (czyli i struktury tabel) nie byłaby trudna
- wygenerowanie admina również nie powinno stanowić problemu (podczas logowania wybieramy rodzaj sklepu i na podstawie tej wartości ustawiany jest jakiś mega globalny filtr)
- dodanie/usunięcie sklepu - również nie stanowi najmniejszego problemu



Ten post edytował phpion 11.07.2008, 12:52:59

[destroyerr]

Ja widzę to tak:
Ustawiasz połączenie (w database.yml) do głównej bazy, gdzie masz produkty i tabele z konfiguracją wszystkich sklepów.
Tworzysz model dla produktów z jednym połączeniem (powiedzmy propel, czyli standardowo), i całą reszte modeli z połączeniem o nazwie custom.
Tworzysz sobie filtr, który na podstawie adresu określa, który to sklep i pobiera z bazy danych jego konfiguracje (nazwe bazy danych, usera, haslo etc.). Na podstawie tych danych tworzysz nowe połączenie (sfPropelDatabase) i dorzucasz do symfony (sfDatabaseManager) jako custom.

Powinno działać. Jest w sumie jeszcze możliwość wykorzystania do tego i18n, ale to chyba zbyt przekombinowane

Ten post edytował destroyerr 11.07.2008, 13:23:06