Czy to są dobre praktyki? Opcje

[atomic1234]

Cześć. Jak lepiej zaprojektować bazę danych w takim przypadku:

Użytkownik ma adresy dostawy, które wybiera do złożonych zamówień.

Załóżmy że ma adres dostawy adr_dost1
Składa zlecenie zlec1 i wybiera dla niego adr_dost1
Za miesiąc, aktualizuje dane adr_dost1.

Ja oczywiście chciałbym zachować dane przed edycją adr_dost1 dla zlec1 w historii.

Jak to zrobić?
Do tej pory robiłem tak, że jeżeli edycja występowała na adr_dost1, który już był wykorzystany w zleceniu, to ten adres dostał atrybut hidden=1, a zmieniony adres został wstawiony do tabeli z nowym id. Dla użytkownika operacja nie widoczna, bo wyswietlam tylko rekordy z atrybutem hidden=0 (domyślna wartość to 0).

Czy może lepiej nie łączyć zlecenia z adresami kluczem, tylko kopiować treść adresu do pola typu text?

Jak wy robicie?

Ten post edytował atomic1234 2.08.2011, 11:37:43

[luckyps]

Moim zdaniem lepiej jest utworzyc tabele historii i tam gromadzic archiwalne dane.

Odniesc sie bedziesz do niej mogl kiedy bedziesz tego potrzebowal.
Glowna tabela nie jest "zasmiecana" starymi danymi a co za tym idzie, nie ma niepotrzebnego przyrostu danych.

[grrizli]

ja robię tak, że każdy adres ma pole `wersja`. Gdy uzytkownik dodaje pierwszy adres to on ma wersje 1 (lub 0, jak sobie ustalisz), gdy go zmieni, to nie zmieniam juz adresu z wersja 1 tylko dodaje nowy adres z wersja poprzednia_wersja+1 dla tego klienta. Kazde zamowienie ma pole `wersja_adresu`. W tym wypadku klient moze zmieniac adres 30 razy a do kazdego zamowienia miec inny. To rozwiazanie wymaga osobnej tabeli z adresami, ale to chyba standard.

[atomic1234]

Ciekawe pomysły. Nie bardzo umiem sobie wyobrazić implementację tej tabeli historii i jej powiązanie z zamówieniami.

W pomyśle z wersjami, jak przebiega usuwanie adresu przez usera?

Bo u mnie to SET hidden=1;

Ten post edytował atomic1234 2.08.2011, 11:55:12

[grrizli]

U mnie nie kasuje sie adresu tylko dodaje nowy z wyzszym numerem wersji. Potem aktualny adres == ten z najwyzsza wersja.