Temat: Interbase - limit dostępu do bazy danych

Daniel "wloochacz" Grabowski:

Michał Z.:

/ciach/

/ciach/

No, nie wiem. Może u Ciebie jest to standard, ale np. ja wolę nie używać procedur składowanych, jeżeli to nie absolutnie potrzebne.

Ale ja nigdzie nie napisałem, że tak robię. Przede wszystkim -
nic nie robię pod ten serwer. Swego czasu mieli jakieś dziwne
podejście do triggerów. Efekt był taki, że większość ludzi parła
do stored procedures. Znam parę firm, które tak właśnie mają
zaprojektowane systemy.
Dla mnie - ważne, żeby używać właściwych narzędzi.

Innymi słowy, aplikacja z bazą nie komunikuje się za pomocą tysięcy procedur (a więc praktyczna implementacja wzorca CRUD), tylko wykorzystuje model domeny. W samej definicji domeny, oczywiście może być wykorzystana procedura, ale nie jest to standard tak jak w CRUD. Raczej jestem za automatycznym generowaniem kodu SQL, który potem jest wykorzystywany.
Generalnie jest to praktyczna implementacja SQLMap, bardzo podobna do iBATIS.

To akurat zależy. Dla mnie - może być tak, może być owak. Każde
podejście ma plusy i minusy. Głównie zależy od wielkości systemu,
stylu pracy i od tego po której stronie interfejsu się znajdujesz.
Miałem przyjemność pracować po obu stronach i ciężko mi tak
jednoznacznie to traktować :) Dyskutowanie z kilkunastoma
programistami o tym, że coś jest do zrobienia przebiega o wiele
lepiej przed faktem - jak ratowanie sytuacji po fakcie. Tak to
przynajmniej widzę jako DBA. Warto mieć jakieś argumenty - a nie
patrzeć jak nowe zapytania rozwalają bazę... Z drugiej strony -
ktoś musi utrzymywać te procedury i to też kosztuje.

Dużo by pisać, dlaczego tak i co to daje, ale to zdecydowanie wykracza poza zakres tematu...

Od tematu to już chyba odjechaliśmy parę postów temu.

I oba
interfejsy (ADO, ODBC) dobrze sobie z tym radzą. Zostaje kwestia
drivera do bazy dla konkretnego interfejsu... Tak jak wyżej
pisałem. Działało, powinno działać dalej. Co do zagnieżdżania
transakcji... wiele baz to ma. Testowałem kiedyś dostęp z ADO
do Oracle'a. Wiele transakcji zagnieżdżonych - przy ręcznej
obsłudze transakcji po stronie klienta - śmigało elegancko.

O to chodzi, że to NIE są transakcje zagnieżdżone, tylko współbieżne; pracują równolegle i niezależnie od siebie, w tej samej sesji połączeniowej do bazy danych.
Tego nie da się zrobić za pomocą ADO, ponieważ tam kontrola transakcji jest dokonywana na poziomie obiektu Connection. A np. w takich IBX jest dedykowany obiekt IBTransaction, który odwzorowuje fizyczną transakcję w danym connection. I takich IBTransacion może być wiele w tym samym czasie w jednym Connection, niezależnych od siebie.

No ok. Prawdę mówiąc nigdy nie musiałem takich rzeczy robić.
Nie bardzo widzę zastosowanie dla takich równoległych transakcji
z jednej końcówki. Może jakieś dociąganie danych... no nie wiem.
Jak coś pisałem to i tak nawet dla wyszukiwania był założony
limit na 200 pozycji. Nikt nie dojeżdżał tak daleko. Jakoś
preferuję proste rozwiązania, a takie dociąganie w tle robię
tylko gdy nie da się inaczej. Dla systemu z lokalną bazą danych -
nie ma sensu. W dobie www, krótko żyjących sesji, chyba tym
bardziej.

/ciach/

