Witam
Potrzebuję pomocy w sprawie następującej

mam zaimplementować strukturę organizacyjną w firmie
najlepiej myślę że w formie drzewa
ale bonusem jest to że ma być to drzewo z przechowywaniem historii

jeżeli chodzi o strukturę drzewa , to implementacje jest trywialna
ale zachowanie historii ( w sensie struktura na dany dzień) to już dla
mnie zagwozdka

czy może mnie ktoś nakierować na jakieś rozwiązania
jakiś algorytm albo przynajmniej gdzie szukać rozwiązań

Z góry dzięki

JB

do góry

On 5 Sty, 22:12, James Blond <t...@g...com> wrote:
> mam zaimplementować strukturę organizacyjną w firmie
>
> jeżeli chodzi o strukturę drzewa , to implementacje jest trywialna
> ale zachowanie historii ( w sensie struktura na dany dzień) to już dla
> mnie zagwozdka

Zmieniacie hierarchię służbową co pare dni? Podkręć jasność
w pytaniu, bo WTF się ciśnie na usta.

pozdr
Khorne

do góry

(...)
> Zmieniacie hierarchię służbową co pare dni? Podkręć jasność
> w pytaniu, bo WTF się ciśnie na usta.
>
> pozdr
> Khorne

no niestety :/
co prawda nie jest to "co parę dni"
ale w ciągu roku tych zmian troszkę jest
struktura ma obecnie około ~14k obiektów
i w ciągu roku takich drobnych zmian jest kilka - kilkanaście
a raz na dwa - trzy lata .... zmiany są "drastyczne"
taka permanentna reorganizacja :/

do góry

On 6 Sty, 06:34, James Blond <t...@g...com> wrote:
> no niestety :/
> co prawda nie jest to "co parę dni"
> ale w ciągu roku tych zmian troszkę jest
> struktura ma obecnie około ~14k obiektów
> i w ciągu roku takich drobnych zmian jest kilka - kilkanaście
> a raz na dwa - trzy lata .... zmiany są "drastyczne"
> taka permanentna reorganizacja :/

Cóż, możesz trzymać albo "na pałę" kopie poprzedniej struktury
drzewa, albo bawić się w przyrostowe liczenie zmian.

Niestety w przypadku drzew nie jest to takie proste.
http://www.cs.wisc.edu/niagara/papers/xdiff.pdf

pozdr
Khorne

do góry

James Blond pisze:
> (...)
>> Zmieniacie hierarchię służbową co pare dni? Podkręć jasność
>> w pytaniu, bo WTF się ciśnie na usta.
>>
>> pozdr
>> Khorne
>
> no niestety :/
> co prawda nie jest to "co parę dni"
> ale w ciągu roku tych zmian troszkę jest
> struktura ma obecnie około ~14k obiektów
To nie mała firma.... (Juz mi się cisnęło na usta XML + wersjonowanie,
ale nie ta wielkość.).

Tak sobie myślę, to twoje drzewo rozumiem nie jest sobie a muzom, ma
ktoś/coś tego drzewa używać, sugeruję coś standardowego. A jak drzewo
zwłaszcza duże i standard to LDAP i okolice (ActiveDirectory, eDirectory
czy coś z Open Soursów), i koło tego głęboko poszukać w dokumentacji
(zwłaszcza w rozszerzeniach komercyjnych), poszukać wartości dodanej.
Wielość narzędzi do edycji drzewa, dostępność ze wszystkich prawie
środowisk programistycznych itd. wiadomo, wszystko co idzie za standardem.

Z serwerów zainteresował mnie Apache Directory (jestem z nim na poziomie
lektury dokumentacji), dość nowy projekt, jest kompatybilny z LDAP a
extra potrafi podobno trzymać w drzewie nie literki i cyferki, a żywe
obiekty Javy. To mnie zainteresowało.


Co nie oznacza że mam na temat historii/wersji w drzewie LDAP gotową radę.

do góry

(ciach)
LDAP wydaje się świetnym pomysłem ... i też go rozważałem ale
problemem może się okazać to że reszta danych jest w bazie
relacyjnej ... i do z tej bazy będzie większość zapytań o
strukturę ...
więc obawiam się niestety że muszę zaimplementować to na "płaskich
strukturach"

troszku "poradziliśmy" w firmie...
i wyłoniła się koncepcja następująca (mam nadzieję że uda mi się w
miarę jasno przedstawić)

stanem wyjściowym jest struktura drzewa (dziecko pokazuje na rodzica
R1)

każda edycja dziecka D1 powoduje
1) D1 zostaje "zamknięte"
2) tworzone jest nowe dziecko D1' pokazujące na rodzica R1
3) wszystkie "poddzieci" D1 (DD1 - DDX) rekurencyjnie w dół są
"zamykane" oraz tworzona jest kopia ich z D1 jako rodzicem
4) wszystkie obiekty powiązane z D1 muszą zostać zaktualizowane aby
pokazywały na D1'

jeżeli następowało by przeniesienie w strukturze to postępowanie było
by podobne z tym że D1' pokazywało by na nowego rodzica R2

... jeszcze nie jestem na fazie implementacji więc kolejność
niekoniecznie taka ;)

wielkim minusem rozwiązania jest pkt 4 bo tych obiektów powiązanych
jest dużo i w różnych miejscach :/
innym minusem edycja "dzieci" które są wysoko w strukturze spowoduje
utworzenie praktycznie całej kopii drzewa - ale tu mam nadzieję że
najwięcej edycji będzie jednak na dole drzewa



jest jeszcze jedna koncepcja
a mianowicie robienie kopi całego drzewa do tablicy "archiwum" przed
każdą zmianą ... ale nie wydaje się to być eleganckim rozwiązaniem :/
( za to jest proste w implementacji :D )


uwagi mile widziane

do góry

wkradł sie mały błąd pkt powinien brzmieć następująco
3) wszystkie "poddzieci" D1 (DD1 - DDX) rekurencyjnie w dół są
"zamykane" oraz tworzona jest kopia ich z D1' jako rodzicem

D1' a nie D1 na końcu wiersza
sorki za zamieszanie

do góry

James Blond pisze:
> (ciach)
> LDAP wydaje się świetnym pomysłem ... i też go rozważałem ale
> problemem może się okazać to że reszta danych jest w bazie
> relacyjnej ... i do z tej bazy będzie większość zapytań o
> strukturę ...
Sam nie używałem, ale widocznie nie jesteś odosobniony w potrzebach
skoro ktoś robi drivery ODBC do LDAP-a (Np. Novell). Jednak łatwiej
dostać się do danych po standardowcyh protokołach niż wynalazkami, np.
kwerendami sql o długości dwóch ekranów.
> więc obawiam się niestety że muszę zaimplementować to na "płaskich
> strukturach"
>
> troszku "poradziliśmy" w firmie...
Gadałem kiedyś z gościem który 'radził' sobie ulepszając z czasem
SQL-ową implementację drzewa tag go ulepszył, ze wynalazł 'prawie
ldap-a' tyle że się orobił i nie uzyskał tej jakości

Z innej strony backendem pod niektóre serwery LDAP bywa SQL (rzadko bo
może chodzić o wydajność?). Sprawdź, co ma pod spodem Apache Directory
(nie pamietam)

do góry