GoldenLine
Zaloguj się
Daniel Częstki

Daniel Częstki senior php developer

Temat: Integralność danych na bazie.

Zastanawiam się jak powinna wyglądać prawidłowo zaprohektowana baza danych aby zachować jej integralność.

Weźmy taki przykładowy problem.
Najłatwiej na przykładzie więc niech to będzie system np. bilingowy.

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

Usluga łaczy sie kluczem z klientem, a faktura z uslugą.
Prawidłowo zaprojektowana baza powinna być jednak niezależna od takich informacji jak np.
- klient zmienia dane adresowe
- klient rezygnuje z uslugi.

Jezeli bedziemy laczyc te tabele kluczami, to okaze sie ze np. w momencie 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.

Jakie są wasze doświadczenia w tym aspekcie projektowania aplikacji ? Chodzi mi o zachowanie integralnosci danych i budowania odpowiednich powiązań pomiedzy tabelami ?
Link do wypowiedziLink

konto usunięte

Temat: Integralność danych na bazie.

Klient może mieć wiele umów, każda może mieć okres obowiązywania... Jeżeli kilka umów to problem - można dodać aneksy, albo załączniki. W takim wypadku umowa będzie grupować takie byty.
W brew pozorom problem jest szerszy - jest firma - SC, sp. z o.o. i firma zmienia się na S.A. - dostaje nowy NIP, nową nazwę, nowy KRS nowe... wszystko. Problem w tym, że pracownicy zostali po staremu, tak samo jak kontakty... W takim przypadku zwykle kończy się na dodaniu kolumny z id poprzedniej firmy. Dane kontaktowe można przenieść do nowej firmy - tylko wyszukiwarka musi sobie z tym inteligentnie poradzić.
Dodam jeszcze, że podobnie radzić sobie można z dublami.
Wszystko zależy od tego jak restrykcyjny system wprowadzimy. Jak bardzo - będzie cisza i spokój. Jak restrykcje ograniczymy do minimum - użytkownikowi będzie się lepiej pracować...
Link do wypowiedziLink
Mirosław Serwaczyński

Mirosław Serwaczyński Analityk programista

Temat: Integralność danych na bazie.

Prosta zasada: wszystkie tabele mają ID wewnętrzny (np. <IdKlienta>, <IdFaktury> itp) typu Autonumer, i jest to jedyne pole wykorzystywane do łączenia pomiędzy tabelami. Oczywiście w przypadku relacji wiele-do-wielu potrzebna jest dodatkowa tabela łącząca, w przypadku jeden-do-wielu (na fakturze jest jeden klient) <IdKlienta> mamy po prostu w tabeli [Faktury].

Same zalety: struktura odporna na dowolne zmiany danych przez użytkownika, klucze główne niedostępne i niewidoczne dla użytkownika, jednoznaczne odzwierciedlenie rzeczywistości, mała długość pól łączących tabele.Mirosław Serwaczyński edytował(a) ten post dnia 13.03.08 o godzinie 21:11
Link do wypowiedziLink
Łukasz Schabek

Łukasz Schabek Architekt Rozwiązań

Temat: Integralność danych na bazie.

Daniel C.:
Usluga łaczy sie kluczem z klientem, a faktura z uslugą.

Moim zdaniem brakuje Ci złotego środka: konto klienta :)

Cały proces end2end w obsłudze klienta przebiega od otwarcia takiego konta do jego zamknięcia.
Klient (i wszelkie o nim dane), usługa (i jej konfiguracja), zamówienia, reklamacje/zgłoszenia powiązane są TYLKO i wyłącznie z kontem, co daje pewną abstrakcję (np. moduł zarządzania klientem, nie musi wiedzieć nic o fakturowaniu).

Miałem okazję pracować z takim modelem zaimplementowanym w systemie klasy CRM i muszę przyznać, że jest bardzo przejrzysty i łatwo się w nim poruszać.
Link do wypowiedziLink
Norbert M.

Norbert M. Nobody's perfect.
Call me Nobody ;)

Temat: Integralność danych na bazie.

Daniel C.:
Jezeli bedziemy laczyc te tabele kluczami, to okaze sie ze np. w momencie 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.

Ja bym to zrobił tak: dodałbym tabelę adresKlienta łącząc ją w relacji jeden-do-wielu z tabelą klient, dodałbym do niej dwa pola DateTime: AktualnyOd (not null) i AktualnyDo. W momencie zmiany adresu przez klienta dodaje się nowy wpis w tabeli (AktualnyOd = dziś, AktualneyDo = null, plus wszystkie inne dane) oraz aktualizuje poprzedni dotyczący tegoż klienta (AktualnyDo = dziś -1).
Oczywiście każda faktura ma datę wystawienia, która była by tu kluczowa do określenia daty adresu.
Teraz jeżeli generujesz fakturę to zaciągasz sobie adres po odpowiednim kluczu obcym i AktualnyDo= null. Przeglądając faktury – no tu już trzeba sprawdzić po dacie.
Oczywiście jest to wolniejsza metoda, ale nie zapycha Ci bazy tymi samymi danymi.
Link do wypowiedziLink