No więc właśnie - nie dało się tego szybko poprawić, bo sama architektura ZEOSów jest krzywa. A na temat zarządzania pamięcią przez tą bibliotekę (alokacje i realokacje) krąży anegdota, jaki to wzorcowy przykład jak nie powinno się tego robić. W efekcie czego, sama wydajność biblioteki przy pobieraniu danych z serwera jest kilkakrotnie niższa niż mogłaby być w porównaniu np. do AnyDAC.
A o różnicach w funkcjonalności szkoda nawet pisać ;-)
No, ale jak coś jest za darmo (tak jak ZEOS), to nie należy krytykować tylko używać i cieszyć się, że jest.

Ja tam nie wiem o co Ci chodzi. Działało, miało się dobrze.
Nigdy nie potrzebowałem tym wyciągać hektarów danych na raz,
reallokować. Widzisz, taka normalna aplikacja OLTP... :)
Doimplementowałem jakieś cache i z tą mityczną reallokacją
też jakoś sobie poradziłem. Pewnie na wynikach po kilka tysięcy
wierszy - są różnice. Ale przy 100, 200... ginie w tłumie.
Być może mówimy o innej wersji, od paru lat na oczy nie
widziałem - ani delphi, ani zeosów. Chociaż z tego co pamiętam
dla Ciebie zeosy to było zło - zawsze. :)
Jak miałbym luksus poświęcenia jakiegoś tam czasu na wdrożenie,
może bym się zdecydował. Tyle, że zawsze jest coś do zrobienia,
i wytłumaczenie komuś, że teraz to my się pobawimy i wdrożymy
bibliotekę, która jest mniej "krzywa"... a im w tym czasie
kasa będzie uciekać. :)
Podsumowując. Tak, robiłem testy. Dla przeciętnego użytkownika
tego konkretnego systemu wdrożenie AnyDAC nie dałby zauważalnego
wzrostu wydajności. Koszty nie były zerowe, ryzyko też. I to
chyba tyle.

Ja używałem ZEOSów - tyle, że to było pod D7 parę lat temu...

I nic się nie zmieniło na plus - były paskudne i takie pozostały :P

:D
I co zrobić... Jeden woli ogórki, a drugi ogrodnika córki. :)

IMO to nie ma nic wspólnego z "woleniem" - bo jak mam rozumieć, że wolisz poruszać się starym fiatem zamiast nowym autem z Bawarii?

Oj, nie, ale wcale fanem nie jesteś... :P

Tak zupełnie na boku. Stary fiat ma tę zaletę, że jak jedziesz
na imprezę to zostawiasz go gdziekolwiek i się nie martwisz.
Tak, możesz jechać taksówką - jechałeś taksówką w Sylwestra? Ja
co roku mam problem, bo albo czekam na taryfę 30 minut, albo
jestem pod lokalem 30 za wcześnie. A tak - słuchaj - jedziesz
starym fiatem, niech z petard strzelają... nawet jak coś na niego
spadnie - różnicy nie zrobi ;) To tak bez związku z ZEOSami.

Temat: Interbase - limit dostępu do bazy danych

Michał Z.:

Daniel "wloochacz" Grabowski:

Michał Z.:

/ciach/

/ciach/

No, nie wiem. Może u Ciebie jest to standard, ale np. ja wolę nie używać procedur składowanych, jeżeli to nie absolutnie potrzebne.

Ale ja nigdzie nie napisałem, że tak robię.

No dobra, to Cię zacytuję:
"Niestandardową funkcjonalność zwykle można udostępnić przez
stored procedures. W MS SQL Serverze takie ukrywanie struktury
bazy i operowanie tylko na procedurach jest standardem."
I o to mi chodziło.

Przede wszystkim -
nic nie robię pod ten serwer.

Ale to jakby nie ma znaczenia w tym kontekście, prawda? Żeby było ciekawiej, ja też nic nie robię pod ten serwer, tylko utrzymuję ;-) Za to robiłem (raczej sporo) i jestem mniej więcej na bieżąco...

Swego czasu mieli jakieś dziwne
podejście do triggerów. Efekt był taki, że większość ludzi parła do stored procedures.

