GoldenLine
Zaloguj się
Daniel Częstki

Daniel Częstki senior php developer

Temat: Integralność danych na bazie w projektach www.

Weźmy taki przykładowy problem - niech to będzie system np. bilingowy.

Mamy klienta, który kupuje jakieś usługi, na które system wystawia faktury.

Usluga łaczy sie "po ID" z klientem, a faktura z uslugą.
Prawidłowo zaprojektowana baza powinna być jednak uniezależniona od takich informacji jak np.
- klient zmienia dane adresowe
- klient rezygnuje z uslugi (usunięcie danych z bazy)

Jezeli bedziemy laczyc te tabele "po ID", to okaze sie ze np. zmiany danych adresowych klienta pociagnie za sobą zmianę wszystkich danych na fakturach - rowniez tych wystawionych w przeszlosci.

Aby temu zapobiec, do tabeli zawierajacej faktury, w momencie jej tworzenia kopiujemy bieżące dane klienta. W tym momencie zmiana danych klienta nie pociągnie za sobą zmiany danych w starych fakturach.

Jestem ciekawy jakie są wasze doświadczenia w tym aspekcie projektowania aplikacji ? Chodzi mi o zachowanie integralnosci danych i budowania odpowiednich powiązań pomiedzy tabelami ?
Z jakimi problemami się spotkaliście i jakie były rozwiazania ?
Jaką polecacie literaturę zwiazaną z poruszonym przeze mnie zagadnieniem ?
Link do wypowiedziLink

konto usunięte

Temat: Integralność danych na bazie w projektach www.

Dane blingowe, faktury .. itp w systemach zawsze zostawia się nie jako połączenia po ID, a wypełniając pola aktualnymi w danym momencie danymi.
Link do wypowiedziLink

konto usunięte

Temat: Integralność danych na bazie w projektach www.

Marcin Deręgowski:
Dane blingowe, faktury .. itp w systemach zawsze zostawia się nie jako połączenia po ID, a wypełniając pola aktualnymi w danym momencie danymi.

Potwierdzam.
Mimo tego, że znam takie oprogramowania, które tego nie robią... to jednak należy zawsze zostawić takie dane jakie były na dokumencie w trakcie jego wystawienia. Zmiana na przykład danych adresowych w bazie kontrahentów nie może mieć wpływu na dane zarejestrowane podczas wystawienia dokumentu.

Oczywiście dla innych potrzeb (choćby płatności) należy takie ID zostawić.. ale to już inna bajka.
Link do wypowiedziLink
Marcin Lejman

Marcin Lejman Właściciel, iTrans

Temat: Integralność danych na bazie w projektach www.

Witam,

można sobie wyobrazić inny scenariusz, z trzema tabelami:

w pierwszej tabeli mamy:

a) ID klienta
b) ID aktualnej wersji danych identyfikacyjnych / adresowych

w drugiej tabeli mamy:

a) ID danych identyfikacyjnych
b) ID klienta
c) wszystkie dane identyfikacyjne

w trzeciej tabeli mamy:

a) id klienta
b) id aktualnych danych identyfikacyjnych (pobrane z pierwszej tabeli w chwili tworzenia rekordu)
c) dane faktury (kwota itd.)

Jeżeli klient zmieni dane, wówczas w drugiej tabeli dodajemy nowy rekord z nowymi danymi, a w pierwszej tabeli zmieniamy wskaźnik na nowe ID aktualnych danych.

Zalety:

a) nie musimy kopiować wszystkich danych do każdej faktury
b) mamy historię wszystkich ewentualnych zmian danych
c) dane w już wystawionych dokumentach nie ulegają zmianie
Link do wypowiedziLink
Michał W.

Michał W. właściciel, WEES.PL

Temat: Integralność danych na bazie w projektach www.

dokładnie wpisujemy zawsze aktualny id klienta, a za identyfikator klienta możemy przyjąć pesel

dla usuwanych danych robimy inaczej oznaczamy je jako delete poprzez dodanie odpowiedniej kolumny i dalej poprzez widoki lub zapytania sql widzimy tylko tych dostępnychMichał Wesołowski edytował(a) ten post dnia 21.03.08 o godzinie 17:20
Link do wypowiedziLink

konto usunięte

Temat: Integralność danych na bazie w projektach www.

Michał Wesołowski:
dokładnie wpisujemy zawsze aktualny id klienta, a za identyfikator klienta możemy przyjąć pesel

PESEL jest dobry dla samobójców ;-)

Kiedyś pracowałem dla Policji, to mi ich informatycy mówili, że był taki okres (gdzieś koło lat '80), że 13% PESELi było co najmniej zduplikowanych (i one nie zniknęły).
Link do wypowiedziLink
Michał W.

Michał W. właściciel, WEES.PL

Temat: Integralność danych na bazie w projektach www.

Michał K.:
Michał Wesołowski:
dokładnie wpisujemy zawsze aktualny id klienta, a za identyfikator klienta możemy przyjąć pesel

PESEL jest dobry dla samobójców ;-)

Kiedyś pracowałem dla Policji, to mi ich informatycy mówili, że był taki okres (gdzieś koło lat '80), że 13% PESELi było co najmniej zduplikowanych (i one nie zniknęły).

fakt, ale w praktyce często stosuje się takie rozwiązanie, może pesel2 coś rozwiąże
Link do wypowiedziLink
Agnieszka Stojanik

Agnieszka Stojanik "Love like there's
no tomorrow, dance
like no one can
see...

Temat: Integralność danych na bazie w projektach www.

Marcin Lejman:
>
Zalety:

a) nie musimy kopiować wszystkich danych do każdej faktury
b) mamy historię wszystkich ewentualnych zmian danych
c) dane w już wystawionych dokumentach nie ulegają zmianie

Jak najbardziej zgadzam sie z wszystkimi wymienionymi tutaj zaletami, trzeba jednak wziąć pod uwagę narzut jaki niesie ze sobą łączenie tabel przy ich przeszukiwaniu. Oczywiście każde zapytanie można zoptymalizować, jednak czasem denormalizacja okazuje sie po prostu bardziej opłacalna.
Link do wypowiedziLink
Adam Brodziak

Adam Brodziak PHP, football, fun

Temat: Integralność danych na bazie w projektach www.

Denormalizacja jest tu dobrym wyjściem. Dane do faktury powinny być wpisane do tabeli z fakturą. Ww. system wydaje się dobry, ale co jeśli np. firma ma wiele działów na które trzeba wystawić faktury?
Link do wypowiedziLink
« Wróć do tematów
Odpowiedz

Podobne tematy





Wyślij zaproszenie do
Anuluj