Wersjonowanie obiektów w bazie danych - architektura - poprawiony diagram!!

499 views
Skip to first unread message

Krzysztof Nielepkowicz

unread,
Dec 4, 2012, 2:58:24 PM12/4/12
to warsza...@googlegroups.com
Na początek chcę się z wszystkimi przywitać - cześć :)

Co tak cicho? Zimno na Dworze się zrobiło i wszyscy poszli lepić
bałwanki z pociechami? :P

Teraz zupełnie na poważnie - najpierw problem potem rozwiązanie o którym
myślę

Problem - obiekt reprezentowany w tabeli jako rekord należy wersjonować.
Mamy powiedzmy tabelę Aplikacja z paronastoma kolumnami. Należy
zapisywać historię zmian danego obiektu, struktura powinna umożliwić
odczytanie obiektu aktualnego dla podanej daty, nie powinna też
generować zbędnego obciążenia (migawki są wykluczone) Co więcej, obiekt
aplikacja jest powiązany z... powiedzmy obiektami Firma lub
Miejsce_Wdrożenia (jedna firma może wyprodkować/zakupić etc wiele
aplikacji) Więc przy zmodyfikowaniu rekordu aplikacji (powiedzmy
poprawki umożliwiły odpalenie jej na nowej wersji windowsa) jest
tworzona nowa "wersja"

Solution :

w diagramie dołączonym jako załącznik - gif dwukolorowy więc wiele nie waży

Dzięki takiemu rozwiązaniu mamy zachowane powiązania jak również i
informację o zmianach w obiekcie


P.S. tabele nie mają dużo pól ale na potrzeby przykładów trzeba
uruchomić wyobraźnię ;p na razie 100 kolumn to szersza tabela jaką
widziałem - ale widać niewiele w życiu jeszcze widziałem ;)

--
Serdecznie Pozdrawiam,
Krzysztof Nielepkowicz
fotografia : fotomilo.pl
mój programistyczny blog : http://kyniek.blogspot.com/
diagram.gif

Dominik Jarmułowicz

unread,
Dec 4, 2012, 3:43:30 PM12/4/12
to warsza...@googlegroups.com
Cześć,
Z tego co widzę Twoje rozwiązanie nie obsługuje usuwania wierszy.

Historie operacji proponował bym podzielić na dwie tabele:
- jedną utrzymującą informację o rodzaju operacji na wierszu (insert/update/delete),
- drugą utrzymującą informację o zmianie kolumny w ramach operacji na danym wierszu.

ags

unread,
Dec 4, 2012, 3:45:35 PM12/4/12
to warsza...@googlegroups.com
A naprawdę nie chcesz tego zakodować na eventach?

2012/12/4 Dominik Jarmułowicz <dominik.j...@iem.pw.edu.pl>
--
Wiadomość z grupy Warszawa Java User Group (Warszawa JUG).
Więcej informacji na stronie http://groups.google.com/group/warszawa-jug?hl=pl
Zachęcamy do odwiedzenia naszej strony domowej http://warszawa.jug.pl
Oferty pracy dozwolone zgodnie z zasadami na http://sites.google.com/site/warszawajug/oferty-pracy-na-grupie



--
ags

Łukasz Żuchowski

unread,
Dec 4, 2012, 3:48:08 PM12/4/12
to warsza...@googlegroups.com
A dlaczego by nie użyć enversa ?
Pozdrawiam,

Łukasz

Krzysztof Nielepkowicz

unread,
Dec 4, 2012, 3:55:21 PM12/4/12
to warsza...@googlegroups.com
Dlatego �e ma to by� rozwi�zanie koncepcyjne i jakie kolwiek magiczne
frameworki nie s� rozwi�zaniem. Zapomnia�em doda� - nie musi by�
operacji usuwania - z definicji co raz trafi do bazy nie mo�e by� z niej
usuni�te - ale je�li mia�y by by� operacji usuwania to czemu nie doda�
kolumny z flag� do tabeli "Modification". Wiem �e to nie temat na grup�
javovďż˝ bo raczej dotyczy architektury niďż˝ konkretnych bibliotek i
framework�w, ale pomy�la�em �e znajd� si� osoby kt�re ch�tnie pog��wkuj�
;p ja tam lubi� g�owkowa� ;p



