Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > pl.comp.programming > #32743 > unrolled thread

Serializacja obiektów w bazie danych - jakie podejście jest zalecane?

Back to article view | Back to pl.comp.programming

Contents

  Serializacja obiektów w bazie danych - jakie podejście jest zalecane? Szyk Cech <szykcech@spoko.pl> - 2019-07-27 17:11 +0200
    Re: Serializacja obiektów w bazie danych - jakie podejście jest zalecane? Maciej Sobczak <see.my.homepage@gmail.com> - 2019-07-27 12:39 -0700
      Re: Serializacja obiektów w bazie danych - jakie podejście jest zalecane? Szyk Cech <szykcech@spoko.pl> - 2019-07-27 21:57 +0200
        Re: Serializacja obiektów w bazie danych - jakie podejście jest zalecane? Maciej Sobczak <see.my.homepage@gmail.com> - 2019-07-28 12:58 -0700
        Re: Serializacja obiektów w bazie danych - jakie podejście jest zalecane? Tomasz Kaczanowski <kaczus@poczta.onet.pl> - 2019-07-29 09:07 +0200
          Re: Serializacja obiektów w bazie danych - jakie podejście jest zalecane? Szyk Cech <szykcech@spoko.pl> - 2019-07-29 17:03 +0200
            Re: Serializacja obiektów w bazie danych - jakie podejście jest zalecane? Tomasz Kaczanowski <kaczus@poczta.onet.pl> - 2019-07-30 08:23 +0200
              Re: Serializacja obiektów w bazie danych - jakie podejście jest zalecane? Szyk Cech <szykcech@spoko.pl> - 2019-07-31 18:30 +0200
            Re: Serializacja obiektów w bazie danych - jakie podejście jest zalecane? Maciej Sobczak <see.my.homepage@gmail.com> - 2019-07-30 01:51 -0700
              Re: Serializacja obiektów w bazie danych - jakie podejście jest zalecane? Szyk Cech <szykcech@spoko.pl> - 2019-07-31 18:40 +0200
                Re: Serializacja obiektów w bazie danych - jakie podejście jest zalecane? wloochacz <wloochacz@no.spam.gmail.com> - 2019-07-31 18:52 +0200
                Re: Serializacja obiektów w bazie danych - jakie podejście jest zalecane? Maciej Sobczak <see.my.homepage@gmail.com> - 2019-08-01 04:41 -0700
                  Re: Serializacja obiektów w bazie danych - jakie podejście jest zalecane? "M.M." <mmarszik@gmail.com> - 2019-09-02 05:56 -0700
                    Re: Serializacja obiektów w bazie danych - jakie podejście jest zalecane? Szyk Cech <szykcech@spoko.pl> - 2019-09-02 17:46 +0200
    Re: Serializacja obiektów w bazie danych - jakie podejście jest zalecane? queequeg@trust.no1 (Queequeg) - 2019-07-29 15:15 +0000

#32743 — Serializacja obiektów w bazie danych - jakie podejście jest zalecane?

Witam

Chcę rozpocząć nowy projekt od zera. Projekt będzie dotyczył prostego 
programu edukacyjnego do nauki angielskiego (takie lepsze SuperMemo) 
opartego o bazę danych. Program ma być dostosowany do użytku na 
sprytnych telefonach komórkowych z systemem Android (oraz na tabletach i 
PC z Windows lub Linux).

Chcę do tego projektu zrobić bazę danych. Jednak nie głupią.
Oczekiwane cechy modułu bazy danych:

* zamyka w sobie całą specyfikę biblioteki pośredniczącej, motoru i 
zapytań Sql-a.

* struktura bazy danych generuje się automatycznie z klas C++. Klasy 
zachowalne w bazie są wzbogacane o makra: PRIMARY_KEY, 
FOREIGN_KEY(klasa.zmienna1, klasa.zmiennaN), INDEX, NO_STORE. Makra te 
nic nie robią z poziomu C++, mają znaczenie tylko dla parsera klas 
zachowalnych.

* przed zbudowaniem aplikacji jest uruchamiany parser klas zachowalnych

* parser klas zachowalnych wykrywa zmiany w klasach zachowalnych i 
generuje: pierwszą wersję pliku struktury danych w SQL-u lub pacz w 
porównianiu do poprzedniej wersji, oraz nową wersję klasy bazy danych.

* parser dodaje do pacza pustą i popsutą metodę migrateData() którą 
trzeba naprawić i odpowiednio uzupełnić (bez naprawienia się nie 
skompiluje).

