[MySQL] Zamówienia, dostawy i płatności Opcje

[SmokAnalog]

Cześć,

będę tworzył bazę danych z zamówieniami, dostawami i płatnościami. Chciałbym, żebyście podzielili się swoimi pomysłami.

Klienci mogą zamawiać pakiety usług. Powiedzmy, że mamy usługę X, usługę Y i usługę Z. Każda z nich może być zakupiona w pakiecie 1, 3, 7 lub 14. Klienci mogą je realizować w dowolnym dniu, chociaż normą jest realizacja ich dzień po dniu. Jest to typ usług, które realizuje się regularnie.

Na pewno muszę dodać tabelę zamówienia, która będzie zawierała ID usługi, ID klienta, cenę i liczbę w pakiecie.

Nieco więcej wątpliwości mam z tabelą dostawy. Powinny być pewnie połączone z zamówieniem. Zastanawiam się co robić w przypadku, kiedy zamówienia nie ma (bo np. poprzednie już się wyczerpało), a zakładamy, że ktoś jednak chce zakupić usługę. To w tym przypadku nie jest wykluczone. Wymyśliłem takie coś, że wtedy system doda rekord zamówienia automatycznie i połączy je. Jest jeszcze kwestia darmowych usług. Tu z kolei wymyśliłem, że też będą połączone z zamówieniami, ale te zamówienia będą miały po prostu cenę 0. Czyli podsumowując, dostawa zawsze musi mieć odpowiadający rekord zamówienia.

No i jeszcze kwestia płatności. Tutaj myślę o tym, żeby nic nie linkować, tylko przechowywać wszystkie wpłaty. Jeśli ktoś chce wpłacić milion zł, niech wpłaca. Będzie miał po prostu zapas. Saldo klienta wyliczałoby się jako łączna wartość wpłat klienta minus łączna wartość zamówień.

Ostatnią sprawą jest jak rozwiązać odwoływanie dostaw. W domyśle jest tak, że odbywają się dzień po dniu. Mam taki pomysł, że po dodaniu zamówienia dodają się rekordy dostaw. W panelu byłaby opcja odwołania dostawy, które przeszłoby wtedy na pierwszy wolny dzień.

Co sądzicie o tych pomysłach, brzmią sensownie?

[Pyton_000]

Wypowiem się ad płatności.

Jeżeli rozważasz dowolnie duże wpływy (np. wykraczające poza zakup) to radziłbym każde zdjęcie z salda odnotować rekordem z opisem co jak gdzie dlaczego i kto i kiedy (IMG:style_emoticons/default/smile.gif)

Zamówienia powinny zawierać pełne dane tak aby można było to zamówienie odtworzyć nawet jeżeli wywalisz usługę (puste ID ?)

[SmokAnalog]

Jeżeli rozważasz dowolnie duże wpływy (np. wykraczające poza zakup) to radziłbym każde zdjęcie z salda odnotować rekordem z opisem co jak gdzie dlaczego i kto i kiedy (IMG:style_emoticons/default/smile.gif)

Nie rozumiem szczerze mówiąc. Jakie zdjęcie z salda?

Zamówienia powinny zawierać pełne dane tak aby można było to zamówienie odtworzyć nawet jeżeli wywalisz usługę (puste ID ?)

Myślę, że w poważnych projektach to się inaczej rozwiązuje. Baza zawierałaby w ten sposób zbyt dużo śmieci (tzw. redundancja danych). Jest takie coś jak usuwanie miękkie, tzn. rekordy nigdy nie są usuwane z bazy. Można albo nadawać im wartość pola np. deleted_at, albo np. przenosić do innej tabeli i wtedy zmieniać wiązanie z zamówieniem.

System tworzę na frameworku Laravel i tam miękkie usuwanie jest wbudowane, zmieniana jest właśnie wartość kolumny deleted_at. Oczywiście nie jest to idealne rozwiązanie (idealnego nie ma), bo przy własnych zapytaniach łatwo zapomnieć o tym. Ale jest tam dobry ORM, który wystarcza w większości przypadków i on domyślnie ignoruje rekordy z wartością inną niż NULL w deleted_at.