--
Serdecznie Pozdrawiam,
Krzysztof Nielepkowicz
fotografia : fotomilo.pl
m�j programistyczny blog : http://kyniek.blogspot.com/

> A dlaczego by nie u�y� enversa ?
>
> W dniu 4 grudnia 2012 21:45 u�ytkownik ags <andrzej...@gmail.com> napisa�:
>> A naprawdďż˝ nie chcesz tego zakodowaďż˝ na eventach?
>>
>> 2012/12/4 Dominik Jarmu�owicz <dominik.j...@iem.pw.edu.pl>
>>> Cze��,
>>> Z tego co widz� Twoje rozwi�zanie nie obs�uguje usuwania wierszy.
>>>
>>> Historie operacji proponowaďż˝ bym podzieliďż˝ na dwie tabele:
>>> - jedn� utrzymuj�c� informacj� o rodzaju operacji na wierszu
>>> (insert/update/delete),
>>> - drug� utrzymuj�c� informacj� o zmianie kolumny w ramach operacji na
>>> danym wierszu.
>>>
>>> W dniu wtorek, 4 grudnia 2012 20:58:24 UTC+1 u�ytkownik Krzysztof napisa�:
>>>> Na pocz�tek chc� si� z wszystkimi przywita� - cze�� :)
>>>>
>>>> Co tak cicho? Zimno na Dworze si� zrobi�o i wszyscy poszli lepi�
>>>> ba�wanki z pociechami? :P
>>>>
>>>> Teraz zupe�nie na powa�nie - najpierw problem potem rozwi�zanie o kt�rym
>>>> my�l�
>>>>
>>>> Problem - obiekt reprezentowany w tabeli jako rekord nale�y wersjonowa�.
>>>> Mamy powiedzmy tabel� Aplikacja z paronastoma kolumnami. Nale�y
>>>> zapisywa� histori� zmian danego obiektu, struktura powinna umo�liwi�
>>>> odczytanie obiektu aktualnego dla podanej daty, nie powinna teďż˝
>>>> generowa� zb�dnego obci��enia (migawki s� wykluczone) Co wi�cej, obiekt
>>>> aplikacja jest powi�zany z... powiedzmy obiektami Firma lub
>>>> Miejsce_Wdro�enia (jedna firma mo�e wyprodkowa�/zakupi� etc wiele
>>>> aplikacji) Wi�c przy zmodyfikowaniu rekordu aplikacji (powiedzmy
>>>> poprawki umo�liwi�y odpalenie jej na nowej wersji windowsa) jest
>>>> tworzona nowa "wersja"
>>>>
>>>> Solution :
>>>>
>>>> w diagramie do��czonym jako za��cznik - gif dwukolorowy wi�c wiele nie
>>>> wa�y
>>>>
>>>> Dzi�ki takiemu rozwi�zaniu mamy zachowane powi�zania jak r�wnie� i
>>>> informacjďż˝ o zmianach w obiekcie
>>>>
>>>>
>>>> P.S. tabele nie maj� du�o p�l ale na potrzeby przyk�ad�w trzeba
>>>> uruchomi� wyobra�ni� ;p na razie 100 kolumn to szersza tabela jak�
>>>> widzia�em - ale wida� niewiele w �yciu jeszcze widzia�em ;)
>>>>
>>>> --
>>>> Serdecznie Pozdrawiam,
>>>> Krzysztof Nielepkowicz
>>>> fotografia : fotomilo.pl
>>>> m�j programistyczny blog : http://kyniek.blogspot.com/
>>> --
>>> Wiadomo�� z grupy Warszawa Java User Group (Warszawa JUG).
>>> Wi�cej informacji na stronie
>>> http://groups.google.com/group/warszawa-jug?hl=pl
>>> Zach�camy do odwiedzenia naszej strony domowej http://warszawa.jug.pl
>>> Oferty pracy dozwolone zgodnie z zasadami na
>>> http://sites.google.com/site/warszawajug/oferty-pracy-na-grupie
>>
>>
>>
>> --
>> ags
>>
>> --
>> Wiadomo�� z grupy Warszawa Java User Group (Warszawa JUG).
>> Wi�cej informacji na stronie
>> http://groups.google.com/group/warszawa-jug?hl=pl
>> Zach�camy do odwiedzenia naszej strony domowej http://warszawa.jug.pl