konto usunięte

Temat: Integralność danych na bazie.

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

Nie, ponieważ nie zmienia się klientowi adresu, tylko dodaje nowy. Ma on znacznik typu "Aktualny/Bieżący" ewentualnie coś typu "pusta data ważności". I od momentu dodania wszystkie wygenerowane faktury są z nowym adresem, a starych to nie dotyka. W bazie jest w tym momencie nawet historia "przeprowadzek" :)

No i oczywiście ponowna generacja faktury nie dotyka adresu.

Wszystko jest kwestią dobrego zaprojektowania.Krzysztof P. edytował(a) ten post dnia 14.03.08 o godzinie 09:33
Link do wypowiedziLink
Mirosław Serwaczyński

Mirosław Serwaczyński Analityk programista

Temat: Integralność danych na bazie.

Faktura w świecie realnym to papier, z definicji niezmienny po wytworzeniu. Można więc dopuścić skopiowanie danych teksowych(nazwa, adres) klienta (obowiązujących w dniu wystawienia) do faktury, z zachowaniem jednak powiązania przez <IdKlienta> z tabelą [Klienci] w celach analitycznych.

Można też oczywiście trzymać dodatkową tabelę z adresami i okresem ich obowiązywania, i składać dynamicznie w momencie oglądania fakltury, ale pierwszy model lepiej chyba odwzorowuje rzeczywistość. Oczywiście wszystko zależy od tego, co chcemy z systemu wyciagnąć - jeżeli np. analizy sprzedaży w okresie w podziale na miejscowości, to musi być zawarta w fakturze także zesłownikowana informacja o miejscowości, która - swoją drogą - nie musi przecież pokrywać się z fakturowym adresem klienta.
Link do wypowiedziLink
Bartosz Ślepowronski

Bartosz Ślepowronski Problem? Jaki
problem?

Temat: Integralność danych na bazie.

Nie bardzo rozumiem problem - robi sie tabele 'faktury' (jedna czy pare, obojetne) i w czasie generowania faktur wrzuca do niej dane 'as at'. W ramach referencji do klienta robimy tabele xref klientid fakturaid. I tyle. 'faktury' nie tylko nie musza ale nawet nie powinny byc tabela w 10 postaci normalnej - przynajmniej ja nie widzialem zadnego systemu w ktorym by byly.Bartosz Ślepowroński edytował(a) ten post dnia 14.03.08 o godzinie 12:44
Link do wypowiedziLink

konto usunięte

Temat: Integralność danych na bazie.

1. Trzeba zacząć od "postaci normalnych".
2. Potem przychodzi fascynacja "integralnością po stronie bazy" - triggery, FK, unikalne indeksy...
3. A potem sie o tym wszystkim zapomina bo jest to zbyt duży narzut na maszynę i wraca się do denormalizacji i decentralizacji...

Bez jedynki niestety trudno docenić dwójkę i trójkę. Dlatego trzeba to przejść po kolei.

I jeszcze jedno - bardzo chciałbym wiedzieć czy istnieje chociaż jeden system bilingowy w którym są triggery na kluczowych tabelach (i obsługuje więcej niż 1000 klientów).Piotr Likus edytował(a) ten post dnia 14.03.08 o godzinie 14:08
Link do wypowiedziLink
Bartosz Ślepowronski

Bartosz Ślepowronski Problem? Jaki
problem?

Temat: Integralność danych na bazie.

Piotr Likus:
3. A potem sie o tym wszystkim zapomina bo jest to zbyt duży narzut na maszynę i wraca się do denormalizacji i decentralizacji...

A potem ja siwieje jak mi kaza cos na takiej bazie robic ;)
Link do wypowiedziLink

konto usunięte

Temat: Integralność danych na bazie.

Bartosz Ślepowroński:
Piotr Likus:
3. A potem sie o tym wszystkim zapomina bo jest to zbyt duży narzut na maszynę i wraca się do denormalizacji i decentralizacji...
A potem ja siwieje jak mi kaza cos na takiej bazie robic ;)

Też dotarłem tylko do 2. i w sumie dobrze mi z tym. Bardzo źle - chyba podobnie jak Bartosz - wspominam pracę na wytworach praktyków III poziomu wtajemniczenia ;-)

Nie, żebym nie rozumiał względów praktycznych: jeżeli analiza i doświadczenie wskazują, że np. zbytnie otriggerowanie bazy ją zabije, to trudno. Ale pozbawianie się kluczy obcych (przynajmniej w tych nieco mniejszych rozwiązaniach) to często samobójstwo.

