ďťż
 
Dokumenty - jak =?ISO-8859-2?Q?zaprojektowa=E6_baz=EA=3F?= ďťż
 
Dokumenty - jak =?ISO-8859-2?Q?zaprojektowa=E6_baz=EA=3F?=
Zobacz wiadomości
 
Cytat
A gdyby tak się wedrzeć na umysłów górę, / Gdyby stanąć na ludzkich myśli piramidzie, / I przebić czołem przesądów chmurę, / I być najwyższą myślą wcieloną. . . Juliusz Słowacki, Kordian
Indeks BCB i MySQL subiekt gt fototapeta
 
  Witamy

Dokumenty - jak =?ISO-8859-2?Q?zaprojektowa=E6_baz=EA=3F?=



Szarak - 12-01-2007 00:29
Dokumenty - jak =?ISO-8859-2?Q?zaprojektowa=E6_baz=EA=3F?=
  Witam

Mam następującą sytuację:
Aplikacja ma operować na dokumentach. Tylko tych dokumentów będzie ze
40-50 rodzajów. Dokumenty mają kilka (ok. 10) pól wspólnych (numer,
autor, tytuł, status, itp.), ale mają też pola specyficzne dla danego
typu. Pola mogą być różnych typów (tekst, liczba, czas, id dokumentu -
do powiązań między dokumentami). Dokumenty, oprócz tego, że będą
wyświetlane w formularzach, muszą być wyświetlane w tabelach. Co więcej,
w jednej tabeli będą wyświetlane jednocześnie dokumenty prawie
wszystkich typów, łącznie z polami specyficznymi.

No i mam dylemat jak zaprojektować bazę do takich celów. Wstępnie będzie
postgres, ale musi być możliwość przejścia w przyszłości na MSSQL,
Oracle itd. Aplikacja będzie napisana w javie i dostęp do bazy przez
JPA. Przewiduję, że po pewnym czasie baza ma udźwignąć kilkadziesiąt
tysięcy dokumentów, a każdy dokument, średnio 20 pól specyficznych.
Zakładam, że użytkownicy nie będą pobierać do wyświetlenia więcej niż
200 dokumentów na raz.

Nie jestem biegły w projektowaniu baz danych. Szczególnie obce są mi
kwestie wydajnościowe. Dlatego właśnie zwracam się do Was o pomoc w
zaprojektowaniu tego. Z powodu konieczności wyświetlania dokumentów w
jednym widoku, raczej odpada stosowanie tabeli dla każdego typu
dokumentu. Pomyślałem, że najlepiej będzie to zrobić tak, że jedna
tabela będzie trzymać wspólne pola wszystkich dokumentów, a pola
specyficzne będą trzymane w jednej bądź w kilku dodatkowych tabelach.
Dla specyficznych widzę dwa rozwiązania:
1. W jednej tabeli kilka pól na wartość, które będą wypełniane zależnie
od typu, czyli np. jeśli pole tekstowe, to wypełniamy pole valueString,
jeśli liczba całkowita, to valueInteger, itd. Mamy wtedy tylko jedną
tabelę na pola specyficzne, ale jest ona duża, bo zajmują miejsce puste
pola;
2. Dla każdego typu pola tworzymy jedną tabelę z polami: docId, name,
value. Wtedy, w zapytaniu pobierającym dokumenty do widoku dla usera,
trzeba zbierać pola z kilku tabel.

Co myślicie o tym? Jak byście coś takiego zaimplementowali? Gdzie mogą
się pojawić problemy wydajnościowe i jak im zaradzić korzystając być
może ze specyficznych mechanizmów poszczególnych baz?

Pozdrawiam
Szarak





=?ISO-8859-2?Q?Micha=B3_Zaborowski?= - 12-01-2007 00:29

  [...]
3: Można zrobić jedną tabelę - do pól wspólnych dodać BLOBa z XMLem...
Tak np. jedna firma z Wrocławia trzyma dane do formularzy celnych.