Grzegorz Balcerek

unread,
Dec 4, 2012, 4:59:40 PM12/4/12
to warsza...@googlegroups.com
Cześć,

Dopytuję bo nie jestem przekonany że rozumiem wymagania.

Jakie operacje nie powinny generować obciążenia? odczyty? zapisy?  Co
powinno być bardziej zoptymalizowane? Odczyty? Zapisy?  Co to znaczy
zapisywać historię zmian? Historię zmian konkretnych pól, czy
wystarczy historię zmian obiektu traktowanego jako całość? Z diagramu
wnioskuję że może chodzi o to pierwsze, ale wolę dopytać.

No bo proste rozwiązanie polegać może na tym, że dodajesz do tabeli
Aplication datę (i do jej klucza głównego też) i zapisujesz w tej
tabeli kolejne wersje obiektów jako kolejne rekordy. A potem
odczytywanie odpowiedniej wersji dla danej daty to kwestia napisania
odpowiedniego zapytania SQL.

Ale czy takie rozwiazanie spełnia wymagania?

Pozdrawiam,
Grzegorz Balcerek

Krzysztof Nielepkowicz

unread,
Dec 4, 2012, 5:29:39 PM12/4/12
to warsza...@googlegroups.com
hey,

mechanizm migawkowy o kt�rym piszesz nie jest w�a�ciwym rozwi�zaniem - powiedzmy �e do tabeli Application odwo�uje si� tabela Version - gdy stworzysz nowy rekord z dat� modyfikacji w tabeli Application to b�dzie on posiada� inne ID ni� rekordy z tabeli Version wskazuj�ce na ten rekord - wtedy albo je te� skopiujemy... albo b�d� wskazywa� na pierwotn� wersj� obiektu. Usuwanie - natura historii nie wymaga usuwania, najwy�ej mo�emy deaktywowa� obiekt.

Tak sobie my�l� �e dla optymalizacji mo�na trzyma� aktualn� wersj� obiektu w osobnej tabeli - ID obiektu pierwotnego i aktualnego powinno by� identyczne, tak by nie niszczy� wi�z�w sp�jno�ci.


--
Serdecznie Pozdrawiam,
Krzysztof Nielepkowicz
fotografia : fotomilo.pl
m�j programistyczny blog : http://kyniek.blogspot.com/
Cze��,

Dopytuj� bo nie jestem przekonany �e rozumiem wymagania.

Jakie operacje nie powinny generowa� obci��enia? odczyty? zapisy? �Co
powinno by� bardziej zoptymalizowane? Odczyty? Zapisy? �Co to znaczy
zapisywa� histori� zmian? Histori� zmian konkretnych p�l, czy
wystarczy histori� zmian obiektu traktowanego jako ca�o��? Z diagramu
wnioskuj� �e mo�e chodzi o to pierwsze, ale wol� dopyta�.

No bo proste rozwi�zanie polega� mo�e na tym, �e dodajesz do tabeli
Aplication dat� (i do jej klucza g��wnego te�) i zapisujesz w tej
tabeli kolejne wersje obiekt�w jako kolejne rekordy. A potem
odczytywanie odpowiedniej wersji dla danej daty to kwestia napisania
odpowiedniego zapytania SQL.

Ale czy takie rozwiazanie spe�nia wymagania?

Pozdrawiam,
Grzegorz Balcerek


On Tuesday, December 4, 2012 8:58:24 PM UTC+1, Krzysztof wrote:
Na pocz�tek chc� si� z wszystkimi przywita� - cze�� :)

Co tak cicho? Zimno na Dworze si� zrobi�o i wszyscy poszli lepi�
ba�wanki z pociechami? :P

