jak =?ISO-8859-2?Q?zamodelowa=E6_tak=B1_sytuacj=EA=2E=2E=2E?=
josh - 09-05-2006 23:55
jak =?ISO-8859-2?Q?zamodelowa=E6_tak=B1_sytuacj=EA=2E=2E=2E?=
Hej,
tak się zastanawiałem... są trzy różne tabele klientów (osoby
indywidualne, firmy oraz klienci w akwizycji) oraz takie tabele jak np.
umowy czy korespondencja...
Jak powinien wyglądać model takiej bazy? W tabeli umowy muszą być dwa
pola - rodzaj klienta oraz id klienta, gdzie rodzaj określałby tabele
(np. 1,2 lub 3), ale jak wtedy opisać to kluczami głównymi i obcymi?
Przecież nie może być sytuacji, gdzie para kolumn jest jednocześnie
kluczem obcym dla 3 różnych tabel...
Z drugiej strony można by zrobić jedną tabele klientów, która
zawierałaby wszystkie pola wspólne dla każdej grupy (np. adres) i
następnie tabele specyficzne dla konkretnego rodzaju klienta, ale to też
takie sobie mało eleganckie rozwiązanie - bo tak istotna informacja jak
"nazwa" już jest kłopotliwa (przypadku firm nazwa jest do opisania w
jednym polu, a dla osób fizycznych już mamy kombinację: imie+nazwisko...)
Tak prawdę mówiąc to nie pytam się co powinienem zrobić, bo już nic nie
poradzę - system o którym mówię już istnieje od dawna i nie jest możliwe
jego przerobienie... chciałem poznać tylko Wasze opinie, czy ta druga
opcja jest jedynym sensownym modelem, czy może ta istniejąca wersja z
trzema tabelami dla różnych rodzajów klientów też ma swoje uzasadnienie
i jest jakiś formalny sposób, żeby opisać to w sposób zrozumiały dla
bazy danych.
Rafal sxat - 09-05-2006 23:55
=?iso-8859-2?Q?Re:_jak_zamodelowa=E6_tak=B1_sytuacj=EA...?=
> Hej,
> tak się zastanawiałem... są trzy różne tabele klientów (osoby
> indywidualne, firmy oraz klienci w akwizycji) oraz takie tabele jak np.
> umowy czy korespondencja...
nie oczekuj ze ktos to zrobi za Ciebie :] grupa moze pomoc nie zrobic
--
Archiwum grupy: http://niusy.onet.pl/pl.comp.bazy-danych
josh - 11-05-2006 12:59
Rafal sxat napisał(a):
> nie oczekuj ze ktos to zrobi za Ciebie :] grupa moze pomoc nie zrobic
>
Nigdzie nie pisałem, że chcę, żeby ktoś dla mnie cokolwiek zrobił,
dlatego nie rozumiem twojej odpowiedzi.
Może zacytuję fragment:
> [...] system o którym mówię już istnieje od dawna i nie jest możliwe jego
> przerobienie... chciałem poznać tylko Wasze opinie [...]
Tygrys - 11-05-2006 12:59
=?iso-8859-2?Q?Re:_jak_zamodelowa=E6_tak=B1_sytuacj=EA...?=
Użytkownik "josh" <pljosh_malpa_poczta.neostrada.pl@nospam.org> napisał w
wiadomości news:e3hpr7$fgi$1@atlantis.news.tpi.pl...
> Hej,
> tak się zastanawiałem... są trzy różne tabele klientów (osoby
> indywidualne, firmy oraz klienci w akwizycji) oraz takie tabele jak np.
> umowy czy korespondencja...
>
> Jak powinien wyglądać model takiej bazy? W tabeli umowy muszą być dwa
> pola - rodzaj klienta oraz id klienta, gdzie rodzaj określałby tabele (np.
> 1,2 lub 3), ale jak wtedy opisać to kluczami głównymi i obcymi? Przecież
> nie może być sytuacji, gdzie para kolumn jest jednocześnie kluczem obcym
> dla 3 różnych tabel...
>
> Z drugiej strony można by zrobić jedną tabele klientów, która zawierałaby
> wszystkie pola wspólne dla każdej grupy (np. adres) i następnie tabele
> specyficzne dla konkretnego rodzaju klienta, ale to też takie sobie mało
> eleganckie rozwiązanie - bo tak istotna informacja jak "nazwa" już jest
> kłopotliwa (przypadku firm nazwa jest do opisania w jednym polu, a dla
> osób fizycznych już mamy kombinację: imie+nazwisko...)
Dla osoby fizycznej nazwa to imię + nazwisko. Jest jakiś powód do
wyróżnienia imienia i nazwiska osobno?
Zobacz ile pól jest wspólnych, a ile rozłącznych. Jeżeli część wspólna jest
duża, a wszystkie te bazy są używane w jednym kontekscie (np. klienta) to
jest sens wstawić to do jednej bazy. Jeżeli występuje pole informacyjne (nie
kluczowe) np. Regon dla firmy i Pesel dla osoby prywatnej to możesz to
wsadzić do jednego pola Regon/Pesel. Co do części rozłącznej, to albo jest
mała i można ją wpisać do tej tabeli dająć NULL-e w zależności od rodzaju
klienta, albo zrobić dodatkową tabelę o polach IdKlienta, Cecha, Wartość,
gdzie utkasz dodatkowe dane. To jednak bardzo zależy od konkretnych kolumn w
tych tabelach i tego, czy możesz zdefiniować coś jak "klient", czy raczej
lepiej mieć "osoba", "firma" i coś tam jeszcze. W moim przypadku siedzi
wszystko w jednej tabeli, ale właściwie dane mi się pokrywają dla osób i
firm.
Tygrys
=?ISO-8859-2?Q?S=B3awomir_Szysz=B3o?= - 11-05-2006 13:00
=?ISO-8859-2?Q?Re:_jak_zamodelowa=E6_tak=B1_sytuacj=EA...?=
Dnia Sat, 6 May 2006 19:10:05 +0200, "Tygrys" <mediacom@wywalto.polbox.com>
wklepał(-a):
>Dla osoby fizycznej nazwa to imię + nazwisko. Jest jakiś powód do
>wyróżnienia imienia i nazwiska osobno?
Wpisz imię i nazwisko w jedno pole, a potem posortuj dane wg nazwiska.
Powodzenia. Aha, nie zapomnij o osobach z 2 nazwiskami albo z 2 imionami.
>Zobacz ile pól jest wspólnych, a ile rozłącznych. Jeżeli część wspólna jest
>duża, a wszystkie te bazy są używane w jednym kontekscie (np. klienta) to
>jest sens wstawić to do jednej bazy. Jeżeli występuje pole informacyjne (nie
>kluczowe) np. Regon dla firmy i Pesel dla osoby prywatnej to możesz to
>wsadzić do jednego pola Regon/Pesel. Co do części rozłącznej, to albo jest
>mała i można ją wpisać do tej tabeli dająć NULL-e w zależności od rodzaju
>klienta, albo zrobić dodatkową tabelę o polach IdKlienta, Cecha, Wartość,
>gdzie utkasz dodatkowe dane. To jednak bardzo zależy od konkretnych kolumn w
>tych tabelach i tego, czy możesz zdefiniować coś jak "klient", czy raczej
>lepiej mieć "osoba", "firma" i coś tam jeszcze. W moim przypadku siedzi
>wszystko w jednej tabeli, ale właściwie dane mi się pokrywają dla osób i
>firm.
PESEL i REGON to nie to samo, więc powinny być w osobnych polach.
Moim zdaniem nie ma sensu rozbijać danych osobowych na osobne tabele. Tak
naprawdę osoba fizyczna i firma ma tyle danych wspólnych (nazwa, adres,
telefony), że pola które są inne dla każdego z typów mogą być opcjonalne;
natomiast aplikacja może wymuszać wpisanie np. REGON gdy wybrano typ
klienta=firma.
--
Sławomir Szyszło mailto:slaszysz@poczta.onet.pl
Primus inter FAQires & Grand Inquisitor no.0 of pl.comp.bazy-danych
FAQ pl.comp.bazy-danych http://www.dbf.pl/faq/
Archiwum http://groups.google.com/groups?grou...mp.bazy-danych
Tygrys - 11-05-2006 13:00
=?iso-8859-2?Q?Re:_jak_zamodelowa=E6_tak=B1_sytuacj=EA...?=
Użytkownik "Sławomir Szyszło" <slaszysz@poczta.onet.pl> napisał w wiadomości
news:e3iugs.2b0.1@slaszysz.poczta.onet.pl...
> Dnia Sat, 6 May 2006 19:10:05 +0200, "Tygrys"
> <mediacom@wywalto.polbox.com>
> wklepał(-a):
>
>>Dla osoby fizycznej nazwa to imię + nazwisko. Jest jakiś powód do
>>wyróżnienia imienia i nazwiska osobno?
>
> Wpisz imię i nazwisko w jedno pole, a potem posortuj dane wg nazwiska.
> Powodzenia. Aha, nie zapomnij o osobach z 2 nazwiskami albo z 2 imionami.
W określeniu klienta używam pola Logo którego używam do sortowania i pola
Nazwa które drukuję na fakturze.
Tak że nie mam problemu opisanego powyżej. Natomiast przy innym rozwiązaniu
to rzeczywiście może przeszkadzać
>
> PESEL i REGON to nie to samo, więc powinny być w osobnych polach.
To nie to samo, ale spełnia podobną rolę (dodatkowa identyfikacja podmiotu).
Jeżeli komuś BARDZO zależy na miejscu i planuje to pole tylko do wydruku na
jakimś dokumencie, bez wyszukiwań itp. to może wsadzić je jednego pola i
zmieniać opis pola w aplikacji w zależności od typu klienta.
Nie podaję tego jako zalecenia, tylko potencjalnej możliwości wpakowania
"kompatybilnych" danych do jednego pola (takie union)
Tygrys.
zanotowane.pldoc.pisz.plpdf.pisz.pleffulla.pev.pl
|
Wydajność baz danych w zależności od poziomu izolacji ANSI/ISO
Czy zna (obsługuje) ktoś program Iso Draw ?
MYSQL - kodowanie w ISO-PL
strona plus baza w iso do utf-8
Kodowanie: z iso na utf
Konwesja znaków w dump'ie bazy danych - ISO -> utf-8 -> ISO -> utf-8
=?iso-8859-2?q?Co_oznacza_b=B3=B1d_Warning:_mysql=5Fconnect() _[function.mysql-connect]:_Can't_connect_to_local_MySQL_server_through_sock et_'/var/run/mysqld/mysqld.sock'_(2)_in?=
[MS SQL 2005] =?windows-1250?Q?Ilo=9C=E6_wiersz=F3w_w_zbiorze_wynikowym?=
=?iso-8859-2?q?Mo=BFe_kto=B6_ch=EAtny_na_konkursik_na_stron=E A_www=3F_to_nic,_=BFe_nie_ma_nagr=F3d....?=
ubuntu + postgresql - =?ISO-8859-2?Q?u=BFytkownik_postgres?=
zanotowane.pldoc.pisz.plpdf.pisz.plshutter.opx.pl
Cytat
Decede mihi sole - nie zasłaniaj mi słonca.
Gdy kogoś kochasz, jesteś jak stworzyciel świata - na cokolwiek spojrzysz, nabiera to kształtu, wypełnia się barwą, światłem. Powietrze przytula się do ciebie, choćby był mróz, a ty masz w sobie tyle radości, że musisz ją rozdawać wokoło, bo się w tobie nie mieści
Hoc fac - tak czyń.
A tergo - od tyłu; z tyłu.
I czarne włosy posiwieją. Safona |
|