Co ciekawe, najczęściej zdarzało mi się stykać z takimi bazami (bez więzów integralności, zdenormalizowanymi) jako produktami dużych firm informatycznych. I - uprzedzając oczywisty wniosek - nie wynikało to z ogromnego doświadczenia projektantów, tylko z takiej filozofii pracy (szybko, tanio, tesco...), przekazywanej młodym przez starych (tudzież PMów).

A potem trzeba było tłumaczyć klientowi, że "się nie da" (w rozsądnym koszcie), np. dlatego, że pole klasy operacji nie było słownikowane, a modyfikacja tabeli nie wchodziła w grę bo inserty (of koz' zakodowane na twardo) nie miały jawnie wyspecyfikowanych pól (tylko kolejność naturalną) itd.Michał K. edytował(a) ten post dnia 14.03.08 o godzinie 17:18
Link do wypowiedziLink
Bartosz Ślepowronski

Bartosz Ślepowronski Problem? Jaki
problem?

Temat: Integralność danych na bazie.

No to wlasnie mam 'na warsztacie' taki 'profesjonalny' system. Nawet nie bede pisal co tam siedzi, bo szkoda nerwow ;)
Link do wypowiedziLink

konto usunięte

Temat: Integralność danych na bazie.

Bartosz Ślepowroński:
No to wlasnie mam 'na warsztacie' taki 'profesjonalny' system. Nawet nie bede pisal co tam siedzi, bo szkoda nerwow ;)

Po apostrofach (zamiast cudzysłowia) sądząc, pracujesz nad tym bardzo intensywnie.. ;-)
Link do wypowiedziLink

konto usunięte

Temat: Integralność danych na bazie.

Piotr Likus:
1. Trzeba zacząć od "postaci normalnych".
2. Potem przychodzi fascynacja "integralnością po stronie bazy" - triggery, FK, unikalne indeksy...
3. A potem sie o tym wszystkim zapomina bo jest to zbyt duży narzut na maszynę i wraca się do denormalizacji i decentralizacji...
4. Firma ma tyle danych, że bez normalizacji nikt nie jest w stanie zapanować nad chlewem jaki robi się bez normalizacji, więzów integralności, constraintów, not nulli itp.

Punkt 3 - to droga na skróty - a to zawsze wyłazi bokiem - czasem szybciej, czasem później, czasem inaczej się nie da. Tyle, że trzeba sobie z tego zdawać sprawę.

Co do dyskusji - nie da się jednoznacznie powiedzieć co się sprawdzi, a co nie. Być może kultura organizacji wymaga takiego podejścia a nie innego. Dla przykładu - zmiany następują tak szybko, że projektowanie przez 2 miesiące nie ma sensu, bo projekt jest już nieaktualny. Z drugiej strony - problem jest dość typowy, więc coś można powiedzieć, zasugerować...
Link do wypowiedziLink
Marek Kubiś

Marek Kubiś programista c#

Temat: Integralność danych na bazie.

Michał Z.:
Piotr Likus:
1. Trzeba zacząć od "postaci normalnych".
2. Potem przychodzi fascynacja "integralnością po stronie bazy" - triggery, FK, unikalne indeksy...
3. A potem sie o tym wszystkim zapomina bo jest to zbyt duży narzut na maszynę i wraca się do denormalizacji i decentralizacji...
4. Firma ma tyle danych, że bez normalizacji nikt nie jest w stanie zapanować nad chlewem jaki robi się bez normalizacji, więzów integralności, constraintów, not nulli itp.
5. Jump to 3
Tyle, że trzeba sobie z tego zdawać sprawę.
Z jednej strony problem z elementarza (czyli właściwie nie wiadomo o co chodzi), z drugiej samo życie i przypadek nieodosobniony.

Myślę, że rozwiązania problemu nie należy szukać w technologii a w modelu. Struktura bazy danych winna zależeć od dziedziny zastosowań i zdefiniowanych wymagań. Wszystko zależy od ilości danych i użytkowników, częstotliwości dostępu do danych archiwalnych, posiadanych zasobów sprzętowych, mocy przetwarzania.

Najpierw rzeczywiste założenia biznesowe i wymagania prawne.

Raz zetknąłem się z przypadkiem, że kontrolujący firmę biegły rewident, widząc fakturę sprzed lat z błędem ortograficznym czy literowym w nazwie kontrahenta zażyczył sobie jej powtórnego wydrukowania. Wydrukowana na bieżąco faktura błędu oczywiście nie posiadała no i był problem.
Z drugiej strony - problem jest dość typowy, więc coś można powiedzieć, zasugerować...
Przykład faktury dotyczy dokumentu, który ma kilka elementów proszących się o normalizację, przy jednoczesnej ich redundancji i ściśle określonych wymaganiach prawnych.