Teraz zupe�nie na powa�nie - najpierw problem potem rozwi�zanie o kt�rym
my�l�

Problem - obiekt reprezentowany w tabeli jako rekord nale�y wersjonowa�.
Mamy powiedzmy tabel� Aplikacja z paronastoma kolumnami. Nale�y
zapisywa� histori� zmian danego obiektu, struktura powinna umo�liwi�
odczytanie obiektu aktualnego dla podanej daty, nie powinna teďż˝
generowa� zb�dnego obci��enia (migawki s� wykluczone) Co wi�cej, obiekt
aplikacja jest powi�zany z... powiedzmy obiektami Firma lub
Miejsce_Wdro�enia (jedna firma mo�e wyprodkowa�/zakupi� etc wiele
aplikacji) Wi�c przy zmodyfikowaniu rekordu aplikacji (powiedzmy
poprawki umo�liwi�y odpalenie jej na nowej wersji windowsa) jest
tworzona nowa "wersja"

Solution :

w diagramie do��czonym jako za��cznik - gif dwukolorowy wi�c wiele nie wa�y

Dzi�ki takiemu rozwi�zaniu mamy zachowane powi�zania jak r�wnie� i
informacjďż˝ o zmianach w obiekcie


P.S. tabele nie maj� du�o p�l ale na potrzeby przyk�ad�w trzeba
uruchomi� wyobra�ni� ;p na razie 100 kolumn to szersza tabela jak�
widzia�em - ale wida� niewiele w �yciu jeszcze widzia�em ;)

--
Serdecznie Pozdrawiam,
Krzysztof Nielepkowicz
fotografia : fotomilo.pl
m�j programistyczny blog : http://kyniek.blogspot.com/

Grzegorz Balcerek

unread,
Dec 4, 2012, 5:53:56 PM12/4/12
to warsza...@googlegroups.com
Nie, nie będzie posiadał innego ID.
Nowe rekordy dotyczące tego samego obiektu w tabeli Application wstawiasz z tym samym ID, a tylko z różną datą.
Natomiast kluczem tabeli nie jest samo ID, tylko para (ID, data).
Czy rekordy z tabeli Version i innych też mają być wersjonowane?
Czy historia modyfikacji ma być tylko liniowa? Nie ma wymagania żeby historia wersji tworzyła drzewo?
To znaczy czy nowe wersje mogą powstawać tylko w oparciu o ostatnie obiekty?

Grzegorz Balcerek

Krzysztof Nielepkowicz

unread,
Dec 4, 2012, 6:06:18 PM12/4/12
to warsza...@googlegroups.com
On 2012-12-04 23:53, Grzegorz Balcerek wrote:
> Nie, nie b�dzie posiada� innego ID.
> Nowe rekordy dotycz�ce tego samego obiektu w tabeli Application
> wstawiasz z tym samym ID, a tylko z r�n� dat�.
> Natomiast kluczem tabeli nie jest samo ID, tylko para (ID, data).
> Czy rekordy z tabeli Version i innych teďż˝ majďż˝ byďż˝ wersjonowane?
> Czy historia modyfikacji ma by� tylko liniowa? Nie ma wymagania �eby
> historia wersji tworzy�a drzewo?
> To znaczy czy nowe wersje mogďż˝ powstawaďż˝ tylko w oparciu o ostatnie
> obiekty?
>
> Grzegorz Balcerek
> www.grzegorzbalcerek.net
>
> --
> Wiadomo�� z grupy Warszawa Java User Group (Warszawa JUG).
> Wi�cej informacji na stronie
> http://groups.google.com/group/warszawa-jug?hl=pl
> Zach�camy do odwiedzenia naszej strony domowej http://warszawa.jug.pl
> Oferty pracy dozwolone zgodnie z zasadami na
> http://sites.google.com/site/warszawajug/oferty-pracy-na-grupie
Zachowanie ID w nowej wersji obiektu po przez stworzenie z�o�onego
klucza g��wnego nie jest zbyt wydajnym rozwi�zaniem - opr�cz tego co
je�li w tabeli Version jest pole application_ID - do kt�rego obiektu ma
si� odwo�ywa�? Historia ma by� liniowa, cho� ciekawym wyzwaniem by by�o
wymy�lenie struktury dla historii "drzewiastej" ;) Wersjonowanie innych
obiekt�w z innych tabel te� powinno by�, w ka�dym razie mechanizm nie
powinien wyklucza� mo�liwo�ci wersjonowania obiekt�w w tabelach powi�zanych.

