Usługa na abonament, zmiana pakietu

0

Mam usługę, którą rozliczana jest abonamentowo, czyli kupujesz bezterminowo i co miesiąc płacisz abonament. Są różne warianty pakietów. Jednak możesz w dowolnym momencie zmienić pakiet na inny, data aktywacji nowego zależy od różnych czynników, dla uproszczenia załóżmy że to pierwszy dzień kolejnego miesiąca. Są pakiety indywidualne i grupowe, czyli można usługę współdzielić z innymi osobami. Jest możliwość zmiany pakietu z indywidualnego na grupowy.

Zastanawiam się jak podejść do tematu składowania danych, kiedy zmienia się pakiet.

  1. mam tabelkę zamówienie i podrzędną na pakiet z polami aktywny od - do, czyli wszystkie zmiany pakietów są cały czas jako jedno zamówienie
  2. informację o pakiecie i aktywności mam w zamówieniu, a zmiana pakietu powoduje na poziomie bazy stworzenie nowego zamówienia aktywnego od następnego mies., a stare zamówienie dostaje datę końca na ostatni dzień aktualnego mies.

Ktoś robił podobny system i może jakieś plusy i minusy obu podejść wskazać?

Ja widzę takie:

add 1:

  • cały czas mam jedno zamówienie
  • wszystkie dane zależne z tabel podrzędnych zamówienia nie wymagają kopiowania

add 2:

  • wszystkie inne dane zależne, powiązane z zamówieniem także należy skopiować, czyli dane abonentów etc.
0

chcesz powiedzieć, że nie masz tabeli z abonentami tylko ich dane są w zamówieniach???? Trochę to dziwnie wygląda. Wg mnie powinno być tak:

  1. Abonent to abonent i jego dane powinny być w jednym miejscu
  2. Zamówienie to zamówienie - to jest tylko żądanie zmiany usługi i może ale nie musi być zrealizowane. Co ważniejsze zamówienie jest zlecane przez konkretnego JEDNEGO abonenta.
  3. Pakiet to coś co jest niejako narzucone (ustalone) z góry i jest go ograniczona liczba. Co więcej ten sam pakiet może 'należeć' do różnych abonentów, albo inaczej różni abonenci mogą korzystać z tych samych pakietów.
  4. Teraz normalnie dodaje się dodatkową tabelę abonent<->pakiet, która łączy te dwie tabele. Zalety: a) jeden abonent może mieć różne pakiety w tym samym czasie (o ile zachodzi taka potrzeba), b) z tego samego pakietu mogą korzystać różni abonenci w różnych okresach czasu, c) jeśli dodatkowo dodasz do niej jeszcze pole z id_zamówienia masz pełną historię kto, kiedy, od jakiego momentu i na jaki czas coś zmieniał, d) nie masz redundancji danych. Wady: trochę bardziej skomplikowana struktura (ale czy to wada). Rekord do tej tabeli jest dodawany w momencie, kiedy zamówienie jest zaakceptowane/przyjęte do realizacji
0

Oczywiście że mam osobną tabele na abonentów i kilka innych podrzędnych.
abon.png
W wersji 1 informacja o pakiecie jest w zamówieniu, więc zmiana pakietu = nowe zamówienie.
W wersji 2 mam dodatkową tabelę łączącą zamówienie z pakietem, więc zmiana pakietu to inny wpis w niej, a zamówienie pozostaje ciągle to samo (czyli OrderId).
Założenie jest akurat takie że klient w danym czasie może mieć dokładnie jeden pakiet aktywny.
Oczywiście nie przedstawiam tu pozostałych informacji składowanych w poszczególnych tabelach, bo nie jest to istotą problemu.

Chyba ostatnio systemy z którymi pracuję wyjątkowo mnie otępiają.

Właściwie chyba faktycznie nie ma tu co główkować i wariant 2 jest słuszny. Ale tak to jest jak klientowi się w trakcie coś przypomina i człowiek głowi się jak tu zmienić struktury żeby jak najmniej rozwalić z tego co jest do tej pory. Na szczęście implementacja jest we wczesnej fazie i nie powinno być problemu.

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