* po skompilowaniu uruchamiana aplikacja wykrywa jakie pacze powinna 
zastosować na bazie i w razie potrzeby ją aktualizuje w pełni automatycznie.

To wiem jak zrobić.

Natomiast nie wiem, czy generowane funkcje do obsługi bazy danych:
1. Powinny znajdować się w jednej super klasie?
2. Powinny być rozrzucone w klasach serializujących poszczególne obiekty?

Ja pierwotnie zrobiłem ten generator struktury baz danych i paczy do 
nich tak że generował jedną super klasę. Jednak nie wiem czy to 
prawidłowe podejście. Mi się wydaje, że tak, bo całą logikę bazy danych 
miałem zawsze w jednej klasie jaką sobie przezywałem using-iem tak by 
mimo podbijania wersji bazy nic nie zmieniać w kodzie.

Jakie są zalety użycia wielu klas (po jednej do każdej zachowalnej klasy?

Jak to robią korporacje? Jak się to robi w dużych systemach?

dzięki tym co wytrwali do końca
pozdro
Szyk Cech

[toc] | [next] | [standalone]

#32744

> Chcę rozpocząć nowy projekt od zera.

Tak zawsze jest najfajniej. :-)

> * struktura bazy danych generuje się automatycznie z klas C++.

Dlaczego?

Tylko nie pisz, żeby było łatwiej. Bo kolejne punkty, które napisałeś, to opis dodatkowych kosztów, które musisz ponieść. I to tylko tych, które przewidziałeś.

> Jak to robią korporacje? Jak się to robi w dużych systemach?

Czasami jeszcze gorzej...

-- 
Maciej Sobczak * http://www.inspirel.com

[toc] | [prev] | [next] | [standalone]

#32745

>> * struktura bazy danych generuje się automatycznie z klas C++.
> 
> Dlaczego?

