🚀 go-pugleaf

> 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

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

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

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

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.

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

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

> 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

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

> 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?!?

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

> 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

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

Dzięki za opinię.