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

do góry

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

do góry

> 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

do góry

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

do góry

Dzięki za opinię.

do góry