🚀 go-pugleaf

W dniu 2015-02-09 o 15:49, Marek pisze:
> W dniu 2015-02-09 o 09:40, nkab@toya.net.pl pisze:
>
>> Przy księgowości bez indeksów ciężko byłoby zliczać dane powiązane
>> z innymi tabelami, no ale to są sztywne rozwiązania, a kolega Marek
>> chce dowolności w wyborze pól.
>
> Czytam, czytam Waszą rozmowę :-)
Mam nadzieję, że nie wszystko - bo czasem ktoś palnie jakąś głupotę. jak 
np. z dodawanie indeksów, które tworzą pliki...
WTF - jakie kurna pliki?
W DBF to faktycznie tak było... I pewnie w MyISAM - bo to jak sama nazwa 
wskazuje, takie DBFy (czyli ISAM) są z nakładka SQLa i razem to się zwie 
- MySQL.

> Wyjaśnię: tak, chcę dowolności choć zależnie od przyjętego rozwiązania
> nie musi być to "frywolne powiązanie" bez indeksów. Jeśli przyjęlibyśmy
> koncepcję dublowania wartości pól:
> a) W tabeli wartości pól
Trzymaj się tego, bo innego raczej nie ogarniesz w tej chwili...

> b) W dynamicznie dostawianych polach w tabeli właściwej (tzn.
> zawierającej dane, które rozszerzamy o dodatkowe pola) z narzuceniem
> typu pól i budowaniem na nich indeksów gdzie trzeba.
>
> To wtedy nie ma problemu w tworzeniu relacji. Aczkolwiek dynamiczne
> dostawianie pól to nie jest profesjonalne podejście...
Uzasadnij, bo mam dokładnie odwrotne wyobrażenie.
Tylko jest kilka ALE - nie wyobrażam sobie ręcznego zarządzania tym 
bajzlem. to musi być rozwiązane systemowo i automatycznie w taki sposób, 
aby raz dodane pole było widoczne dla całego systemu.
Bez rekompilacji systemu (albo zmiany kodów źródłowych w językach 
skryptowych - jeżeli ktoś się ma ochotę czepić...).
Ale takie podejście przerasta większość "programistów".
Sorry - taka prawda.

Po drugie, nie każdemu takie podejście potrzebne. W realnym zastosowaniu 
okazuje się, że wykorzystanie paradygmatu EAV (doczytaj se w wikipedii 
czy gdzie tam chcesz co to, po co i na co) ze wszystkimi jego wadami 
daje po prostu radę.
I od tego bym na Twoim miejscu zaczął, skoro dla Ciebie "ogromna" baza 
danych ma 100 tabel ;-)

> Na wszelki wypadek zobrazuję co mam na myśli. Jakaś tabela, powiedzmy,
> że to "dokument", ma pola A, B i C. W trakcie pracy aplikacji klient
> zażyczył sobie mieć pole D, które np. ma zawierać ID do innej tabeli.
> Wchodzi w edytor rozszerzeń, dodaje sobie nowe pole i informuje system
> "to pole ma linkować do ID autora dokumentu" przykładowo. I co się wtedy
> dzieje:
>
> 1. W tabeli dodatkowych pól powstaje pole D, jego opisy etc.
W EAV nie dodaje się pola, tylko wiersz do tabeli definicji pola.
Na jego poziomie definiujesz nazwę, typ danych, constraint i link do 
relacji/obiektu biznesowego. Ja bym jeszcze dodał flagę określającą, czy 
dana wartość jest skalarna czy wektorowa.
A same wartości lecą do innej tabli, która jest połączona z tabelą 
definicji pola.
Ot i cała magia.

> 2. W tabeli wartości następuje skojarzenie w/w pola D z rekordem w
> tabeli "dokument" i w uniwersalnym typie text pola "wartość" jest
> przechowywana liczba oznaczająca ID użytkownika w tabeli userów. No ale
> raczej kiepsko byłoby budować indeksowanie na polu tekstowym, które raz
> jest liczbą a innym razem tekstem.
Zależy.
Ale po cholerę Ci indeks na tym polu?

> 3. Z w/w powodu dostawiamy pole danych D do tabeli "dokument" (lub
> tabeli powiązanej poprzez dziedziczenie - inherit)
Dziedziczenie w bazach relacyjnych? Ho, ho... można i tak, ale ja bym 
się w to nie bawił.
Oczywiście są bazy post-relacyjne lub obiektowo-relacyjne, które 
zapewniają rożne wsparcie do takich zabawek (mam na myśli OOP w ujęciu 
bazo-danowym).
Moim zdaniem - nie warto. Więcej z tym kłopotów niż pożytku.
Ale ja tam się na tym nie znam...

> już właściwego typu,
> czyli int4 i tworzymy na nim indeks (dynamicznie również - czyli z
> poziomu działania logiki aplikacji).
No i po co ten indeks?
Indeks należy dodać wtedy kiedy jest NIEZBĘDNY, a nie od razu bo może 
się przyda...
To tak jak testować aplikację z pusta bazą danych.
Tragedia...

> Zazwyczaj w polach rozszerzonych bardzo mało danych będzie
> przechowywanych (liczby, krótkie teksty) więc ich dublowanie nie będzie
> bolesne objętościowo. Jednocześnie otrzymujemy łatwy dostęp do tych
> danych poprzez select * from dokument, działają constrainy.
Constrainty (banał) i budowanie SQL (a tu zależy - może to być w miarę 
proste lub nie) możesz sobie załatwić po stronie aplikacji.
Napiszesz to raz i będzie działało z dowolnym typem dokumentu.
Tu nie ma co dywagować, tylko doczytać o EAV i zakodować.
Do roboty! ;-)

-- 
wloochacz