Grzegorz Balcerek

unread,
Dec 4, 2012, 7:14:02 PM12/4/12
to warsza...@googlegroups.com
Dlaczego to nie jest wydajne rozwiązanie? W porównaniu z czym nie jest wydajne?
Zakładam że w bazie są odpowiednie indeksy a silnik bazy danych umie optymalizować wykonanie zapytań SQL.
To chyba nie są wygórowane wymagania?

Może przykład coś rozjaśni? Rozważam tabele Applications i Versions, obie wersjonowane.

Załóżmy że w tabeli Applications masz rekordy:
A: (ID=1, data=1 grudnia, ...)
B: (ID=1, data=4 grudnia, ...)

Natomiast w tabeli Versions (też wersjonowanej) następujące:
C: (ID=1, data=1 grudnia, Application_ID=1, ...)
D: (ID=1, data=5 grudnia, Application_ID=1, ...)
E: (ID=2, data=3 grudnia, Application_ID=1, ...)

W obu tabelach kluczem głównym jest para (ID, data)

Spójny stan na dzień 1 grudnia reprezentują rekordy: A, C
Spójny stan na dzień 2 grudnia reprezentują rekordy: A, C
Spójny stan na dzień 3 grudnia reprezentują rekordy: A, C, E
Spójny stan na dzień 4 grudnia reprezentują rekordy: B, C, E
Spójny stan na dzień 5 grudnia reprezentują rekordy: B, D, E

Mechanizmów dotyczących historii "drzewiastej" nie trzeba wymyślać. Wystarczy poczytać: 

Grzegorz Balcerek

Tomasz Szymanski

unread,
Dec 5, 2012, 2:50:08 AM12/5/12
to warsza...@googlegroups.com
To sobie zobacz jak envers dziala i bedziesz wiedzial jak to mozna zapisac ;-)

Generalnie kazda tabelka ma swoja siostrzana tabelke _AUD, ktora ma dodatkowe dwie kolumny rewizje i typ operacji. Do tego dochodzi wspolna tabelka z rewizjami w ktorej sa tez daty dodania rewizji i dowolne inne informacje (takie jak uzytkownik ktory zrobil zmiany itd.).

W typie operacji mozesz miec dodanie, zmiane albo usuniecie. Jak zrobisz taki typ danych mozesz juz dowolne informacje wyciagac.

T.

On Dec 4, 2012, at 9:55 PM, Krzysztof Nielepkowicz <k.p.niel...@gmail.com> wrote:

