Rozbudowana aplikacja analiz sprzedaży, jak stworzyć przyjazny kod?

0

Witam,
Mam stworzone dość złożone analizy sprzedaży, cały kod to dwa pliki: config.php i index.php.
Całość podzielona jest na 3 pętle.

Jedna która pobiera dane z odległych serwerów MSSQL, bądź lokalnego serwera MYSQL (cache) jeśli stwierdzi, że nie ma potrzeby odświeżania danych.

Druga, która przygotowuje na podstawie powyższych danych dane do tabelek i pakuje je w tablice w stylu

$dane['sprzedaz']['dzienna'][$id_oddzialu][$rok][$miesiac][$dzien] (jest to obrót z danego oddziału z danego dnia)

lub

$dane['sprzedaz']['dzienna_suma'][0][$rok][$miesiac][$dzien] (jest to suma obrotów z wszystkich oddziałów z danego dnia)

Czasem też oddział składa się z kilku magazynów i druga pętla musi niektóre parametry zsumować, uśrednić, lub wybrać wartość z ostatniego dnia miesiąca, lub ostatniego roboczego dnia miesiąca i wiele takich dziwnych operacji.

Trzecia pętla odpowiada za generowanie tabelek table, th, tr, td itd., tutaj też znajdują się funkcje kolorujące, na przykład komórke tabeli w której widnieje najwyższy wynik sprzedaży danego oddziału zaznacza na zielono.
Poza tym jeśli wystąpił spadek/wzrost sprzedaży w porównaniu do dnia poprzedniego to koloruje taką komórke na czerwono/zielono.

Po trzeciej pętli jest jeszcze kilka mniejszych odpowiadających za mniejsze tabelki z parametrami towarów nierotujących, oraz porównanie wyników sprzedaży oddziału do zadanych parametrów.

Na końcu jest funkcja pakująca to wszystko na maila i wysyłająca.
Są też dwie wersje zestawienia krótka i długa. Krótka jest wysyłana codziennie pod koniec dnia pracy, natomiast długa generowania jest wieczorem.

Do czego zmierzam?
Mój kod jest napisany mało rozwojowo, zmiana kolejności kolumn tabeli to męka, bądź też dodanie nowych oddziałów.

Chciałbym napisać to ustrojstwo od początku i ubrać w ładne klasy, gdzie zadawał bym parametry serwera, magazynów, rejestrów sprzedaży, kas, wszelkie nazwy oddziałów itd.
Do tego też gdzieś muszę zadać czas życia oddziału (data otwarcia, data zamknięcia) tak by generowały się tylko aktualne.

Chciałbym prosić o pomoc jak logicznie podzielić kod i zrobić to na klasach, ale nie mam doświadczenia na jakie klasy to podzielić.

Jakaś klasa odpowiedzialna za przygotowanie danych gdzie będzie precyzować się parametry oddziałów adres serwera, magazyny, rejestry sprzedaży, kasy, data otwarcia, zamknięcia, a druga odpowiedzialna za widok np. wersja HTML-owa, Excelowa, bądź na tel. która tez musi się odnieść np. do daty otwarcia i zamknięcia (żeby wiedzieć co wyświetlić).

Jak to powinno wyglądać?

Pozdrawiam

0
theta napisał(a)

Jedna która pobiera dane z odległych serwerów MSSQL, bądź lokalnego serwera MYSQL (cache) jeśli stwierdzi, że nie ma potrzeby odświeżania danych.

Czy to znaczy, że wszystkie Twoje dane ściągasz tylko z jednej tabeli?

theta napisał(a)

Druga, która przygotowuje na podstawie powyższych danych dane do tabelek i pakuje je w tablice w stylu
$dane['sprzedaz']['dzienna'][$id_oddzialu][$rok][$miesiac][$dzien] (jest to obrót z danego oddziału z danego dnia)

lub

$dane['sprzedaz']['dzienna_suma'][0][$rok][$miesiac][$dzien] (jest to suma obrotów z wszystkich oddziałów z danego dnia)

Nie wiem jak wyglądają Twoje dane, ale sześciowymiarowa tabelka, to chyba zły pomysł. Na pierwszy rzut oka zrobiłbym zmienne $sprzedarz_dzienna i $sprzedarz_dzienna_suma, a zamiast [$rok][$miesiac][$dzien] stosował [$data]. Oczywiście zasadność pierwszego i drugiego pomysłu zależy od tego co właściwie masz zrobić...

theta napisał(a)

Czasem też oddział składa się z kilku magazynów i druga pętla musi niektóre parametry zsumować, uśrednić, lub wybrać wartość z ostatniego dnia miesiąca, lub ostatniego roboczego dnia miesiąca i wiele takich dziwnych operacji.

Czy tego sumowania, uśredniania, wybierania i innych niedziwnych operacji nie można przerzucić na bazę danych?

theta napisał(a)

Jakaś klasa odpowiedzialna za przygotowanie danych gdzie będzie precyzować się parametry oddziałów adres serwera, magazyny, rejestry sprzedaży, kasy, data otwarcia, zamknięcia, a druga odpowiedzialna za widok np. wersja HTML-owa, Excelowa, bądź na tel. która tez musi się odnieść np. do daty otwarcia i zamknięcia (żeby wiedzieć co wyświetlić).

Rozdzielenie logiki od widoku wydaje się ogólnie być rozwiązaniem słusznym. Czy wiesz i rozumiesz czym jest i jak "działa" MVC?

Na razie podałeś za mało informacji, żeby móc zaproponować konkretny podział na klasy.

1 użytkowników online, w tym zalogowanych: 0, gości: 1