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

do góry

> 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

do góry

>> * 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...

do góry

> >> * 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

do góry

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

do góry

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.

do góry

In pl.comp.programming Szyk Cech <s...@s...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

do góry

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

do góry

> 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

do góry

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...

do góry