Kto miał dziwne podejście do triggerów? Twórcy FB? Bo się chyba pogubiłem...

Znam parę firm, które tak właśnie mają
zaprojektowane systemy.

Co nie znaczy, że to jest koszerne rozwiązanie. Chodzi mi o to, że jeżeli coś działa, nie jet automatycznie cud miód orzeszki - vel ZEOS ;-)

Dla mnie - ważne, żeby używać właściwych narzędzi.

A dla mnie, raczej to żeby używać właściwie narzędzi ;-)

Innymi słowy, aplikacja z bazą nie komunikuje się za pomocą tysięcy procedur (a więc praktyczna implementacja wzorca CRUD), tylko wykorzystuje model domeny. W samej definicji domeny, oczywiście może być wykorzystana procedura, ale nie jest to standard tak jak w CRUD. Raczej jestem za automatycznym generowaniem kodu SQL, który potem jest wykorzystywany.
Generalnie jest to praktyczna implementacja SQLMap, bardzo podobna do iBATIS.

To akurat zależy. Dla mnie - może być tak, może być owak. Każde podejście ma plusy i minusy.

Dla Ciebie, to znaczy dla kogo? Dla DBA, programisty, architekta? Masz napisane w profilu "programista", a z tego co piszesz wygląda na to, że teraz to raczej jesteś DBA :)

Głównie zależy od wielkości systemu,
stylu pracy i od tego po której stronie interfejsu się znajdujesz.
Miałem przyjemność pracować po obu stronach i ciężko mi tak
jednoznacznie to traktować :) Dyskutowanie z kilkunastoma
programistami o tym, że coś jest do zrobienia przebiega o wiele
lepiej przed faktem - jak ratowanie sytuacji po fakcie. Tak to
przynajmniej widzę jako DBA. Warto mieć jakieś argumenty - a nie
patrzeć jak nowe zapytania rozwalają bazę... Z drugiej strony -
ktoś musi utrzymywać te procedury i to też kosztuje.

Utrzymywanie procedur jest bardzo kosztowne. Ręczne klepanie i refaktoring procedur w bazie danych, która posiada ich kilkaset (powiedzmy ok. 500) to nie jest przyjemne i mało stresujące zadanie.
Dla mnie ważne jest aby aplikacja poprawnie rozmawiała z bazą danych - to warunek sine qua non. Po drugie, aby w miarę możliwości kod SQL generowany był automatycznie, a nie ręcznie. A po trzecie - abym miał pełną kontrolę nad tym automatem. Wiem, że to są sprzeczne wymagania, których nie da się spełnić bez kompromisów, ale w sumie jest naprawdę sporo wiedzy na ten temat (ORM, SQLMAp, ActiveRecord, LinqToSQL, itd., itp.).

Dużo by pisać, dlaczego tak i co to daje, ale to zdecydowanie wykracza poza zakres tematu...

Od tematu to już chyba odjechaliśmy parę postów temu.

No raczej ;-)

I oba
interfejsy (ADO, ODBC) dobrze sobie z tym radzą. Zostaje kwestia
drivera do bazy dla konkretnego interfejsu... Tak jak wyżej
pisałem. Działało, powinno działać dalej. Co do zagnieżdżania
transakcji... wiele baz to ma. Testowałem kiedyś dostęp z ADO
do Oracle'a. Wiele transakcji zagnieżdżonych - przy ręcznej
obsłudze transakcji po stronie klienta - śmigało elegancko.

O to chodzi, że to NIE są transakcje zagnieżdżone, tylko współbieżne; pracują równolegle i niezależnie od siebie, w tej samej sesji połączeniowej do bazy danych.
Tego nie da się zrobić za pomocą ADO, ponieważ tam kontrola transakcji jest dokonywana na poziomie obiektu Connection. A np. w takich IBX jest dedykowany obiekt IBTransaction, który odwzorowuje fizyczną transakcję w danym connection. I takich IBTransacion może być wiele w tym samym czasie w jednym Connection, niezależnych od siebie.