Hasło: DRY (ang.: Don't repeat yourself.).

Nie zmierzam robić tego raz. Chcę stworzyć mechanizm generowania baz dla 
wszelkich moich projektów bazodanowych. Chcę mieć potem wygodę używania 
tego rozwiązania (tak wiem by to osiągnąć muszę napisać drugie tyle 
testów automatycznych).

SOCI ma pełnić w tym kluczową rolę, bo jak rozumiem przykrywa nawet 
specyficzną składnię danego motoru (ujednolica ją). Prawdopodobnie będę 
musiał użyć wersji 3.x z uwagi na stabilność. Szkoda, że nie wiadomo 
jakie są różnice między wersjami 3.x a 4.0...

[toc] | [prev] | [next] | [standalone]

#32747

> >> * struktura bazy danych generuje się automatycznie z klas C++.
> > 
> > Dlaczego?
> 
> Hasło: DRY (ang.: Don't repeat yourself.).

No ale gdzie to "repeat" miałoby być?

> Nie zmierzam robić tego raz.

Tym gorzej. Bo jeśli to nie jest dobre rozwiązanie (a tego jeszcze nie ustaliliśmy), to będziesz miał N źle zrobionych projektów.

> SOCI ma pełnić w tym kluczową rolę, bo jak rozumiem przykrywa nawet 
> specyficzną składnię danego motoru (ujednolica ją).

Niezupełnie przykrywa, chociaż miejscami próbuje. Tam, gdzie leci string, tam nie przykrywa - ten string ma być zrozumiały dla docelowej bazy.
Natomiast to, co przykrywa i to dosyć starannie, to wywołania natywnych API klienckich.

> Prawdopodobnie będę 
> musiał użyć wersji 3.x z uwagi na stabilność.

Z uwagi na stabilność najlepiej użyj najświeższej wersji z GitHuba, nie patrząc jaka to wersja. Od dłuższego czasu nie ma nowych funkcji, są tylko bugfiksy - więc im świeższy kod, tym lepiej.

> Szkoda, że nie wiadomo 
> jakie są różnice między wersjami 3.x a 4.0...

Różnica jest bardzo prosta i tylko jedna: wersji 4.0 nie ma.
Jeśli będzie, to będzie to najświeższa wersja z GitHuba. Właśnie dlatego nikt nie ma specjalnie motywacji, żeby to uroczyście zrobić.

-- 
Maciej Sobczak * http://www.inspirel.com

[toc] | [prev] | [next] | [standalone]

#32750

W dniu 2019-07-27 o 21:57, Szyk Cech pisze:
>>> * struktura bazy danych generuje się automatycznie z klas C++.
>>
>> Dlaczego?
> 
> Hasło: DRY (ang.: Don't repeat yourself.).
> 
> Nie zmierzam robić tego raz. Chcę stworzyć mechanizm generowania baz dla 
> wszelkich moich projektów bazodanowych. Chcę mieć potem wygodę używania 
> tego rozwiązania (tak wiem by to osiągnąć muszę napisać drugie tyle 
> testów automatycznych).
> 
> SOCI ma pełnić w tym kluczową rolę, bo jak rozumiem przykrywa nawet 
> specyficzną składnię danego motoru (ujednolica ją). Prawdopodobnie będę 
> musiał użyć wersji 3.x z uwagi na stabilność. Szkoda, że nie wiadomo 
> jakie są różnice między wersjami 3.x a 4.0...

Problem jest taki, że takie przebudowywanie bazy od strony programu 
wprowadza na bazę ograniczenia (szczególnie jeśli chodzi o rzeczy 
specyficzne dla danego silnika bazodanowego), po wtóre potrafi 
wygenerować dodatkowe problemy. Nadzorowanie struktury bazy z klienta to 
proszenie się o kłopoty. Pracuje przy jednym podobnym projekcie, kto w 
ten sposób obmyślił, niby wszystko fajnie, ale niestety jeśli potrzeba 
cos poprawić / zoptymalizować, zaczynają się schody. Dużo lepsze 
rozwiązanie było w poprzedni projekcie, przy którym pracowałem, gdzie 
baza była niezależna od kodu klienta, jeśli chodzi o strukturę. Jedyne 
co to baza pozwalała się podpiąć bądź nie w zależności od wersji programu.

-- 
http://kaczus.ppa.pl

[toc] | [prev] | [next] | [standalone]

#32756

On 29.07.2019 09:07, Tomasz Kaczanowski wrote:
> Nadzorowanie struktury bazy z klienta to proszenie się o kłopoty.

Chodzi o to by warstwa bazy danych była całkowicie zautomatyzowana 
(automatyzacja to atut systemów komputerowych). Ten mój generator będzie 
generował klasę Database_N_M w oparciu o klasy zachowalne umiejscowione 
w warstwie logiki biznesowej. Dopiero nad tą warstwą będzie interfejs 
użytkownika.

[toc] | [prev] | [next] | [standalone]

#32760

W dniu 2019-07-29 o 17:03, Szyk Cech napisał:
> On 29.07.2019 09:07, Tomasz Kaczanowski wrote:
>> Nadzorowanie struktury bazy z klienta to proszenie się o kłopoty.
> 
> Chodzi o to by warstwa bazy danych była całkowicie zautomatyzowana 
> (automatyzacja to atut systemów komputerowych). Ten mój generator będzie 
> generował klasę Database_N_M w oparciu o klasy zachowalne umiejscowione 
> w warstwie logiki biznesowej. Dopiero nad tą warstwą będzie interfejs 
> użytkownika.

Jak dla mnie abstrakcja jest wtedy gdy na najwyzszej warstwie jest 
funkcja, która mowi daj mi paczke danych o takich i takich parametrach, 
i nie wnika jak to robi funkcja. Czy tworzy zapytanie, czy korzysta z 
innego typu bazy (przecież bazy sql-owe to nie jedyne), czy nawet w 
SQL-owych, nie interesuje nas, czy pod spodem użyte jest zwykłe 
zapytanie, czy korzystamy z funkcji składowanej. Machanie przez ogon 
psem jest moim zdaniem nie najlepszym pomysłem, bo jak napisałem, 
właśnie to powinno być jak najbardziej odseparowane, a Ty chcesz mieć na 
to wpływ z poziomu kodu nie wiedząc czy to się będzie sprawdzać i skalować.
Takie automaty sa fajne, jak się je pisze, a jak później użytkownik musi 
używać, albo musisz dodać jakąś funkcjonalność, albo optymalizację 
zrobić, to odbijasz się od założeń i ograniczeń automatu.Dlatego zostaw 
te byty jako osobne, jedynie martwiąc się o to by sprawdzić, czy są w 
wersjach kompatybilnych.

-- 
http://kaczus.ppa.pl

[toc] | [prev] | [next] | [standalone]

#32769

On 30.07.2019 08:23, Tomasz Kaczanowski wrote:
> Takie automaty sa fajne, jak się je pisze, a jak później użytkownik musi 
> używać, albo musisz dodać jakąś funkcjonalność, albo optymalizację 
> zrobić, to odbijasz się od założeń i ograniczeń automatu.

Oba te przypadki:
* dodawanie nowej funkcjonalności
* optymalizację - (zmiana struktury lub dodanie indeksu)

Obsłużę z automatu...

[toc] | [prev] | [next] | [standalone]

#32761

> Chodzi o to by warstwa bazy danych była całkowicie zautomatyzowana 
> (automatyzacja to atut systemów komputerowych).

Automatyzacja jest możliwa, jeśli są wszystkie dane do automatycznego przetwarzania. A projekt bazy danych nie opiera się na strukturze programu, tylko na wymaganiach, które są powyżej projektowanego programu. Czyli nawet gdybyś chciał coś automatyzować, to nie na tej ścieżce:

program
    |
    V
baza danych,

tylko na takich:

    wymagania
     |     |
     V     V
program   baza danych

I tu byś był bliżej ideału, ale zwykle wymagania nie występują w formie, na której można jakąkolwiek automatyzację uprawiać (w szczególności: zwykle nie występują w żadnej formie). Ale da się ten proces, całościowo, uprawiać ręcznie - i zwykle jest to lepsze, niż ułomna automatyzacja, która ostatecznie może kosztować więcej, niż oszczędza.

Projekt bazy danych w ogóle nie musi się zgadzać 1:1 z projektem programu. W sensie - nawet liczba tabel nie musi się zgadzać z liczbą klas. Może być nawet tak, że ze względów wydajnościowych (albo innych) struktury bazy służące do zapisu danych będą inne, niż te służące do odczytu. Albo pierdylion innych możliwości, których nie da się obsłużyć automatem parsującym kod programu.

> Ten mój generator będzie 
> generował klasę Database_N_M w oparciu o klasy zachowalne umiejscowione 
> w warstwie logiki biznesowej.

Lepiej nie.
Najlepszy cytat w tym temacie: "It's a data base, not a data dump."

-- 
Maciej Sobczak * http://www.inspirel.com

[toc] | [prev] | [next] | [standalone]

#32770

> Projekt bazy danych w ogóle nie musi się zgadzać 1:1 z projektem programu.

Z tym, że mi chodzi o to by operować danymi na poziomie C++ a nie 
grzebać się w SQL-u. Szczerze mówiąc nie robię przy programach gdzie 
problemem jest brak odwzorowania 1:1 (tabel na klasy). Dlatego myślę, że 
scenariusz odwzorowania 1:1 jest najpowszechniejszy i jego autmatyzacja 
jest sensowna. Po za tym nie widzę przeszkód by osobno implementować 
bardziej złożone scenariusze. Ba! Przewiduję już to w obecnej 
implementacji gdzie generowane są:

Database_N_M

(N - numer główny, M - numer drugorzędny) którą przykrywam aliasem. Ta 
klasa zawiera obsługę (dodawanie, nadpisywanie, odczyt pojedynczych 
obiektów i otwieranie kursora do sekwencyjnego dostępu do danych) .

using Db = Database_N_M;

I z tego aliasu dziedziczę:

class Db_MyApp : public Db
{
public:
	// Tu dowolne funkcje z dziedziny problemowej aplikacji.
};

Skąd Wasze opory przed robieniem takich automatów jeśli oszczędzają one 
90% czasu na klepanie SQL-i?!?

[toc] | [prev] | [next] | [standalone]

#32771

W dniu 31.07.2019 o 18:40, Szyk Cech pisze:
>> Projekt bazy danych w ogóle nie musi się zgadzać 1:1 z projektem 
>> programu.
> 
> Z tym, że mi chodzi o to by operować danymi na poziomie C++ a nie 
> grzebać się w SQL-u. Szczerze mówiąc nie robię przy programach gdzie 
> problemem jest brak odwzorowania 1:1 (tabel na klasy). Dlatego myślę, że 
> scenariusz odwzorowania 1:1 jest najpowszechniejszy i jego autmatyzacja 
> jest sensowna. 
/Ciach/
Najprostszy, a nie najpowszechniejszy.
Czy jego obsługa jest sensowna?
To zależy, ja jeszcze nie miałem do czynienia z tak prostym modelem 
danych, aby sensownie wyglądał model obiektowy przy mapowaniu 1 do 1 na 
bazę danych.
Albo model wygląda dziwacznie, albo baza danych dostaje zadyszki przy 
prostych operacjach.
Dla mega-prostych zastosowań, pewnie czemu nie.

A tak poza tym... dziwie się, że jeszcze nikt nie podrzucił słowa 
klucza: ORM
Zanim zaczniesz wymyślać kwadratowe koła na nowa, to może sobie wpisz w 
googlarkę: SOCI ORM


I poczytaj ze zrozumieniem, a możesz się zdziwić...

-- 
wloochacz

[toc] | [prev] | [next] | [standalone]

#32774

> Skąd Wasze opory przed robieniem takich automatów jeśli oszczędzają one 
> 90% czasu na klepanie SQL-i?!?

Stąd, że przy prostych systemach pisanie SQLi prawie w ogóle nie zajmuje czasu, więc nie ma sensu inwestować, żeby tam coś zaoszczędzić; a przy skomplikowanych systemach niczego się nie zaoszczędzi automatyzacją.
Co więcej, nawet przy Twoim rozwiązaniu z dziedziczeniem klas możesz napotkać na opór programisty przed wprowadzaniem optymalizacji - wyobraź sobie, że jakiemuś SQLowi bardzo by pomogło jedno dodatkowe słowo (np. hint na użycie konkretnego indeksu, co jest częstym przypadkiem) - w Twoim rozwiązaniu, żeby to jedno słowo dopisać do zapytania, trzeba stworzyć dodatkowy byt w postaci klasy dziedziczącej. Zależnie od polityki zarządzania kodem, to może być konieczność dodania nowego pliku. Dalej być może zmiana skryptu budującego. Itd. Znam przypadek, kiedy to właśnie programista stawiał opór po tym, jak wcześniej sam poprosił admina o zdiagnozowanie słabej wydajności programu i admin po diagnozie zarekomendował drobną zmianę SQLa a na tą drobną zmianę programista nie miał procesu, bo mu framework (akurat w Javie) wszystko "automatyzował".

Napisz uczciwie SQLa. Nawet krótkiego.

-- 
Maciej Sobczak * http://www.inspirel.com

[toc] | [prev] | [next] | [standalone]

#32937

On Thursday, August 1, 2019 at 1:41:58 PM UTC+2, Maciej Sobczak wrote:
> > Skąd Wasze opory przed robieniem takich automatów jeśli oszczędzają one 
> > 90% czasu na klepanie SQL-i?!?
> 
> Stąd, że przy prostych systemach pisanie SQLi prawie w ogóle nie zajmuje czasu, więc nie ma sensu inwestować, żeby tam coś zaoszczędzić; a przy skomplikowanych systemach niczego się nie zaoszczędzi automatyzacją.
> Co więcej, nawet przy Twoim rozwiązaniu z dziedziczeniem klas możesz napotkać na opór programisty przed wprowadzaniem optymalizacji - wyobraź sobie, że jakiemuś SQLowi bardzo by pomogło jedno dodatkowe słowo (np. hint na użycie konkretnego indeksu, co jest częstym przypadkiem) - w Twoim rozwiązaniu, żeby to jedno słowo dopisać do zapytania, trzeba stworzyć dodatkowy byt w postaci klasy dziedziczącej. Zależnie od polityki zarządzania kodem, to może być konieczność dodania nowego pliku. Dalej być może zmiana skryptu budującego. Itd. Znam przypadek, kiedy to właśnie programista stawiał opór po tym, jak wcześniej sam poprosił admina o zdiagnozowanie słabej wydajności programu i admin po diagnozie zarekomendował drobną zmianę SQLa a na tą drobną zmianę programista nie miał procesu, bo mu framework (akurat w Javie) wszystko "automatyzował".
> 
> Napisz uczciwie SQLa. Nawet krótkiego.
> 
> -- 
> Maciej Sobczak * http://www.inspirel.com

Pracowałem zarówno na sqlu osadzanym bezpośrednio w kodzie (z różnym zestawem funkcji 
wspomagających, rzecz jasna, nie chodzi o to aby łączyć się z bazą po
soketach), jak i na różnych maperach i warstwach pośrednich. Nie wyrobiłem 
sobie zdania że jedno z tych rozwiązań jest wyraźnie lepsze lub gorsze. 
Na pewno w przypadku gdy pracowałem blisko sqla w kodzie, to łatwiej mogłem
dopisać funkcje które z punktu widzenia projektu były przydatne, a jakiś
framework/biblioteka niekoniecznie je oferował.

Pozdrawiam

[toc] | [prev] | [next] | [standalone]

#32938

Dzięki za opinię.

[toc] | [prev] | [next] | [standalone]

#32757

In pl.comp.programming Szyk Cech <szykcech@spoko.pl> wrote:

> Jak to robią korporacje? Jak się to robi w dużych systemach?

Nie chcesz wiedzieć. Korporacje rządzą się swoimi prawami.

Ale może protocol buffers cię zainteresują.

-- 
https://www.youtube.com/watch?v=9lSzL1DqQn0

[toc] | [prev] | [standalone]

Back to top | Article view | pl.comp.programming

csiph-web