Biorąc liczne za i przeciw, osobiście jestem zwolennikiem utworzenia rozsądnego repozytorium danych archiwalnych przechowywanych w postaci nadmiarowej. Podpowiedzi co do struktury z wieloma kluczami wykorzystałbym w zakresie pracy z danymi aktualnymi. Siła chyba w rozsądnym połączeniu obydwu podejść.
Link do wypowiedziLink

konto usunięte

Temat: Integralność danych na bazie.

Marek Kubiś:
Michał Z.:
Piotr Likus:
1. Trzeba zacząć od "postaci normalnych".
2. Potem przychodzi fascynacja "integralnością po stronie bazy" - triggery, FK, unikalne indeksy...
3. A potem sie o tym wszystkim zapomina bo jest to zbyt duży narzut na maszynę i wraca się do denormalizacji i decentralizacji...
4. Firma ma tyle danych, że bez normalizacji nikt nie jest w stanie zapanować nad chlewem jaki robi się bez normalizacji, więzów integralności, constraintów, not nulli itp.
5. Jump to 3
Takie skakanie można sobie powtarzać. Rzecz w tym, żeby optymalnie wykorzystać RAM i moc procesora. Po to wymyślono normalizację. Denormalizacja ma sens jeżeli dostęp do pewnych danych wymaga zbyt dużego nakładu pracy procesora - czyli użytkownik czeka za długo.
Myślę, że rozwiązania problemu nie należy szukać w technologii a w modelu. Struktura bazy danych winna zależeć od dziedziny zastosowań i zdefiniowanych wymagań. Wszystko zależy od ilości danych i użytkowników, częstotliwości dostępu do danych archiwalnych, posiadanych zasobów sprzętowych, mocy przetwarzania.

Najpierw rzeczywiste założenia biznesowe i wymagania prawne.
No - czyli zaczynamy od analizy a kończymy na modelu i sprzęcie. ;)
Postawienie problemu - IMVHO - odnosiło się do sytuacji "tuż przed
modelem".
Raz zetknąłem się z przypadkiem, że kontrolujący firmę biegły rewident, widząc fakturę sprzed lat z błędem ortograficznym czy literowym w nazwie kontrahenta zażyczył sobie jej powtórnego wydrukowania. Wydrukowana na bieżąco faktura błędu oczywiście nie posiadała no i był problem.
>
Ja miałem wymóg, żeby korekta dotyczyła wielu rachunków.
Biorąc liczne za i przeciw, osobiście jestem zwolennikiem utworzenia rozsądnego repozytorium danych archiwalnych przechowywanych w postaci nadmiarowej. Podpowiedzi co do struktury z wieloma kluczami wykorzystałbym w zakresie pracy z danymi aktualnymi. Siła chyba w rozsądnym połączeniu obydwu podejść.
>
Są rzeczy, które tylko na pierwszy rzut oka wydają się nadmiarowe.
Nazwa kontrahenta, adres, nip... Jak się nie zapisze tych danych -
wystawienie duplikatu może być problemem. No, ale to chyba dość
oczywiste.
Link do wypowiedziLink
Bartosz Ślepowronski

Bartosz Ślepowronski Problem? Jaki
problem?

Temat: Integralność danych na bazie.

Michał K.:
Bartosz Ślepowroński:
No to wlasnie mam 'na warsztacie' taki 'profesjonalny' system. Nawet nie bede pisal co tam siedzi, bo szkoda nerwow ;)

Po apostrofach (zamiast cudzysłowia) sądząc, pracujesz nad tym bardzo intensywnie.. ;-)

Apostrofy wynikaja z uzywanej strony kodowej - troche niewygodnie korzystac z cudzyslowia znajdujacego sie pod 2jka :)
Link do wypowiedziLink

konto usunięte

Temat: Integralność danych na bazie.

A nie dało się założyć nowego wątku, tylko każdy możliwy zaspamować ogłoszeniem? Mam szczerą nadzieję, że ktoś to wytnie...
Link do wypowiedziLink
Łukasz Schabek

Łukasz Schabek Architekt Rozwiązań

Temat: Integralność danych na bazie.

Piotr S.:
A nie dało się założyć nowego wątku, tylko każdy możliwy zaspamować ogłoszeniem? Mam szczerą nadzieję, że ktoś to wytnie...

Wycięte ;) Jak ja nie lubię natarczywego marketingu... ;)
Link do wypowiedziLink

konto usunięte

Temat: Integralność danych na bazie.

Skutki przyniosło mu to odwrotne do zamierzonych ;) No nic milczę już, bo też offtopuję ;)
Link do wypowiedziLink
« Wróć do tematów
Odpowiedz

Podobne tematy





Wyślij zaproszenie do
Anuluj