No ok. Prawdę mówiąc nigdy nie musiałem takich rzeczy robić.
Nie bardzo widzę zastosowanie dla takich równoległych transakcji z jednej końcówki.
Może jakieś dociąganie danych... no nie wiem.

Może inaczej. Jeżeli DAC, którego używasz w aplikacji nie wymaga aktywnej sesji (otwartej transakcji) do utrzymania danych - to faktycznie da się bez tego żyć. Ale w przeciwnym razie, jak zrobisz dostęp do danych w systemie, który nie otwiera formatek w sposób modalny? Kiedy użytkownik może sobie otworzyć np. n dokumentów, lub na raz edytować kilka faktur?
Oczywiście można to realizować np. tak że dane są zapisane do bazy danych dane z flagą "temporary", ale tego typu rozwiązania mają inne niebezpieczeństwa.
Można tez tworzyć n sesji - ale w takim serwerze jak FB nie ma analogicznego Connection Polling'u do np. MS SQL. A więc samo utrzymanie sesji jest dużo bardziej kosztowne dla serwera (widzisz - tu gadam jak DBA :P).

Jak coś pisałem to i tak nawet dla wyszukiwania był założony
limit na 200 pozycji. Nikt nie dojeżdżał tak daleko.

200 rekordów to przy współczesnych monitorach, ile? Dwa ekrany?
To nie za mało? :)

Jakoś
preferuję proste rozwiązania, a takie dociąganie w tle robię
tylko gdy nie da się inaczej. Dla systemu z lokalną bazą danych -
nie ma sensu.

No nie wiem, mamy też takie czasu że średni wolumen danych, dla systemu średniej firmy w jakiejś tam branży jest ile razy większy niż kilka lat temu?
Nie wiem ile, ale na pewno sporo.
A wszyscy chcą mieć już, teraz, natychmiast!
Poza tym, samo dociąganie danych wbrew pozorom nie jest czasochłonne (pod warunkiem, że "ssanie" podzielone jest na bloki i działa na żądanie), ale już np. uruchomieni jakiegoś tam zestawienia, które czesze bazę danych wszerz i wzdłuż - już tak. I tego typu rzeczy winny być robione w tle...

W dobie www, krótko żyjących sesji, chyba tym bardziej.

Przy prościutkich zapytaniach w trywialnych zastosowaniach - to oczywiście. Ale nie wszystkie zastosowania dla bazy danych są proste i szybkie, niestety...

/ciach/

No więc właśnie - nie dało się tego szybko poprawić, bo sama architektura ZEOSów jest krzywa. A na temat zarządzania pamięcią przez tą bibliotekę (alokacje i realokacje) krąży anegdota, jaki to wzorcowy przykład jak nie powinno się tego robić. W efekcie czego, sama wydajność biblioteki przy pobieraniu danych z serwera jest kilkakrotnie niższa niż mogłaby być w porównaniu np. do AnyDAC.
A o różnicach w funkcjonalności szkoda nawet pisać ;-)
No, ale jak coś jest za darmo (tak jak ZEOS), to nie należy krytykować tylko używać i cieszyć się, że jest.

Ja tam nie wiem o co Ci chodzi.

Widać :)

Działało, miało się dobrze.

A tak z ciekawości - sprawdziłeś kiedykolwiek taką aplikację pod kątem wycieków pamięci?
Albo może napisałeś usługę, która działa sobie długo i non stop, a w środku używa ZEOSów?

Nigdy nie potrzebowałem tym wyciągać hektarów danych na raz,
reallokować. Widzisz, taka normalna aplikacja OLTP... :)
Doimplementowałem jakieś cache i z tą mityczną reallokacją
też jakoś sobie poradziłem. Pewnie na wynikach po kilka tysięcy
wierszy - są różnice. Ale przy 100, 200... ginie w tłumie.
Być może mówimy o innej wersji, od paru lat na oczy nie
widziałem - ani delphi, ani zeosów. Chociaż z tego co pamiętam
dla Ciebie zeosy to było zło - zawsze. :)