Ogólnie to polecam 2, dużo zależy od specyfiki projektu. Przy małych
projektach, za to słabo doprecyzowanych... lepiej wybrać 1, albo 3,
bo utrzymanie będzie tańsze, a struktura elastyczna. Jak projekt jest
duży, albo ma w planach urosnąć to może się okazać, że bez solidnej
i godnej zaufania struktury... całość się posypie i to w bardzo brzydki
sposób.

--
Pozdrawiam,
Michał Zaborowski (TeXXaS)




Herakles - 12-01-2007 00:29

  1) Tabela typ_dokumentu tylko nazwa i id.
2) Tabela pola_dokumentu definiujesz chekbox text radia i telewizory
najlepiej z rozmiarami.
3) tabela pola dokumentu z id dokumentu i id pola
Dochodzi jeszcze możliwość zwielokrotnienia pól czyli dodatkowe pole bool.

I już możesz walczyć możesz w tabeli z polami dokumentów zdefiniować jakoś
jeszcze layouty aby pola układały się tak jak trzeba na ekranie.

tabelka dokumenty i linijki:
1) id, numer dukumentu typ oraz co ważne jakieś pole do wyszukiwania, bo jak
zaczniesz wyszukiwanie po linijkach na dużej bazie to he he będzie problem,
warto zdefiniowac sobie jakiś ciekawy typ danych do tego wyszukiwania.
2) linijki dokumenntu, id dokumentu typ pola i zawartosc

Do tego warto jakiś graf zdefiniować powiązań dokumentów między sobą kolejne
dwie tabelki.

HA dobre nie?




Szarak - 13-01-2007 00:01

  Dnia 11.01.2007 16:39 Michał Zaborowski napisał(a):
> 3: Można zrobić jedną tabelę - do pól wspólnych dodać BLOBa z XMLem...
> Tak np. jedna firma z Wrocławia trzyma dane do formularzy celnych.

Gdyby pola specyficzne były tylko informacyjne, to tak. Ale każdy
dokument pełni jakąś funkcję w systemie i pola specyficzne
wykorzystywane są do różnych celów. Potrzebne są obliczenia na tych
polach, więc taki XML w BLOB-ie raczej odpada, bo ma to być względnie
uniwersalne, a nie wszystkie popularne bazy wspierają XML-a. Jak już
wspominałem priorytet to Postgres.

> Ogólnie to polecam 2, dużo zależy od specyfiki projektu.

Ku temu rozwiązaniu właśnie się skłaniam. Muszę to z grubsza
zaimplementować i zrobić jakieś testy.

> Jak projekt jest
> duży, albo ma w planach urosnąć to może się okazać, że bez solidnej
> i godnej zaufania struktury... całość się posypie i to w bardzo brzydki
> sposób.

Zdaję sobie z tego sprawę i dlatego pytam na tej grupie :) Aplikacja
będzie rozbudowywana przez następne lata i musimy mieć swobodę w
definiowaniu nowych typów dokumentów itp. Powinna też wytrzymać większe
ilości dokumentów.

Pozdrawiam
Szarak
  • zanotowane.pl
  • doc.pisz.pl
  • pdf.pisz.pl
  • effulla.pev.pl
  • comp
    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 =?UTF-8?Q?=5Bmysql=5D_jak_pobra=C4=87_warto=C5=9B=C4=87_ AUTO=5F?==?UTF-8?Q?INCREMENT=3F?= 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?= =?iso-8859-2?q?Informatyka,_Java,_EJB,_Ajax,_Spring=2E_Czy=BF by_to_koniec_=B6wiata,_czy_te=BF_nasze_uczelnie_b= EAd=B1_uczy=B3y_w_ko=F1cu!_czego_praktycznego_=2E= 2E=2E=2E?= [MS SQL 2005] =?windows-1250?Q?Ilo=9C=E6_wiersz=F3w_w_zbiorze_wynikowym?= Manager =?ISO-8859-2?Q?font=F3w=2E=2E=2E?=
  • zanotowane.pl
  • doc.pisz.pl
  • pdf.pisz.pl
  • own-team.pev.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

    Valid HTML 4.01 Transitional

    Free website template provided by freeweblooks.com