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?

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

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

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


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.

Skoro użytkownik wpłaca to się taka operacja gdzieś zapisuje. Jak kupuje to jest zamówienie. Jak zamówienie zostanie opłacone to fakt dokonania płatności odnotowujesz w tabeli
Przykład:


Co do softdelete to jest to dobre np. w przypadku właśnie zamówień. użytkowników.

Co do śmieci. Przykład:
Masz zamówienie. Przypisujesz sobie do niego ID użytkownika. Generujesz FV. Po jakimś czasie user zmienia sobie dane bo ma takie widzi mi się. Prosi o wygenerowanie duplikatu. Generujesz i... zonk. FV nie odpowiada duplikatowi bo zmieniły się dane.

Kolejny przykład Produkty w zamówieniu.
Zmieniasz nazwę dla produktu i już masz coś innego w zamówieniach.

Zapisywanie historii zmian produktu, usera czy innych danych... Tutaj pojawia się mnóstwo śmieci, bo każde zapisanie generuje kolejną zmianę. Nie ma biedy jak trzymasz w historii 2-3 kolumny, a jeżeli cały wiersz?

Ciekawy pomysł z tym zapisywaniem salda razem z pozycjami ujemnymi. Tylko po co, skoro to już jest w tabeli z zamówieniami? Suma cen w niej służy za sumę zobowiązań klienta. Czy jest sens duplikowanie tego w innej tabeli? Jestem na nie, chyba że masz jakiś argument

Tutaj nie będą generowane faktury (charakter produktu jest taki, że nie rozliczysz się z niego), ale zdaję sobie sprawę, że wszelkie dane powinny być w takich sytuacjach archiwizowane. Tylko że robi się to raczej w osobnej tabeli ze zmianami i dopasowuje dane na dany dzień po timestampach. Wyobrażasz sobie np. bazę danych z milionem klientów, gdzie każdy zakup jest opatrzony nazwiskiem, adresem i wszystkimi innymi danymi? Ich baza musiałaby chyba pękać w szwach

Właśnie zerknąłem na strukturę Magento, tam są zapisane w zamówieniu wszystkie dane. Tak są duplikowane ale to dla tego że są niezbędne do odtworzenia pełnych danych o za mówieniu kiedykolwiek z momentu jego złożenia.

Może dlatego Magento działa jakby chciał, a nie mógł