Bo to strasznie prymitywna biblioteka jest i do tego źle napisana.
No, ale działa - na to nie mam argumentów :D

Jak miałbym luksus poświęcenia jakiegoś tam czasu na wdrożenie,
może bym się zdecydował. Tyle, że zawsze jest coś do zrobienia,
i wytłumaczenie komuś, że teraz to my się pobawimy i wdrożymy
bibliotekę, która jest mniej "krzywa"... a im w tym czasie
kasa będzie uciekać. :)

Eee... tam; tego typu argumenty do mnie nie docierają. Co to znaczy - nie mam czasu na to żeby zrobić lepiej? Jak mam to rozumieć - pracujecie tak aby jakoś działało, poszło do klienta i były z tego profity? Jak rozumiem nie utrzymujecie takiego systemu przez lata - bo gdyby tak było, to same późniejsze poprawki zjadłyby cały zysk. No chyba, że za każde kiwnięcie palcem klient płaci - to szacun :)

Podsumowując. Tak, robiłem testy. Dla przeciętnego użytkownika
tego konkretnego systemu wdrożenie AnyDAC nie dałby zauważalnego
wzrostu wydajności. Koszty nie były zerowe, ryzyko też. I to
chyba tyle.

OK.
Sam DAC, taki czy inny, faktycznie może nie da realnej przewagi przy prostym systemie (pobierz, wyświetl, zaktualizuj).

Ja używałem ZEOSów - tyle, że to było pod D7 parę lat temu...

I nic się nie zmieniło na plus - były paskudne i takie pozostały :P

:D
I co zrobić... Jeden woli ogórki, a drugi ogrodnika córki. :)

IMO to nie ma nic wspólnego z "woleniem" - bo jak mam rozumieć, że wolisz poruszać się starym fiatem zamiast nowym autem z Bawarii?

Oj, nie, ale wcale fanem nie jesteś... :P

Nie, jestem po prostu obiektywny.
Swego czasu mocno dyskutowałem z Bogdanem Polakiem nad różnicami i udowadniałem mu przewagę AnyDAC'a nad dbExpress w wersji 4 (czyli najnowszej).
W końcu wyszło na to, że dbExpress jest dobry bo... jest w pakiecie razem z IDE :P

Tak zupełnie na boku. Stary fiat ma tę zaletę, że jak jedziesz
na imprezę to zostawiasz go gdziekolwiek i się nie martwisz.
Tak, możesz jechać taksówką - jechałeś taksówką w Sylwestra? Ja
co roku mam problem, bo albo czekam na taryfę 30 minut, albo
jestem pod lokalem 30 za wcześnie. A tak - słuchaj - jedziesz
starym fiatem, niech z petard strzelają... nawet jak coś na niego
spadnie - różnicy nie zrobi ;)

Naprawdę mam uwierzyć, że specjalnie na takie okazje masz w swoim garaży starego fiata?

To tak bez związku z ZEOSami.

Oczywiście :)

Temat: Interbase - limit dostępu do bazy danych

[...]
nie zauważyłeś ';)'?

- np. Firebird poniżej wersji 2.1 miał bardzo mało wbudowanych funkcji.

[...]

Oczywiście wiesz jak działają UDFy w Firebird?

Tylko to nie jest w standardzie. To, że dla Ciebie jest wystarczające, nie znaczy, że dla innych też. Poza tym nie zawsze masz możliwość zmiany konfiguracji bazy czy dostęp do kodów programu i musisz użyć tego co jest zadane.

Temat: Interbase - limit dostępu do bazy danych