> Dlatego że ma to być rozwiązanie koncepcyjne i jakie kolwiek magiczne frameworki nie są rozwiązaniem. Zapomniałem dodać - nie musi być operacji usuwania - z definicji co raz trafi do bazy nie może być z niej usunięte - ale jeśli miały by być operacji usuwania to czemu nie dodać kolumny z flagą do tabeli "Modification". Wiem że to nie temat na grupę javovą bo raczej dotyczy architektury niż konkretnych bibliotek i frameworków, ale pomyślałem że znajdą się osoby które chętnie pogłówkują ;p ja tam lubię głowkować ;p
>
>
>
> --
> Serdecznie Pozdrawiam,
> Krzysztof Nielepkowicz
> fotografia : fotomilo.pl
> mój programistyczny blog : http://kyniek.blogspot.com/
>
>> A dlaczego by nie użyć enversa ?
>>
>> W dniu 4 grudnia 2012 21:45 użytkownik ags <andrzej...@gmail.com> napisał:
>>> A naprawdę nie chcesz tego zakodować na eventach?
>>>
>>> 2012/12/4 Dominik Jarmułowicz <dominik.j...@iem.pw.edu.pl>
>>>> Cześć,
>>>> Z tego co widzę Twoje rozwiązanie nie obsługuje usuwania wierszy.
>>>>
>>>> Historie operacji proponował bym podzielić na dwie tabele:
>>>> - jedną utrzymującą informację o rodzaju operacji na wierszu
>>>> (insert/update/delete),
>>>> - drugą utrzymującą informację o zmianie kolumny w ramach operacji na
>>>> danym wierszu.
>>>>
>>>> W dniu wtorek, 4 grudnia 2012 20:58:24 UTC+1 użytkownik Krzysztof napisał:
>>>>> Na początek chcę się z wszystkimi przywitać - cześć :)
>>>>>
>>>>> Co tak cicho? Zimno na Dworze się zrobiło i wszyscy poszli lepić
>>>>> bałwanki z pociechami? :P
>>>>>
>>>>> Teraz zupełnie na poważnie - najpierw problem potem rozwiązanie o którym
>>>>> myślę
>>>>>
>>>>> Problem - obiekt reprezentowany w tabeli jako rekord należy wersjonować.
>>>>> Mamy powiedzmy tabelę Aplikacja z paronastoma kolumnami. Należy
>>>>> zapisywać historię zmian danego obiektu, struktura powinna umożliwić
>>>>> odczytanie obiektu aktualnego dla podanej daty, nie powinna też
>>>>> generować zbędnego obciążenia (migawki są wykluczone) Co więcej, obiekt
>>>>> aplikacja jest powiązany z... powiedzmy obiektami Firma lub
>>>>> Miejsce_Wdrożenia (jedna firma może wyprodkować/zakupić etc wiele
>>>>> aplikacji) Więc przy zmodyfikowaniu rekordu aplikacji (powiedzmy
>>>>> poprawki umożliwiły odpalenie jej na nowej wersji windowsa) jest
>>>>> tworzona nowa "wersja"
>>>>>
>>>>> Solution :
>>>>>
>>>>> w diagramie dołączonym jako załącznik - gif dwukolorowy więc wiele nie
>>>>> waży
>>>>>
>>>>> Dzięki takiemu rozwiązaniu mamy zachowane powiązania jak również i
>>>>> informację o zmianach w obiekcie
>>>>>
>>>>>
>>>>> P.S. tabele nie mają dużo pól ale na potrzeby przykładów trzeba
>>>>> uruchomić wyobraźnię ;p na razie 100 kolumn to szersza tabela jaką
>>>>> widziałem - ale widać niewiele w życiu jeszcze widziałem ;)
>>>>>
>>>>> --
>>>>> Serdecznie Pozdrawiam,
>>>>> Krzysztof Nielepkowicz
>>>>> fotografia : fotomilo.pl
>>>>> mój programistyczny blog : http://kyniek.blogspot.com/
>>>> --
>>>> Wiadomość z grupy Warszawa Java User Group (Warszawa JUG).
>>>> Więcej informacji na stronie
>>>> http://groups.google.com/group/warszawa-jug?hl=pl
>>>> Zachęcamy do odwiedzenia naszej strony domowej http://warszawa.jug.pl
>>>> Oferty pracy dozwolone zgodnie z zasadami na
>>>> http://sites.google.com/site/warszawajug/oferty-pracy-na-grupie
>>>
>>>
>>>
>>> --
>>> ags
>>>
>>> --
>>> Wiadomość z grupy Warszawa Java User Group (Warszawa JUG).
>>> Więcej informacji na stronie
>>> http://groups.google.com/group/warszawa-jug?hl=pl
>>> Zachęcamy do odwiedzenia naszej strony domowej http://warszawa.jug.pl
>>> Oferty pracy dozwolone zgodnie z zasadami na
>>> http://sites.google.com/site/warszawajug/oferty-pracy-na-grupie
>>
>>
>
> --
> Wiadomość z grupy Warszawa Java User Group (Warszawa JUG).
> Więcej informacji na stronie http://groups.google.com/group/warszawa-jug?hl=pl
> Zachęcamy do odwiedzenia naszej strony domowej http://warszawa.jug.pl
Reply all
Reply to author
Forward
0 new messages