🚀 go-pugleaf

W dniu środa, 15 maja 2019 17:34:12 UTC+2 użytkownik zpksoft napisał:
> W dniu środa, 15 maja 2019 17:23:16 UTC+2 użytkownik Krzysztof Szyszka napisał:
> > > To czy i jakie pojęcie mam to nie do Twojej oceny bo Twoja wiedza na temat mojej wiedzy jest
> > > żadna. Takie kontrolki musisz zbindować ze źródłem danych. I o to mi chodziło.
> > > Jeżeli źródło danych ma krótkie życie i jest powiązane z danymi w sposób określany dynamicznie to
> > > tworzenie tych powiązań w kodzie to właśnie dla mnie drutowanie. Ale to już dyskusja akademicka.
> > 
> > Ty nadal nie wiesz, co to jest kontrolka dbaware :-) Zrozum wreszcie, że dbaware oznacza kontrolkę
> > sterowaną przez źródło danych (property DataSource), czyli to baza danych, a konkretnie to jedna
> > kontrolka DAC (np. TFDQuery), która łączy się z bazą danych, steruje wszystkimi kontrolkami
> > wizualnymi podłączonymi do wspólnego źródła danych, a kontrolki dbaware z automatu obsługują
> > wszystkie zdarzenia, jakie generuje źródło danych: Insert, Delete, Edit, Post, Cancel i to bez
> > pisania żadnego kodu, a Ty tu wyjeżdżasz z druciarstwem i krótkim życiem źródła danych.
> > 
> > Jest nawet DBNavigator, który pozwala użytkownikowi tworzyć te zdarzenia wizualnie na formatce,
> > więc nawet nie potrzeba żadnych dodatkowych buttonów do zapisania zmian wprowadzonych przez
> > użytkownika do bazy danych, a jeśli źródło danych może pracować w trybie "cached updates",
> > to masz również do dyspozycji przyciski ApplyUpdates i CancelUpdates, ale dla Ciebie to jest
> > druciarstwo, bo wymaga podłączenia jednego DataSource, zamiast pisania zajebistego kodu.
> > Zastanów się czasem co piszesz, albo nie pisz wcale, jak czegoś nie znasz lub nie rozumiesz :-)
> > 
> > > Dawno temu doszedłem do wniosku, ze kontrolki dbaware są może i sprytne ale do prostych
> > > zastosowań.
> > 
> > Tak informacyjnie, mój X-DBGrid to też kontrolka dbaware, ale tylko do prostych zastosowań,
> > bo do pełnej funkcjonalności Excela jeszcze jej trochę brakuje ;-)
> > 
> > -- 
> > pozdrowienia
> > Krzysztof Szyszka, X-Files Software
> > Developer of X-DBGrid Component
> > Embarcadero Technology Partner
> > http://www.x-files.pl/
> 
> Wymądrzasz się i krytykujesz.
> Ale odpowiem bo widzę że Ty nie rozumiesz. Tylko w prostych przypadkach masz w gridzie widok jednej tabeli. Zwykle jest to widok różnych pól z różnych tabel. I jak tu zrobić automatyczny insert/delete? Na czym? (możesz nie odpowiadać)
> 
> Paweł

No i?

Większość sensownych komponentów dostępowych do baz ma możliwość łączenia widoku i robienia insert/update na wielu tabelach. 

Pomijam sensowność grzebania "bezpośrednio" na tabelach, chyba że nie używasz do tego żadnego serwera bazodanowego lub sprowadzasz go jedynie do roli przechowywania danych.
W większych projektach istotnym jest rozdzielenie fizycznej struktury bazy danych (tabel) od tego co możemy wyświetlić (widoki) oraz dodawać/zmieniać (procedury). Daje to nam niezależność widoku od struktury która może się zmieniać, i nie każda zmiana w strukturze pociąga od razu zmianę kodu aplikacji.

Poza tym (trochę odbiegając od wątku) takie tworzenie SQLa jak pokazałeś powyżej to jest "drutowanie" najwyższej klasy. Ogólnie - takie wymaganie (generowania SQLa wg parametrów) to norma, ale na litość opakuj to w jakiś SQL generator. Raz napisany i przetestowany pozwoli unikać błędów i problemów w przyszłości. IMHO to jeden z pierwszych elementów które trzeba ogarnąć gdy odchodzi się od klikanego programowania...

pozdrawiam,
Przemek O.