W sumie to odpowiem...
Co do procedur składowanych i standardowości tego rozwiązania. Zaczęło się od tego, że chciałem pokazać, że za równo na DAO, jaki na ODBC to działa. Tu jak rozumiem się zgadzamy. Byłem na studiach podyplomowych na SGH, partnerem technologicznym jest Microsoft. Skoro certyfikowany trener mówi, że to jest standard - to raczej jemu wierzę. W Visual Studio są wizardy do generowania CRUDa właśnie na procedurach. Byłem na paru rozmowach o pracę w firmach, które stosowały takie właśnie rozwiązanie. Z tych powodów pozwoliłem sobie nazwać je standardowym.
Dla mnie jako DBA - to jest dodatkowa warstwa, separująca bazę danych. Jeżeli mam odpowiednie narzędzia - debug, testy. Nie widzę jakichś specjalnych problemów. A VS takie narzędzia daje. No, w każdym razie, na tych studiach sobie poklikałem i działało. Może być tak jak z wizardem do modułów danych w Delphi, który był używany tylko na prezentacjach, ale skoro duże firmy używają. No to coś w tym jest. IMVHO - oczywiście.
Kolejna sprawa - triggery. Chodziło o MS SQL Server. Pisałem, że tak je zrobili, że wszyscy walą procedurę, bo tak prościej. Może kwestia wydajności, albo bezpieczeństwo jakoś tu wpływają. Jakoś nie rozumiem ich koncepcji - wolę :old / :new. Zamiast jakichś wynalazków. I to miałem na myśli, że triggery są

Co do ZEOS vs. AnyDAC. Z Tobą jest tak, że ogólnie idzie pogadać, ale temat AnyDAC trzeba trzymać daleko. Ciekawiło mnie, czy coś się zmieniło... :D
Jak chcesz kogoś przekonać do swoich racji to napadanie na rozwiązanie, które stosuje to słaby pomysł. Każdy developer czuje się jakoś tam związany z tym co stworzył. Mnie tam gila, bo mam ten etap za sobą. Jak miałbym kupić coś to wolałbym czuć się doceniony. A nie traktowany jak facet z Fiata, który rozmawia z właścicielem BMW. To się jakoś śmiesznie rozwijało - Bolid Młodzieży Wiejskiej, czy jakoś tak. ;)

Co do Fiata i Sylwestra. Odpowiedź brzmi nie - Lanosa. :D

EOT.

Temat: Interbase - limit dostępu do bazy danych

Daniel "wloochacz" Grabowski:

Wojciech B.:
Ja testowałem IBDAC, głównie z powodu szybkości działania: http://www.devart.com/ibdac/. Rzeczywiście czuje się tę prędkość. Fakt, że na małej bazie...

Nigdy, ale to NIGDY nie testuj swojej aplikacji na bazie danych, która nie ma danych. To tak jakby testować karabin bez oddania żadnego strzału, tego typu zachowania to strzał w stopę - własną ;-)

Tak dla ścisłości: Fakt. Nie robiłem testów obciążeniowych, ale funkcjonalne.
Chciałem zobaczyć czy teoretycznie szybkie komponenty IBDAC są "przyjazne" dla programisty, intuicyjne itp. I zostałem mile zaskoczony faktem, że raczej są. Dopiero teraz to doceniam, gdy próbuję analogicznie zastosować komponenty SQLDirect i jakieś to takie "nieprzyjazne". Drobiazgi, które powodują, że aplikacja działa siermiężnie, bez polotu.Wojciech B. edytował(a) ten post dnia 10.07.10 o godzinie 10:39

Temat: Interbase - limit dostępu do bazy danych

Michał Z.:
W sumie to odpowiem...
Co do procedur składowanych i standardowości tego rozwiązania. Zaczęło się od tego, że chciałem pokazać, że za równo na DAO, jaki na ODBC to działa. Tu jak rozumiem się zgadzamy. Byłem na studiach podyplomowych na SGH, partnerem technologicznym jest Microsoft. Skoro certyfikowany trener mówi, że to jest standard - to raczej jemu wierzę.

Różnimy się - ja z definicji nikomu nie wierzę i nie ma dla mnie znaczenia, czy ktoś jest trenerem czy nie. Jeżeli ów trener przy okazji jest również MVP, to znaczenie lepiej - ale i tak wolę sam sprawdzić ;-)

W Visual Studio są wizardy do generowania CRUDa właśnie na procedurach.

Co wcale nie znaczy, że to dobre rozwiązanie...
Ani wizard ani CRUD :D
OK - odbiegliśmy od tematu i to znacznie.
IMHO - procedury mają dwie poważne wady,

Byłem na paru rozmowach o pracę w firmach, które stosowały takie właśnie rozwiązanie. Z tych powodów pozwoliłem sobie nazwać je standardowym.

Jak wyżej... widziałem trochę oprogramowania i różnych rozwiązań w firmach - powiem tak: czasem firma robi taką kupę, że to cud iż to w ogóle działa. Czasem ich kupa działa stabilnie, ale strasznie wolno, bo jest napisana wg "standardów" (mogę podać konkretny przykład jak kogoś interesuje, ale na publicznej grupie nie będę wymieniał nazwy firmy :)).
Chodzi mi o to, że rozwiązanie trzeba dobierać do problemu, a nie zasłaniać się jakimkolwiek standardem i wierzyć iż tak będzie dobrze.
To bzdura!

Dla mnie jako DBA - to jest dodatkowa warstwa, separująca bazę danych. Jeżeli mam odpowiednie narzędzia - debug, testy. Nie widzę jakichś specjalnych problemów. A VS takie narzędzia daje. No, w każdym razie, na tych studiach sobie poklikałem i działało. Może być tak jak z wizardem do modułów danych w Delphi, który był używany tylko na prezentacjach, ale skoro duże firmy używają. No to coś w tym jest.

Lenistwo?
Brak kreatywności?
Bo to jest "standard"?
Oczywiście nie wszystkie duże firmy tak działają, ale znaczna część niestety tak jak opisałeś.

IMVHO - oczywiście.
Kolejna sprawa - triggery. Chodziło o MS SQL Server. Pisałem, że tak je zrobili, że wszyscy walą procedurę, bo tak prościej. Może kwestia wydajności, albo bezpieczeństwo jakoś tu wpływają. Jakoś nie rozumiem ich koncepcji - wolę :old / :new. Zamiast jakichś wynalazków.

Wynalazki w sensie tabel inserted/deleted?
I mnie to też mocno przeszkadzało, ale przyzwyczaiłem się.
Poza tym każdy SZBD jest przeznaczony do operacji na zbiorach, takie rozwiązanie to umożliwia w przeciwieństwie do OLD/NEW :)
Oczywiście OLD/NEW jest wygodniejsze do oprogramowanie i zdecydowanie prostsze do debugu, no i pewnie w większości aplikacji OLTP zmienia się pojedyncze wiersze ;-)

I to miałem na myśli, że triggery są

Co do ZEOS vs. AnyDAC. Z Tobą jest tak, że ogólnie idzie pogadać, ale temat AnyDAC trzeba trzymać daleko.

Aj tam :)

Ciekawiło mnie, czy coś się zmieniło... :D
Jak chcesz kogoś przekonać do swoich racji to napadanie na rozwiązanie, które stosuje to słaby pomysł.

Nie napadam.
Nie mam zamiaru nikogo do niczego nie przekonywać - ja po prostu przedtsawiam suche fakty, które miażdżą w tym wypadku ZEOSA.
Jak Twoim kontrargumentem jest "używałem i działało" to przepraszam...

Każdy developer czuje się jakoś tam związany z tym co stworzył. Mnie tam gila, bo mam ten etap za sobą. Jak miałbym kupić coś to wolałbym czuć się doceniony. A nie traktowany jak facet z Fiata, który rozmawia z właścicielem BMW. To się jakoś śmiesznie rozwijało - Bolid Młodzieży Wiejskiej, czy jakoś tak. ;)

Aj tam.
Bumka fajna fura.
A że ma złe konotacje, cóż... ;-)

Co do Fiata i Sylwestra. Odpowiedź brzmi nie - Lanosa. :D

EOT.

Pozdrówka!