Discussion:
Logika - co w bazie, a co w aplikacji?
(Wiadomość utworzona zbyt dawno temu. Odpowiedź niemożliwa.)
jh
2008-09-23 21:53:36 UTC
Permalink
Firebird 2.1, Delphi 2007 Pro

Mam pytanie do tych, co to więcej ode mnie potrafią i zechcieliby się
podzielić wiedzą. Pracując nad większym (jak na jednego developera)
projektem, gdybam, gdzie lepiej zaszyć logikę biznesową: co po stronie
aplikacji, a co w bazie i gdzie. Dwa przykłady:

1.
Chcę mieć minimalną długość łańcucha w określonym polu. Mogę więc dać check
dla pola, który korzysta z wbudowanej funkcji CHAR_LENGTH. Przy naruszeniu
zasady baza wyrzuca mi wyjątek z własnym anglojęzycznym komunikatem, który z
warunków został naruszony. Mogę wsadzić to sprawdzanie do triggera before
insert/update i po sprawdzeniu długości wywołać wyjątek, który może już
zawierać mój, zdefiniowany w bazie tekst (EXCEPTION). W aplikacji mogę
oczywiście przechwycić ten wyjątek i tam nadać mu odpowiednią treść.
Zakładając, że jedyną dostępową aplikacją będzie moja (Win32) mogę w
zasadzie przenieść tego typu zasady właśnie do aplikacji. Ale jeśli
chciałbym dorobić front-end webowy, to teoretycznie pozostawienie tej
obsługi w bazie da mi niezależność od tejże aplikacji. Piszę -
teoretycznie - bo, aż takiego doświadczenia nie mam i pewnie wielu rzeczy
nie przewidzę.

2.
Mam wlasny sposób logowania userów. W bazie użytkowników serwera
(security2.fdb) przewiduje trzech userów, każdy związany z różnymi
aplikacjami dostępowymi - user typu system dla narzędzi backupowych itp.,
admin i "zwykły" user, czyli dla normalnej pracy z bazą. W bazie mam obsługę
użytkowników zdefiniowaną jako tabele z loginami etc. Czyli użytkownicy
serwera to de facto konta dla aplikacji, a aplikacje mogą wywoływać
dodatkowy proces logowania na użytkownika bazy. To logowanie mam powiązane z
triggerami dla całej bazy, więc mam sesje i w ramach sesji logowania
użytkowników, co jest niezbędne dla wymogów systemu. I sedno sprawy: po
zalogowaniu aplikacji do serwera jako "zwykły user", użytkownik przed
dokonywaniem jakichkolwiek operacji powinien się zalogować na swoje konto.
No i tu podobne pytanie: czy lepiej to realizować po stronie aplikacji
(prościej blokować operacje, jeżeli user nie zalogował się) czy też
właściwie w każdym triggerze dla tabel i w procedurach dawać sprawdzanie,
czy użytkownik jest zalogowany. To drugie w pewnym sensie obliguje moje
"zalogowanie się", kiedy ktoś (np. lokalny admin systemu) chciałby na szybko
dokonać zmian bezpośrednio podłączając się do serwera chociażby IBExpertem
czy podobnym narzędziem. Oczywiście zabezpieczenie żadne, ale upierdliwe ;)

Dotąd, w prostych projektach wystarczyło (i było szybsze w implementacji)
zaszywać taką logikę w aplikacji. Ale po niedawnym kontakcie z dosyć dużym
systemem opartym na Oracle'u dowiedziałem się, że w zasadzie w bazie jest
zaszyta cała funkcjonalność aplikacji klienta, począwszy od nazw funkcji,
menu, przez całą logikę do wyglądu formatek i niemalże działania tejże
aplikacji. No i tak zastanawiam się, gdzie powinna leżeć ta granica podziału
logiki w aplikacji dwuwarstwowej między RDBMS a programem klienckim?

jh
b0bik
2008-09-24 06:35:39 UTC
Permalink
Post by jh
Firebird 2.1, Delphi 2007 Pro
1.
Chc� mie� minimaln� d�ugo�� �a�cucha w okre�lonym polu. Mog� wi�c da� check
dla pola, kt�ry korzysta z wbudowanej funkcji CHAR_LENGTH. Przy naruszeniu
zasady baza wyrzuca mi wyj�tek z w�asnym angloj�zycznym komunikatem, kt�ry z
warunk�w zosta� naruszony. Mog� wsadzi� to sprawdzanie do triggera before
insert/update i po sprawdzeniu d�ugo�ci wywo�a� wyj�tek, kt�ry mo�e ju�
zawiera� m�j, zdefiniowany w bazie tekst (EXCEPTION). W aplikacji mog�
oczywi�cie przechwyci� ten wyj�tek i tam nada� mu odpowiedni� tre��.
Zak�adaj�c, �e jedyn� dost�pow� aplikacj� b�dzie moja (Win32) mog� w
zasadzie przenie�� tego typu zasady w�a�nie do aplikacji. Ale je�li
chcia�bym dorobi� front-end webowy, to teoretycznie pozostawienie tej
obs�ugi w bazie da mi niezale�no�� od tej�e aplikacji. Pisz� -
teoretycznie - bo, a� takiego do�wiadczenia nie mam i pewnie wielu rzeczy
nie przewidz�.
Kiedyś Kazik śpiewał "... stawiam pytania, na pytania odpowiadam ...".
Jeśli będzie więcej front-endów, to wybierając opcję po stronie
aplikacji, trzeba to będzie mieć w dwóch miejscach - więc odpowiedź na
pytanie ile ich będzie jest istotna (fat czy thin client). Weź też pod
uwagę, że OK długość pola tekstowego sprawdzić łatwo, ale co z
bardziej wyfarinowanymi kontrolami, lub takimi które muszą uwzględniać
szereg innych czynników (może nawet nie zawsze związanych z DB ?).
Widziałem też kilka systemów, w których spora część logiki jest
wsadzona do bazy, i zazwyczaj potwierdzało się w tych przypadkach
jedno - baza musi działać na całkiem niezłym sprzęcie, a najlepiej na
dedykowanym serwerze. Czasem stosuje się też rozwiazanie pośrednie,
wstępna walidacja (w zasadzie to co można) po stronie klienta,
bardziej upierdliwe rzeczy, po stronie bazy (trigger, sp - cokolwiek).
Zresztą tego typu rzeczy możesz sobie zrobić bardzo uniwersalnie
(delphi to powerfull device, a webowe front-endy hmm, kiedyś oddawałem
się lekturze dotyczącej PHP'a - za pomocą MVC można również zrobić
proste i łatwe w utrzymaniu walidatory) - utrzymanie tej wstępnej
warstwy logiki nie będzie wówczas takie uperdliwie.
Post by jh
2.
Mam wlasny spos�b logowania user�w. W bazie u�ytkownik�w serwera
(security2.fdb) przewiduje trzech user�w, ka�dy zwi�zany z r�nymi
aplikacjami dost�powymi - user typu system dla narz�dzi backupowych itp.,
admin i "zwyk�y" user, czyli dla normalnej pracy z baz�. W bazie mam obs�ug�
u�ytkownik�w zdefiniowan� jako tabele z loginami etc. Czyli u�ytkownicy
serwera to de facto konta dla aplikacji, a aplikacje mog� wywo�ywa�
dodatkowy proces logowania na u�ytkownika bazy. To logowanie mam powi�zane z
triggerami dla ca�ej bazy, wi�c mam sesje i w ramach sesji logowania
u�ytkownik�w, co jest niezb�dne dla wymog�w systemu. I sedno sprawy: po
zalogowaniu aplikacji do serwera jako "zwyk�y user", u�ytkownik przed
dokonywaniem jakichkolwiek operacji powinien si� zalogowa� na swoje konto.
No i tu podobne pytanie: czy lepiej to realizowa� po stronie aplikacji
(pro�ciej blokowa� operacje, je�eli user nie zalogowa� si�) czy te�
w�a�ciwie w ka�dym triggerze dla tabel i w procedurach dawa� sprawdzanie,
czy u�ytkownik jest zalogowany. To drugie w pewnym sensie obliguje moje
"zalogowanie si�", kiedy kto� (np. lokalny admin systemu) chcia�by na szybko
dokona� zmian bezpo�rednio pod��czaj�c si� do serwera chocia�by IBExpertem
czy podobnym narz�dziem. Oczywi�cie zabezpieczenie �adne, ale upierdliwe ;)
Pamiętaj, że także i Ty tą upierdliwść będziesz musiał znosić przy
serwisowaniu/utrzymaniu aplikacji. Skoro zabezpieczenie jest żadne, to
już bym wolał zostać przy żadnym zabezpieczeniu pod tytułem "zmiana
hasła na sysdba".


b
zpk
2008-09-24 07:49:00 UTC
Permalink
1.
Chcę mieć minimalną długość łańcucha w określonym polu. Mogę więc...
Jeżeli w bazie nie masz kontroli wersji aplikacji która z nią się
łączy, logika musi być po stronie bazy (nowa wersja app może nieść za
sobą inną wartość łańcucha niż dozwolony, nie przeinstalowana na
wszystkich kompach i masz błędy).
Proponuję dla takiego przypadku zastosować w zasadzie oba rozwiązania,
bo:
- jeżeli ktoś grzebnie w bazie za pomocą konsoli to ograniczenia
zaszyte w bazie nie pozwolą mu na popełnienie błedu <- logika wymagana
w bazie
- zwykle jeżeli commit się nie powiedzie, automatycznie dajemy
rollback. Przy złożonych zmianach na bazie daje to niepotrzebną
korespondencję info o błedach, lepiej nie dopuścić w programie do
dokonania błednego wpisu np. w edicie. <- logika w app

Wspomniałeś o menu przechowywanym w bazie Oracle itp.
Ja także przechowuję elementy konfiguracyjne w bazie, ale tylko te,
które dotyczą wszystkich (np. uprawnienia). Zwykle lokalnie
przechowuję takie info, jak ostatnio otwierany dokument przez usera,
aby miał do niego szybszy dostęp przy kolejnyum logowaniu (tym nie ma
co zaśmiecać bazy)

Pozdrawiam- Paweł Krzyżanowski
wloochacz
2008-09-24 08:43:56 UTC
Permalink
Post by jh
Firebird 2.1, Delphi 2007 Pro
Mam pytanie do tych, co to więcej ode mnie potrafią i zechcieliby się
podzielić wiedzą. Pracując nad większym (jak na jednego developera)
projektem, gdybam, gdzie lepiej zaszyć logikę biznesową: co po stronie
1.
Chcę mieć minimalną długość łańcucha w określonym polu. Mogę więc dać
check dla pola, który korzysta z wbudowanej funkcji CHAR_LENGTH. Przy
naruszeniu zasady baza wyrzuca mi wyjątek z własnym anglojęzycznym
komunikatem, który z warunków został naruszony. Mogę wsadzić to
sprawdzanie do triggera before insert/update i po sprawdzeniu długości
wywołać wyjątek, który może już zawierać mój, zdefiniowany w bazie tekst
(EXCEPTION). W aplikacji mogę oczywiście przechwycić ten wyjątek i tam
nadać mu odpowiednią treść. Zakładając, że jedyną dostępową aplikacją
będzie moja (Win32) mogę w zasadzie przenieść tego typu zasady właśnie
do aplikacji. Ale jeśli chciałbym dorobić front-end webowy, to
teoretycznie pozostawienie tej obsługi w bazie da mi niezależność od
tejże aplikacji. Piszę - teoretycznie - bo, aż takiego doświadczenia nie
mam i pewnie wielu rzeczy nie przewidzę.
W aplikacji.
Ma znaczenie czy w aplikacji czy na serwerze aplikacyjnym :)
Jeśli chcesz nieć jedną logikę i niezależność od front-endu - tu kłania
się SOA.
Jeśli nie za bardzo wiesz o czym piszę, to prawdopodobnie nigdy nie
będzie Ci to potrzebne, więc szkoda na to czasu na obecnym etapie tego
projektu.
Post by jh
2.
Mam wlasny sposób logowania userów. W bazie użytkowników serwera
(security2.fdb) przewiduje trzech userów, każdy związany z różnymi
aplikacjami dostępowymi - user typu system dla narzędzi backupowych
itp., admin i "zwykły" user, czyli dla normalnej pracy z bazą. W bazie
mam obsługę użytkowników zdefiniowaną jako tabele z loginami etc. Czyli
użytkownicy serwera to de facto konta dla aplikacji, a aplikacje mogą
wywoływać dodatkowy proces logowania na użytkownika bazy. To logowanie
mam powiązane z triggerami dla całej bazy, więc mam sesje i w ramach
sesji logowania użytkowników, co jest niezbędne dla wymogów systemu. I
sedno sprawy: po zalogowaniu aplikacji do serwera jako "zwykły user",
użytkownik przed dokonywaniem jakichkolwiek operacji powinien się
zalogować na swoje konto. No i tu podobne pytanie: czy lepiej to
realizować po stronie aplikacji (prościej blokować operacje, jeżeli user
nie zalogował się) czy też właściwie w każdym triggerze dla tabel i w
procedurach dawać sprawdzanie, czy użytkownik jest zalogowany. To drugie
w pewnym sensie obliguje moje "zalogowanie się", kiedy ktoś (np. lokalny
admin systemu) chciałby na szybko dokonać zmian bezpośrednio podłączając
się do serwera chociażby IBExpertem czy podobnym narzędziem. Oczywiście
zabezpieczenie żadne, ale upierdliwe ;)
IMO szkoda prądu na takie pomysły.
Jeśli potrzebujesz bezpiecznej bazy danych, to użyj takiej które oferuje
wymaganą funkcjonalność.
Post by jh
Dotąd, w prostych projektach wystarczyło (i było szybsze w
implementacji) zaszywać taką logikę w aplikacji. Ale po niedawnym
kontakcie z dosyć dużym systemem opartym na Oracle'u dowiedziałem się,
że w zasadzie w bazie jest zaszyta cała funkcjonalność aplikacji
klienta, począwszy od nazw funkcji, menu, przez całą logikę do wyglądu
formatek i niemalże działania tejże aplikacji. No i tak zastanawiam się,
gdzie powinna leżeć ta granica podziału logiki w aplikacji dwuwarstwowej
między RDBMS a programem klienckim?
Taaak... a ja miałem i mam do czynienie z pewnym dużym systemem, który
robi coś takiego:
select top 25 CHEKBKID,
DSCRIPTN,
BANKID,
CURNCYID,
ACTINDX,
BNKACTNM,
NXTCHNUM,
Next_Deposit_Number,
INACTIVE,
DYDEPCLR,
XCDMCHPW,
MXCHDLR,
DUPCHNUM,
OVCHNUM1,
LOCATNID,
NOTEINDX,
CMUSRDF1,
CMUSRDF2,
Last_Reconciled_Date,
Last_Reconciled_Balance,
CURRBLNC,
CREATDDT,
MODIFDT,
Recond,
Reconcile_In_Progress,
Deposit_In_Progress,
CHBKPSWD,
CURNCYPD,
CRNCYRCD,
ADPVADLR,
ADPVAPWD,
DYCHTCLR,
CMPANYID,
CHKBKTYP,
DDACTNUM,
DDINDNAM,
DDTRANS,
PaymentRateTypeID,
DepositRateTypeID,
DEX_ROW_ID
from BOX.dbo.CM00100 with (NOLOCK)
where CHEKBKID = 'ID_ KASY'
order by CHEKBKID asc

Gdzie pole CHEKBKID jest PK, więc po co mu ten order by? O TOP nie
wspomnę w ogóle...
Gdzie z tego zestawu potrzebne jest są mu dwie kolumny...

Co do "Twojego" systemu, to zadam pytanie pomocnicze - w czym jest
napisany ów system? Oracle Forms a może Magic? Jeśli tak - tam jest
zupełnie inna filozofia pisania aplikacji i implementacja takich
rozwiązań w Delphi nie ma większego sensu, bo Twoje IDE (Delphi/BDS) w
niczym Ci nie pomoże.

Aczkolwiek, niektóre pomysły są atrakcyjne vel Application Dictionary;
więcej tu:
http://dn.codegear.com/article/33887
--
wloochacz
jh
2008-09-24 09:41:06 UTC
Permalink
Post by wloochacz
Chcę mieć minimalną długość łańcucha w określonym polu. [...]
W aplikacji.
Ma znaczenie czy w aplikacji czy na serwerze aplikacyjnym :)
Czyli, jeśli dobrze zrozumiałem lepiej w bazie trzymać te ustawienia (np.
ograniczenia, check itd.), zaczytać je przy starcie aplikacji i w niej
kontrolować dane przy wprowadzaniu. To w odniesieniu też do postu bObika oznacza
przeniesienie obciążenia serwera, na którym stoi baza na rzecz końcówek
klientów.
Post by wloochacz
Jeśli chcesz nieć jedną logikę i niezależność od front-endu - tu kłania się
SOA.
Jeśli nie za bardzo wiesz o czym piszę, to prawdopodobnie nigdy nie będzie Ci
to potrzebne, więc szkoda na to czasu na obecnym etapie tego projektu.
Masz rację. Terminologię wygoogle'ać nietrudno, więc nie będę się wymądrzał, że
wiem jak tego użyć. Po prostu nie umiałbym napisać takich rzeczy.
Post by wloochacz
Mam wlasny sposób logowania userów [..]
IMO szkoda prądu na takie pomysły.
Zaraz zaraz, pomysł pochodzi od jednego z Twoich postów na tejże grupie ;)
Chodzi oczywiście o samo logowanie.
Post by wloochacz
Jeśli potrzebujesz bezpiecznej bazy danych, to użyj takiej które oferuje
wymaganą funkcjonalność.
Masz 100% rację, tylko jak się ktoś do czegoś przyzwyczai to ma opory przed
zmianami ;) Zaczynałem od Firebirda i choć po drodze otarłem się o Accessa, MS
SQL, to pozostałem przy FB, za sugestiami (między innymi Twoimi :D) zanabyłem
FIBPlusy, IBExperta i ciężko mi się oderwać od tych narzędzi. IBExpert jest dla
mnie wręcz idealnym narzędziem (database diesigner, choć nieco siermiężny,
dokumentowanie w html itd. są na porządku dziennym). Jak sobie pomyślę, że
FreeMind jest również z Twojego polecenia to robi się niezpiecznie, bo wychodzi
na to, że masz za duży wpływ na mnie :D
Post by wloochacz
Aczkolwiek, niektóre pomysły są atrakcyjne vel Application Dictionary; więcej
http://dn.codegear.com/article/33887
Muszę jeszcze sporo doczytać, jak widać ;)

Dzięki wszystkim.

jh
wloochacz
2008-09-24 09:58:28 UTC
Permalink
Post by jh
Post by wloochacz
Chcę mieć minimalną długość łańcucha w określonym polu. [...]
W aplikacji.
Ma znaczenie czy w aplikacji czy na serwerze aplikacyjnym :)
Czyli, jeśli dobrze zrozumiałem lepiej w bazie trzymać te ustawienia
(np. ograniczenia, check itd.), zaczytać je przy starcie aplikacji i w
niej kontrolować dane przy wprowadzaniu. To w odniesieniu też do postu
bObika oznacza przeniesienie obciążenia serwera, na którym stoi baza na
rzecz końcówek klientów.
Nie.
Zauważ, że baza danych jest strong type, czyli z góry określasz z jakimi
typami danych pracujesz. Deklarując np. pole varchar określasz jego max
długość (tak, wiem są wyjątki, ale nie o to tu chodzi). I już.
Jeśli jednak potrzebujesz dodatkowych ograniczeń (np. to pole jest
wymagane dla tego użytkownika, ale nie jest w bazie danych; to pole ma
max długość 3, pomimo tego że baza przechowa i 25 znaków) to tego typu
zabawki powinny znaleźć się właśnie w AppDictionary, czyli de-facto w
aplikacji (serwerze aplikacyjnym); przynajmniej ja tak robię.
Post by jh
Post by wloochacz
Jeśli chcesz nieć jedną logikę i niezależność od front-endu - tu
kłania się SOA.
Jeśli nie za bardzo wiesz o czym piszę, to prawdopodobnie nigdy nie
będzie Ci to potrzebne, więc szkoda na to czasu na obecnym etapie tego
projektu.
Masz rację. Terminologię wygoogle'ać nietrudno, więc nie będę się
wymądrzał, że wiem jak tego użyć. Po prostu nie umiałbym napisać takich
rzeczy.
Post by wloochacz
Mam wlasny sposób logowania userów [..]
IMO szkoda prądu na takie pomysły.
Zaraz zaraz, pomysł pochodzi od jednego z Twoich postów na tejże grupie
;) Chodzi oczywiście o samo logowanie.
Samo logowanie tak , ale sprawdzanie przed każdą operacją bazodanową czy
user jest zalogowany... hmmm... to zależy, ale jeśli ma to być
zabezpieczenie przed nieautoryzowanym dostępem do danych z zewnątrz, to
na to, imho, szkoda prądu.
Post by jh
Post by wloochacz
Jeśli potrzebujesz bezpiecznej bazy danych, to użyj takiej które
oferuje wymaganą funkcjonalność.
Masz 100% rację, tylko jak się ktoś do czegoś przyzwyczai to ma opory
przed zmianami ;) Zaczynałem od Firebirda i choć po drodze otarłem się o
Accessa, MS SQL, to pozostałem przy FB, za sugestiami (między innymi
Twoimi :D) zanabyłem FIBPlusy, IBExperta i ciężko mi się oderwać od tych
narzędzi. IBExpert jest dla mnie wręcz idealnym narzędziem (database
diesigner, choć nieco siermiężny, dokumentowanie w html itd. są na
porządku dziennym). Jak sobie pomyślę, że FreeMind jest również z
Twojego polecenia to robi się niezpiecznie, bo wychodzi na to, że masz
za duży wpływ na mnie :D
Spoko, będziesz płacił tantiemy :D
Post by jh
Post by wloochacz
Aczkolwiek, niektóre pomysły są atrakcyjne vel Application Dictionary;
http://dn.codegear.com/article/33887
Muszę jeszcze sporo doczytać, jak widać ;)
Poczytaj - pomysł jest ciekawy a łącząc go z czymś na kształt silnika
wykonawczego reguł biznesowych (chodzi o to że logika aplikacji nie jest
zakodowana w aplikacji tylko na odseparowanej warstwie. Najlepiej
takiej, która nie wymaga rekompilacji po zmianie reguł; wielce przydatne
kiedy dostarczasz "to samo" lub "podobne" rozwiązanie dla różnych
klientów, ale różnice są w szczegółach; masz ten sam kod bazowy, a
reguły zAleżne tylko od konkretnej dystrybucji aplikacji dla konkretnego
klienta), robi się naprawdę fajnie :)
Fajnie, bo tu jest naprawdę code reusability! :)
--
wloochacz
jh
2008-09-24 12:03:39 UTC
Permalink
Post by wloochacz
Post by jh
Czyli, jeśli dobrze zrozumiałem lepiej w bazie trzymać te ustawienia (np.
ograniczenia, check itd.), zaczytać je przy starcie aplikacji i w niej
kontrolować dane przy wprowadzaniu. To w odniesieniu też do postu bObika
oznacza przeniesienie obciążenia serwera, na którym stoi baza na rzecz
końcówek klientów.
Nie.
Zauważ, że baza danych jest strong type, czyli z góry określasz z jakimi
typami danych pracujesz. Deklarując np. pole varchar określasz jego max
długość (tak, wiem są wyjątki, ale nie o to tu chodzi). I już.
Jeśli jednak potrzebujesz dodatkowych ograniczeń (np. to pole jest wymagane
dla tego użytkownika, ale nie jest w bazie danych; to pole ma max długość 3,
pomimo tego że baza przechowa i 25 znaków) to tego typu zabawki powinny
znaleźć się właśnie w AppDictionary, czyli de-facto w aplikacji (serwerze
aplikacyjnym); przynajmniej ja tak robię.
OK. Niefortunnie się wyraziłem w pierwszym zdaniu. Miałem na myśli nie tyle np.
check dla pola w konkretnej tabeli, do której ono należy, ale (banalne...)
setup, ustawienia systemu, które są zaczytywane przy starcie aplikacji.

I na razie nie będę się pogrążał :) tylko doczytam ten artykuł.Przy okazji
zajrzałem na wspomniane InstantObjects. Warte uwagi?

jh
wloochacz
2008-09-24 12:35:35 UTC
Permalink
jh pisze:
[ciach]
Post by jh
OK. Niefortunnie się wyraziłem w pierwszym zdaniu. Miałem na myśli nie
tyle np. check dla pola w konkretnej tabeli, do której ono należy, ale
(banalne...) setup, ustawienia systemu, które są zaczytywane przy
starcie aplikacji.
Czytam tylko to co jest potrzebne w danym czasie. Nie wcześniej, nie
później.
Post by jh
I na razie nie będę się pogrążał :) tylko doczytam ten artykuł.Przy
okazji zajrzałem na wspomniane InstantObjects. Warte uwagi?
A kto wspominał o InstantObjects?
Czy warte - a nie wiem, nie używam. Wygląda w miarę, ale mi się nie
zgrywa zupełnie z oczekiwaniami (mam fanaberyjne oczekiwania ;)).
Ja raczej miałem na myśli coś takiego:
http://www.objectconnections.com/ckrulesengine.html
--
wloochacz
jh
2008-09-24 13:06:21 UTC
Permalink
Post by wloochacz
A kto wspominał o InstantObjects?
Jeden z komentarzy do podanego przez Ciebie artykułu.
Post by wloochacz
Czy warte - a nie wiem, nie używam. Wygląda w miarę, ale mi się nie zgrywa
zupełnie z oczekiwaniami (mam fanaberyjne oczekiwania ;)).
http://www.objectconnections.com/ckrulesengine.html
Kiedy Ty masz na to czas...? :)

jh
Andrzej
2008-09-24 13:52:30 UTC
Permalink
Post by jh
Kiedy Ty masz na to czas...? :)
Też się nad tym zastanawiałem :o) Widać Wloochacz ma trzy półkule
mózgowe a nie dwie jak my :o)

pozdrófka...
Andrzej
wloochacz
2008-09-24 14:24:41 UTC
Permalink
Post by Andrzej
Post by jh
Kiedy Ty masz na to czas...? :)
Też się nad tym zastanawiałem :o) Widać Wloochacz ma trzy półkule
mózgowe a nie dwie jak my :o)
Pomiędzy telefonem, outlookiem, gg, grupą, SQLEditorem, CaseStudio i
Delphi :P
Wymyślam takie głupoty jak jestem w lesie (jak jest ciemno, to naprawdę
mało bodźców dociera do człowieka ;)), potem uzgadniam szczegóły ze
swoim DreamTeam i gotowe! :D

Nooo... luknijcie na to:
http://www.mikejustin.com/habari.html
Fajne?
Zajebiste!

Po co? Potrzebne mi to m.in do integracji w czasie rzeczywistym (ok;
"prawie" w czasie rzeczywistym :)) pomiędzy różnymi aplikacjami. Ale nie
tylko - zwłaszcza fajnie w aplikacji wygląda komunikacja w trybie
point-to-point; ktoś dodał informacje - inny klient w sieci
auto-magicznie odświeża niezbędną informację, bo akurat ją ogląda. I nie
ważne czy to app webowa, desktopowa czy na innym kontynencie :)
I wiele innych zastosowań :)
--
wloochacz
Tygrys
2008-09-24 10:11:21 UTC
Permalink
Post by jh
Firebird 2.1, Delphi 2007 Pro
Mam pytanie do tych, co to więcej ode mnie potrafią i zechcieliby się
podzielić wiedzą. Pracując nad większym (jak na jednego developera)
projektem, gdybam, gdzie lepiej zaszyć logikę biznesową: co po stronie
aplikacji, a co w bazie i gdzie.
Ja używam reguł w bazie tam, gdzie mają one wpływ na spójność i
wymagalność danych. W skrócie sprowadza się to do zapewnienia, że dane
wpisane poza aplikacją będą strukturalnie i "komputerowo" poprawne.

Natomiast to, czy są one merytorycznie sensowne pozostawiam aplikacji.

Staram się takie sprawdzenia wydzielić z interfejsu wizualnego do
oddzielnej "warstwy" która zajmuje się oceną poprawności danych.

Pozdrawiam,
Tygrys
jh
2008-09-24 11:38:51 UTC
Permalink
Ja używam reguł w bazie tam, gdzie mają one wpływ na spójność i wymagalność
danych. W skrócie sprowadza się to do zapewnienia, że dane wpisane poza
aplikacją będą strukturalnie i "komputerowo" poprawne.
To rozumiem. Tylko jak w moim przykładzie - zakładam, że każdy user musi mieć
hasło. Czyli pole not null. Pusty string to nie jest null i owej integralnośći
nie narusza - tu potrzebne jest sprawdzenie długości owego hasła. To właśnie to,
o co pytałem - czy robić to po stronie aplikacji, czy po stronie bazy i z niej
rzucać wyjątkiem.
Natomiast to, czy są one merytorycznie sensowne pozostawiam aplikacji.
OK.
Staram się takie sprawdzenia wydzielić z interfejsu wizualnego do oddzielnej
"warstwy" która zajmuje się oceną poprawności danych.
Czyli, dając produkt konkretnemu klientowi z określonymi wymaganiami
rekompilujesz projekt?

jh
Tygrys
2008-09-24 12:12:11 UTC
Permalink
Post by jh
Post by Tygrys
Ja używam reguł w bazie tam, gdzie mają one wpływ na spójność i
wymagalność danych. W skrócie sprowadza się to do zapewnienia, że dane
wpisane poza aplikacją będą strukturalnie i "komputerowo" poprawne.
To rozumiem. Tylko jak w moim przykładzie - zakładam, że każdy user musi
mieć hasło. Czyli pole not null. Pusty string to nie jest null i owej
integralnośći nie narusza - tu potrzebne jest sprawdzenie długości owego
hasła. To właśnie to, o co pytałem - czy robić to po stronie aplikacji,
czy po stronie bazy i z niej rzucać wyjątkiem.
Tak, o to chodzi. Aplikacja może dopuszczać puste hasło albo nie, ale
nie wpływa to na integralność danych w bazie.
Post by jh
Post by Tygrys
Staram się takie sprawdzenia wydzielić z interfejsu wizualnego do
oddzielnej "warstwy" która zajmuje się oceną poprawności danych.
Czyli, dając produkt konkretnemu klientowi z określonymi wymaganiami
rekompilujesz projekt?
Tak, ale jak wiesz robię rozwiązania dedykowane klientowi a nie "na
półkę". Natomiast posiadając taką "wydzieloną warstwę kontrolną" można
się pokusić o eksport tych wymagań do pliku konfiguracyjnego albo dll i
wtedy nie ma konieczności rekompilacji aplikacji. Z drugiej strony,
delphi jest szybkie w kompilacji i jakoś nie mam potrzeby parametryzacji
wszystkiego. Staram się pisać kod tak, aby nie blokować sobie przyszłych
zmian funkcjonalności tego typu a jednocześnie nie zawracać sobie nimi
głowy aż nie będą potrzebne (czytaj: aż ktoś nie będzie chciał za taką
funkcjonalność zapłacić) ;-)

Tygrys
jh
2008-09-24 12:26:37 UTC
Permalink
Tak, ale jak wiesz robię rozwiązania dedykowane klientowi a nie "na półkę"
[ciach]
Dzięki.

Do zobaczenia (wkrótce?)

jh
ZbyszekZ
2008-09-24 18:40:03 UTC
Permalink
Post by jh
Ja używam reguł w bazie tam, gdzie mają one wpływ na spójność i wymagalność
danych. W skrócie sprowadza się to do zapewnienia, że dane wpisane poza
aplikacją będą strukturalnie i "komputerowo" poprawne.
To rozumiem. Tylko jak w moim przykładzie - zakładam, że każdy user musi mieć
hasło. Czyli pole not null. Pusty string to nie jest null i owej integralnośći
nie narusza - tu potrzebne jest sprawdzenie długości owego hasła. To właśnie to,
o co pytałem - czy robić to po stronie aplikacji, czy po stronie bazy i z niej
rzucać wyjątkiem.
Dla każdej funkcji trzeba rozstrzygać w jakie warstwie aplikacji ma
zostać zaimplementowana.
Akurat logowanie należy pozostawić z całą pewnością serwerowi bazy
danych, głównie dlatego że inaczej masz jedno ryzyko więcej że
użytkownik będzie grzebał w nieswoich danych.
Jeśli serwer dba o prawa użytkowników to czy dostanie się on przez
aplikację czy bezpośrednio będzie mógł osiągnąć tyle samo.
Podobnie z każdą inną funkcją, weźmy inną walidację np. wprowadzona
wartość nie może być większa niż górne przyjęte ograniczenie. Gdzie to
należy zaimplementować? Ano w większości przypadków i w aplikacji i
serwerze danych.
Formatowanie nr NIP? Bez problemu w serwerze bd, a sprawdzanie
ortografii? Jasne że w aplikacji itd itp.

--
***@private
wloochacz
2008-09-25 08:22:31 UTC
Permalink
Post by ZbyszekZ
Post by jh
Ja używam reguł w bazie tam, gdzie mają one wpływ na spójność i wymagalność
danych. W skrócie sprowadza się to do zapewnienia, że dane wpisane poza
aplikacją będą strukturalnie i "komputerowo" poprawne.
To rozumiem. Tylko jak w moim przykładzie - zakładam, że każdy user musi mieć
hasło. Czyli pole not null. Pusty string to nie jest null i owej integralnośći
nie narusza - tu potrzebne jest sprawdzenie długości owego hasła. To właśnie to,
o co pytałem - czy robić to po stronie aplikacji, czy po stronie bazy i z niej
rzucać wyjątkiem.
Dla każdej funkcji trzeba rozstrzygać w jakie warstwie aplikacji ma
zostać zaimplementowana.
Akurat logowanie należy pozostawić z całą pewnością serwerowi bazy
danych, głównie dlatego że inaczej masz jedno ryzyko więcej że
użytkownik będzie grzebał w nieswoich danych.
Nie zgadzam się.
To znaczy, że twierdzisz iż app powinna opierać się na loginach bazy danych?
Przerobiłem to - więcej z tym kłopotów, niż pożytku. Zwłaszcza jak do
tego samego serwera ma dostęp kilka aplikacji, które logują się tak jak
mówisz.
W efekcie czego - do app A logujesz się jako "wloochacz1" do app B jako
"wloochacz2", etc. Żeby było ciekawiwj, to są niezbędne wskorśne dostępy
do baz danych poszczególnych aplikacji (app A musi mieć dostęp do bazy
danych B i odwrotnie).
Oczywiście wyjściem jest autoryzacja na poziomie LDAP/ActiveDirectory,
tylko niestety aplikacje z którymi miałem do czynienia autoryzują tylko
i wyłączenie z wykorzystaniem mechanizmów bazy danych.
Efekt - jak się nie odwrócisz, tak d z tyłu...
Post by ZbyszekZ
Jeśli serwer dba o prawa użytkowników to czy dostanie się on przez
aplikację czy bezpośrednio będzie mógł osiągnąć tyle samo.
Prawda. Ale po namyśle, wolę inne rozwiązanie. Chodzi o to, żeby
użytkownik nie miał prawa dowiedzieć się, za pomocą jakiego mechanizmu
(login, hasło) się loguje ;)
Post by ZbyszekZ
Podobnie z każdą inną funkcją, weźmy inną walidację np. wprowadzona
wartość nie może być większa niż górne przyjęte ograniczenie. Gdzie to
należy zaimplementować? Ano w większości przypadków i w aplikacji i
serwerze danych.
Formatowanie nr NIP? Bez problemu w serwerze bd, a sprawdzanie
ortografii? Jasne że w aplikacji itd itp.
Oczywiście że JAKIEKOLWIEK formatowanie NIE powinno być po stronie bazy
danych. Żadne.
Po co bazie danych sformatowane dane? Po nic - to aplikacja potrzebuje
formatowania, a dokładnie - użytkownik. A skoro użytkownik "używa" bazy
danych za pomocą aplikacji, to niech aplikacja zadba o odpowiednią formę
prezentacji.
--
wloochacz
ZbyszekZ
2008-09-25 10:58:57 UTC
Permalink
Post by wloochacz
Nie zgadzam się.
To znaczy, że twierdzisz iż app powinna opierać się na loginach bazy danych?
Przerobiłem to - więcej z tym kłopotów, niż pożytku. Zwłaszcza jak do
tego samego serwera ma dostęp kilka aplikacji, które logują się tak jak
mówisz.
Jo men. Są sytuacje gdzie lepiej zrobić własne logowanie, aczkolwiek
im większa aplikacja tym lepiej jest polegać na mechanizmach
systemowych (ale i od tej reguły są wyjatki ;-)
Post by wloochacz
W efekcie czego - do app A logujesz się jako "wloochacz1" do app B jako
"wloochacz2", etc. Żeby było ciekawiwj, to są niezbędne wskorśne dostępy
do baz danych poszczególnych aplikacji (app A musi mieć dostęp do bazy
danych B i odwrotnie).
Oczywiście wyjściem jest autoryzacja na poziomie LDAP/ActiveDirectory,
tylko niestety aplikacje z którymi miałem do czynienia autoryzują tylko
i wyłączenie z wykorzystaniem mechanizmów bazy danych.
Efekt - jak się nie odwrócisz, tak d z tyłu...
Ale, ale Interbase (nie wiem jak FB) miało w tym celu mechanizm ról
użytkowników.
Przy logowaniu można określić z jakim uprawnieniami teraz działamy, a
login i hasło sa bez zmiany.
Post by wloochacz
Post by ZbyszekZ
Jeśli serwer dba o prawa użytkowników to czy dostanie się on przez
aplikację czy bezpośrednio będzie mógł osiągnąć tyle samo.
Prawda. Ale po namyśle, wolę inne rozwiązanie. Chodzi o to, żeby
użytkownik nie miał prawa dowiedzieć się, za pomocą jakiego mechanizmu
(login, hasło) się loguje ;)
Czasem tak można, coraz częściej nie (administratorzy, otwarty kod i
takie tam brewerie).
Post by wloochacz
Oczywiście że JAKIEKOLWIEK formatowanie NIE powinno być po stronie bazy
danych. Żadne.
Po co bazie danych sformatowane dane? Po nic - to aplikacja potrzebuje
formatowania, a dokładnie - użytkownik. A skoro użytkownik "używa" bazy
danych za pomocą aplikacji, to niech aplikacja zadba o odpowiednią formę
prezentacji.
Nie ma żadnych stałych reguł, zawsze są wyjątki i nie można wyłączać
myślenia (to chyba stała reguła).
Napisałem o bardzo szczególnym przypadku nr NIP, jak wiadomo jest to
10 cyfr czasem dzielonych na mniej lub bardziej przypadkowe grupy. Aby
miało sens wyszukiwanie i inne użycie musi być jednak zapisany zawsze
w tej samej postaci.
IMHO najczęściej, najlepszym sposobem ujednolicenia jest
przechowywanie ich zawsze tak samo, a jak zawsze to dobrze aby serwer
o to dbał.

--
***@private
wloochacz
2008-09-25 11:28:01 UTC
Permalink
Post by ZbyszekZ
Post by wloochacz
Nie zgadzam się.
To znaczy, że twierdzisz iż app powinna opierać się na loginach bazy danych?
Przerobiłem to - więcej z tym kłopotów, niż pożytku. Zwłaszcza jak do
tego samego serwera ma dostęp kilka aplikacji, które logują się tak jak
mówisz.
Jo men. Są sytuacje gdzie lepiej zrobić własne logowanie, aczkolwiek
im większa aplikacja tym lepiej jest polegać na mechanizmach
systemowych (ale i od tej reguły są wyjatki ;-)
Dlaczego?
Właśnie, kiedy moja aplikacja dorosła do "większych" zmieniłem sposób
autoryzacji.
Post by ZbyszekZ
Post by wloochacz
W efekcie czego - do app A logujesz się jako "wloochacz1" do app B jako
"wloochacz2", etc. Żeby było ciekawiwj, to są niezbędne wskorśne dostępy
do baz danych poszczególnych aplikacji (app A musi mieć dostęp do bazy
danych B i odwrotnie).
Oczywiście wyjściem jest autoryzacja na poziomie LDAP/ActiveDirectory,
tylko niestety aplikacje z którymi miałem do czynienia autoryzują tylko
i wyłączenie z wykorzystaniem mechanizmów bazy danych.
Efekt - jak się nie odwrócisz, tak d z tyłu...
Ale, ale Interbase (nie wiem jak FB) miało w tym celu mechanizm ról
użytkowników.
I ma; i nie tylko FB, każda (chyba?) baza ma...
Niektóre mają nawet role aplikacyjne ;o)
Post by ZbyszekZ
Przy logowaniu można określić z jakim uprawnieniami teraz działamy, a
login i hasło sa bez zmiany.
To nie jest takie so easy...
Uprawnienia do obiektów/procesów biznesowych to jedno, a uprawnienia do
obiektów bazy danych (tabele, widoki, procedury) to zupełnie co innego.
Oczywiście, gdyby w Delphi był ORM, to byłoby łatwiej - ale nie ma i nie
znalazłem kompromisu, który by uwzględniał uprawnienia użytkownika w
aplikacji w bazie danych (propagacja uprawnień).
To się da zrobić, ale to jest KUPA roboty i wcale nie wiadomo czy taka
niezbędna :)
Post by ZbyszekZ
Post by wloochacz
Post by ZbyszekZ
Jeśli serwer dba o prawa użytkowników to czy dostanie się on przez
aplikację czy bezpośrednio będzie mógł osiągnąć tyle samo.
Prawda. Ale po namyśle, wolę inne rozwiązanie. Chodzi o to, żeby
użytkownik nie miał prawa dowiedzieć się, za pomocą jakiego mechanizmu
(login, hasło) się loguje ;)
Czasem tak można, coraz częściej nie (administratorzy, otwarty kod i
takie tam brewerie).
Niech będzie, ale to brewerie ;)
Post by ZbyszekZ
Post by wloochacz
Oczywiście że JAKIEKOLWIEK formatowanie NIE powinno być po stronie bazy
danych. Żadne.
Po co bazie danych sformatowane dane? Po nic - to aplikacja potrzebuje
formatowania, a dokładnie - użytkownik. A skoro użytkownik "używa" bazy
danych za pomocą aplikacji, to niech aplikacja zadba o odpowiednią formę
prezentacji.
Nie ma żadnych stałych reguł, zawsze są wyjątki i nie można wyłączać
myślenia (to chyba stała reguła).
Napisałem o bardzo szczególnym przypadku nr NIP, jak wiadomo jest to
10 cyfr czasem dzielonych na mniej lub bardziej przypadkowe grupy. Aby
miało sens wyszukiwanie i inne użycie musi być jednak zapisany zawsze
w tej samej postaci.
IMHO najczęściej, najlepszym sposobem ujednolicenia jest
przechowywanie ich zawsze tak samo, a jak zawsze to dobrze aby serwer
o to dbał.
Zgoda - tak samo.
Nie zgoda - nie serwer.
Sam widziałem dwa różne formaty NIPu - no i co?
Kody pocztowe - inne formaty, zależnie od kraju. Etc, etc.
IMO lepiej trzymać to bez formatu, wyświetlać z odpowiednią maską.
Co do wyszukiwania - dialog wyszukiwania poprosi o NIP w odpowiednim
formacie, prześle do bazy zapytanie już "zdeformatowane". Proste.
--
wloochacz
ZbyszekZ
2008-09-25 14:12:49 UTC
Permalink
Post by wloochacz
Post by ZbyszekZ
Jo men. Są sytuacje gdzie lepiej zrobić własne logowanie, aczkolwiek
im większa aplikacja tym lepiej jest polegać na mechanizmach
systemowych (ale i od tej reguły są wyjatki ;-)
Dlaczego?
Właśnie, kiedy moja aplikacja dorosła do "większych" zmieniłem sposób
autoryzacji.
Bo nie wszyscy w zespole, zawsze pamietają o poprawnym pisaniu
klienta. Szczególnie jak baze danych i klientów piszą dwie różne
firmy.
Post by wloochacz
To nie jest takie so easy...
Uprawnienia do obiektów/procesów biznesowych to jedno, a uprawnienia do
obiektów bazy danych (tabele, widoki, procedury) to zupełnie co innego.
Oczywiście, gdyby w Delphi był ORM, to byłoby łatwiej - ale nie ma i nie
znalazłem kompromisu, który by uwzględniał uprawnienia użytkownika w
aplikacji w bazie danych (propagacja uprawnień).
To się da zrobić, ale to jest KUPA roboty i wcale nie wiadomo czy taka
niezbędna :)
A to nie wiem, od baz danych mam ludzi, i akurat na ten aspekt nigdy
nie narzekali.
Post by wloochacz
Post by ZbyszekZ
Czasem tak można, coraz częściej nie (administratorzy, otwarty kod i
takie tam brewerie).
Niech będzie, ale to brewerie ;)
Ale to między nami, w SIWZ to się nazywa wymagania klienta ;-)
Post by wloochacz
Post by ZbyszekZ
IMHO najczęściej, najlepszym sposobem ujednolicenia jest
przechowywanie ich zawsze tak samo, a jak zawsze to dobrze aby serwer
o to dbał.
Zgoda - tak samo.
Nie zgoda - nie serwer.
Sam widziałem dwa różne formaty NIPu - no i co?
Kody pocztowe - inne formaty, zależnie od kraju. Etc, etc.
IMO lepiej trzymać to bez formatu, wyświetlać z odpowiednią maską.
Co do wyszukiwania - dialog wyszukiwania poprosi o NIP w odpowiednim
formacie, prześle do bazy zapytanie już "zdeformatowane". Proste.
Co znaczy bez formatu? Jak najbardziej w formacie - 9999999999 plus
zapis jak wyświetlać.
Kiedyś miałem spór z pacjentem (główna księgowa), skończyło się tym że
było zapisane dwa razy, raz tak jak luser wprowadził a drugi,
przeformatowany, bez kresek. Zapis do "mojego" pola robił serwer, bo
niby dlaczego miałaby to robić aplikacja, toz idealne a nawet
wzorcowe, zadanie dla procedury skladownej (co by chociaż pozór
spójności danych mieć.

--
***@private
wloochacz
2008-09-26 08:05:35 UTC
Permalink
ZbyszekZ pisze:
[ciach]
Post by ZbyszekZ
Post by wloochacz
Dlaczego?
Właśnie, kiedy moja aplikacja dorosła do "większych" zmieniłem sposób
autoryzacji.
Bo nie wszyscy w zespole, zawsze pamietają o poprawnym pisaniu
klienta. Szczególnie jak baze danych i klientów piszą dwie różne
firmy.
E... na to bym nie wpadł, raczej.
Raczej, przy takiej współpracy wyobrażał bym sobie to zupełnie inaczej
(SOA na ten przykład).
Post by ZbyszekZ
Post by wloochacz
To nie jest takie so easy...
Uprawnienia do obiektów/procesów biznesowych to jedno, a uprawnienia do
obiektów bazy danych (tabele, widoki, procedury) to zupełnie co innego.
Oczywiście, gdyby w Delphi był ORM, to byłoby łatwiej - ale nie ma i nie
znalazłem kompromisu, który by uwzględniał uprawnienia użytkownika w
aplikacji w bazie danych (propagacja uprawnień).
To się da zrobić, ale to jest KUPA roboty i wcale nie wiadomo czy taka
niezbędna :)
A to nie wiem, od baz danych mam ludzi, i akurat na ten aspekt nigdy
nie narzekali.
Może się z nim nie spotkali? ;-)
Post by ZbyszekZ
Post by wloochacz
Post by ZbyszekZ
Czasem tak można, coraz częściej nie (administratorzy, otwarty kod i
takie tam brewerie).
Niech będzie, ale to brewerie ;)
Ale to między nami, w SIWZ to się nazywa wymagania klienta ;-)
Nie no, spoko. Jak to jest wymaganie, to klient za to zapłaci.
A brewerią jest oczekiwanie konkretnego zachowania ;-)
Post by ZbyszekZ
Post by wloochacz
Post by ZbyszekZ
IMHO najczęściej, najlepszym sposobem ujednolicenia jest
przechowywanie ich zawsze tak samo, a jak zawsze to dobrze aby serwer
o to dbał.
Zgoda - tak samo.
Nie zgoda - nie serwer.
Sam widziałem dwa różne formaty NIPu - no i co?
Kody pocztowe - inne formaty, zależnie od kraju. Etc, etc.
IMO lepiej trzymać to bez formatu, wyświetlać z odpowiednią maską.
Co do wyszukiwania - dialog wyszukiwania poprosi o NIP w odpowiednim
formacie, prześle do bazy zapytanie już "zdeformatowane". Proste.
Co znaczy bez formatu? Jak najbardziej w formacie - 9999999999 plus
zapis jak wyświetlać.
Czyli bez formatu :)
Post by ZbyszekZ
Kiedyś miałem spór z pacjentem (główna księgowa), skończyło się tym że
było zapisane dwa razy, raz tak jak luser wprowadził a drugi,
przeformatowany, bez kresek. Zapis do "mojego" pola robił serwer, bo
niby dlaczego miałaby to robić aplikacja, toz idealne a nawet
wzorcowe, zadanie dla procedury skladownej (co by chociaż pozór
spójności danych mieć.
Czy wzorcowe? Bardziej wzorcowy byłby trigger, bo nie da się tego ominąć
(chyba że zabierze się uprawnienia do tabeli a nada tylko do procki);
przecież nie będziemy się spierać o pierdoły ;-)
--
wloochacz
ZbyszekZ
2008-09-26 13:57:51 UTC
Permalink
[ciach]>> Dlaczego?
Post by ZbyszekZ
Post by wloochacz
Właśnie, kiedy moja aplikacja dorosła do "większych" zmieniłem sposób
autoryzacji.
Bo nie wszyscy w zespole, zawsze pamietają o poprawnym pisaniu
klienta. Szczególnie jak baze danych i klientów piszą dwie różne
firmy.
E... na to bym nie wpadł, raczej.
Raczej, przy takiej współpracy wyobrażał bym sobie to zupełnie inaczej
(SOA na ten przykład).
SOA to tylko troche inna abstrakcja niz baza danych.
Np. teraz mam na tapecie firme piszaca fron-end a konieczne
modyfikacje core-systemu robi firma wlasnym zespolem (jest niewielu
mistrzów Cobola na rynku :-)
Post by ZbyszekZ
A to nie wiem, od baz danych mam ludzi, i akurat na ten aspekt nigdy
nie narzekali.
Może się z nim nie spotkali? ;-)
Albo stosują wzorce i mają odfajkowany temat.
Post by ZbyszekZ
Ale to między nami, w SIWZ to się nazywa wymagania klienta ;-)
Nie no, spoko. Jak to jest wymaganie, to klient za to zapłaci.
A brewerią jest oczekiwanie konkretnego zachowania ;-)
Masz na mysli placenie? :-))
Post by ZbyszekZ
Post by wloochacz
Post by ZbyszekZ
IMHO najczęściej, najlepszym sposobem ujednolicenia jest
przechowywanie ich zawsze tak samo, a jak zawsze to dobrze aby serwer
o to dbał.
Zgoda - tak samo.
Nie zgoda - nie serwer.
Sam widziałem dwa różne formaty NIPu - no i co?
Kody pocztowe - inne formaty, zależnie od kraju. Etc, etc.
IMO lepiej trzymać to bez formatu, wyświetlać z odpowiednią maską.
Co do wyszukiwania - dialog wyszukiwania poprosi o NIP w odpowiednim
formacie, prześle do bazy zapytanie już "zdeformatowane". Proste.
Co znaczy bez formatu? Jak najbardziej w formacie - 9999999999 plus
zapis jak wyświetlać.
Czyli bez formatu :)
Post by ZbyszekZ
Kiedyś miałem spór z pacjentem (główna księgowa), skończyło się tym że
było zapisane dwa razy, raz tak jak luser wprowadził a drugi,
przeformatowany, bez kresek. Zapis do "mojego" pola robił serwer, bo
niby dlaczego miałaby to robić aplikacja, toz idealne a nawet
wzorcowe, zadanie dla procedury skladownej (co by chociaż pozór
spójności danych mieć.
Czy wzorcowe? Bardziej wzorcowy byłby trigger, bo nie da się tego ominąć
(chyba że zabierze się uprawnienia do tabeli a nada tylko do procki);
przecież nie będziemy się spierać o pierdoły ;-)
A Ty myślisz że tej bazie to robil krasnoludek, jasne ze trigger.
Wcale sie nie spieram bo mowimy to samo :-) tyle że innymi slowami
(slownik by sie przydal).
Jak będziesz miał chwile w bezkresie swojego czasu moze zerkniesz na
jazz.net a w szczególności na Requirements Composer (aktualnie
dostepny w wersji beta). M.in. pozwala na harmonijne prowadzenie
dyskusji (na temat wymagan).

--
***@private
wloochacz
2008-09-26 14:32:14 UTC
Permalink
Post by ZbyszekZ
[ciach]>> Dlaczego?
Post by ZbyszekZ
Post by wloochacz
Właśnie, kiedy moja aplikacja dorosła do "większych" zmieniłem sposób
autoryzacji.
Bo nie wszyscy w zespole, zawsze pamietają o poprawnym pisaniu
klienta. Szczególnie jak baze danych i klientów piszą dwie różne
firmy.
E... na to bym nie wpadł, raczej.
Raczej, przy takiej współpracy wyobrażał bym sobie to zupełnie inaczej
(SOA na ten przykład).
SOA to tylko troche inna abstrakcja niz baza danych.
Wiem. I dlatego napisałem "inaczej"; ale, w końcu, i tak za każdą
"smołą" w końcu stoi jakaś baza danych - nie? :D
Post by ZbyszekZ
Np. teraz mam na tapecie firme piszaca fron-end a konieczne
modyfikacje core-systemu robi firma wlasnym zespolem (jest niewielu
mistrzów Cobola na rynku :-)
Post by ZbyszekZ
A to nie wiem, od baz danych mam ludzi, i akurat na ten aspekt nigdy
nie narzekali.
Może się z nim nie spotkali? ;-)
Albo stosują wzorce i mają odfajkowany temat.
Post by ZbyszekZ
Ale to między nami, w SIWZ to się nazywa wymagania klienta ;-)
Nie no, spoko. Jak to jest wymaganie, to klient za to zapłaci.
A brewerią jest oczekiwanie konkretnego zachowania ;-)
Masz na mysli placenie? :-))
Mam na myśli zachowanie klienta, któremu się wydaje, że jego pomysły to
jest, tu cytat: "standardowa funkcjonalność", za którą oczywiście nie
musi nic płacić.
Oj, miałem takiego gościa; jak mnie już wk... na maxa to mu
powiedziałem, że jego "standardowa funkcjonalność" to są "fanaberyczne
wymagania". Uuuuhhh, ale była zadyma :)
Tylko, że on już nie pracuje, a ja dalej rozwijam ten system ;-)
Post by ZbyszekZ
Post by ZbyszekZ
Post by wloochacz
Post by ZbyszekZ
IMHO najczęściej, najlepszym sposobem ujednolicenia jest
przechowywanie ich zawsze tak samo, a jak zawsze to dobrze aby serwer
o to dbał.
Zgoda - tak samo.
Nie zgoda - nie serwer.
Sam widziałem dwa różne formaty NIPu - no i co?
Kody pocztowe - inne formaty, zależnie od kraju. Etc, etc.
IMO lepiej trzymać to bez formatu, wyświetlać z odpowiednią maską.
Co do wyszukiwania - dialog wyszukiwania poprosi o NIP w odpowiednim
formacie, prześle do bazy zapytanie już "zdeformatowane". Proste.
Co znaczy bez formatu? Jak najbardziej w formacie - 9999999999 plus
zapis jak wyświetlać.
Czyli bez formatu :)
Post by ZbyszekZ
Kiedyś miałem spór z pacjentem (główna księgowa), skończyło się tym że
było zapisane dwa razy, raz tak jak luser wprowadził a drugi,
przeformatowany, bez kresek. Zapis do "mojego" pola robił serwer, bo
niby dlaczego miałaby to robić aplikacja, toz idealne a nawet
wzorcowe, zadanie dla procedury skladownej (co by chociaż pozór
spójności danych mieć.
Czy wzorcowe? Bardziej wzorcowy byłby trigger, bo nie da się tego ominąć
(chyba że zabierze się uprawnienia do tabeli a nada tylko do procki);
przecież nie będziemy się spierać o pierdoły ;-)
A Ty myślisz że tej bazie to robil krasnoludek, jasne ze trigger.
No to co piszesz, że "toz idealne a nawet wzorcowe, zadanie dla
procedury skladownej"? Zresztą, nevermind...
Post by ZbyszekZ
Wcale sie nie spieram bo mowimy to samo :-) tyle że innymi slowami
(slownik by sie przydal).
taa... pewnie nie tylko słownik, co homogeniczny aparat pojęciowy, co? ;-)
Post by ZbyszekZ
Jak będziesz miał chwile w bezkresie swojego czasu moze zerkniesz na
jazz.net a w szczególności na Requirements Composer (aktualnie
dostepny w wersji beta). M.in. pozwala na harmonijne prowadzenie
dyskusji (na temat wymagan).
Lookam...
--
wloochacz
ZbyszekZ
2008-09-26 14:48:31 UTC
Permalink
Post by wloochacz
Post by ZbyszekZ
SOA to tylko troche inna abstrakcja niz baza danych.
Wiem. I dlatego napisałem "inaczej"; ale, w końcu, i tak za każdą
"smołą" w końcu stoi jakaś baza danych - nie? :D
Jak zawsze będę protestował przeciwko generalizacji, w tym wypadku
najczęściej.
Aczkolwiek jak sklasyfikować Human Tasks w procesie SOA? Czy jest za
nim baza danych (mózg) czy nie to temat do innej dyskusji :-) przy
bardzo szerokim potraktowaniu "jakaś" to tak.
Post by wloochacz
Post by ZbyszekZ
Masz na mysli placenie? :-))
Mam na myśli zachowanie klienta, któremu się wydaje, że jego pomysły to
jest, tu cytat: "standardowa funkcjonalność", za którą oczywiście nie
musi nic płacić.
Oj, miałem takiego gościa; jak mnie już wk... na maxa to mu
powiedziałem, że jego "standardowa funkcjonalność" to są "fanaberyczne
wymagania". Uuuuhhh, ale była zadyma :)
Tylko, że on już nie pracuje, a ja dalej rozwijam ten system ;-)
Pewnie jednak pracuje i gdzie indziej ma fanaberie :-)
Post by wloochacz
No to co piszesz, że "toz idealne a nawet wzorcowe, zadanie dla
procedury skladownej"? Zresztą, nevermind...
Oj, drobne przeklawiaturowanie. Chyba żeby podjąć temat czy trigger to
rodzaj procedury skladownej czy może nie. Tylko powiedz, ze nie, bo
nie będzie punktu zaczepienia ;-)
Post by wloochacz
Post by ZbyszekZ
Wcale sie nie spieram bo mowimy to samo :-) tyle że innymi slowami
(slownik by sie przydal).
taa... pewnie nie tylko słownik, co homogeniczny aparat pojęciowy, co? ;-)
Może by otworzyć projekt? Dla platformy jazz(*) oczywiście, mogło by
być całkiem użyteczne. Taki automat "prostujący" zapiski zepsołu i
pacjentów.


--
***@private

(*) nie zebym mial jakas fiksacje, ale radio na stacje Jazz mam
ustawione
wloochacz
2008-09-26 15:06:09 UTC
Permalink
ZbyszekZ pisze:
[ciach]
Post by ZbyszekZ
Pewnie jednak pracuje i gdzie indziej ma fanaberie :-)
Pewnie że pracuje, bo na oszołomów jest zawsze zapotrzebowanie ;-)
Post by ZbyszekZ
Post by wloochacz
No to co piszesz, że "toz idealne a nawet wzorcowe, zadanie dla
procedury skladownej"? Zresztą, nevermind...
Oj, drobne przeklawiaturowanie. Chyba żeby podjąć temat czy trigger to
rodzaj procedury skladownej czy może nie.
Tak.
Post by ZbyszekZ
Tylko powiedz, ze nie, bo nie będzie punktu zaczepienia ;-)
No jak nie jak tak! :)
Post by ZbyszekZ
Post by wloochacz
Post by ZbyszekZ
Wcale sie nie spieram bo mowimy to samo :-) tyle że innymi slowami
(slownik by sie przydal).
taa... pewnie nie tylko słownik, co homogeniczny aparat pojęciowy, co? ;-)
Może by otworzyć projekt? Dla platformy jazz(*) oczywiście, mogło by
być całkiem użyteczne. Taki automat "prostujący" zapiski zepsołu i
pacjentów.
No to załóż, bo ja laik jestem :)
Post by ZbyszekZ
(*) nie zebym mial jakas fiksacje, ale radio na stacje Jazz mam
ustawione
Za młody jestem na Jazz :D
--
wloochacz
ZbyszekZ
2008-09-28 15:05:25 UTC
Permalink
Post by wloochacz
Post by ZbyszekZ
Post by wloochacz
Post by ZbyszekZ
Wcale sie nie spieram bo mowimy to samo :-) tyle że innymi slowami
(slownik by sie przydal).
taa... pewnie nie tylko słownik, co homogeniczny aparat pojęciowy, co? ;-)
Może by otworzyć projekt? Dla platformy jazz(*) oczywiście, mogło by
być całkiem użyteczne. Taki automat "prostujący" zapiski zepsołu i
pacjentów.
No to załóż, bo ja laik jestem :)
Założenie projektu to najmnieszy problem, trzeba najpierw przemyślec
pare punktow.
Poczynajac co ma byc faktycznie celem :-)
aczkolwiek Twoja nazwa brzmi dobrze ;-)
Jak by to bylo w language:
Homoegeus notion engine ?
Post by wloochacz
Post by ZbyszekZ
(*) nie zebym mial jakas fiksacje, ale radio na stacje Jazz mam
ustawione
Za młody jestem na Jazz :D
Tak, to chyba przychodzi z wiekiem. Zawsze myślałem że mam pierwszy
stopien sluchu muzycznego, ale wczoraj ogladajac jakis program
przyszlo mi na mysl ze moze jednak drugi? Byly takie utwory ze
spiewali a ja sluchac nie moglem ;-)

--
***@private
Norbert
2008-09-28 15:14:23 UTC
Permalink
Post by ZbyszekZ
Post by wloochacz
Za młody jestem na Jazz :D
Tak, to chyba przychodzi z wiekiem. Zawsze myślałem że mam pierwszy
stopien sluchu muzycznego, ale wczoraj ogladajac jakis program
przyszlo mi na mysl ze moze jednak drugi? Byly takie utwory ze
spiewali a ja sluchac nie moglem ;-)
Posluchaj Diamandy Gallas to moze i o trzecim pomyslisz ;-P
--
pozdrawiam
Norbert
ZbyszekZ
2008-09-28 17:46:14 UTC
Permalink
Post by Norbert
Post by ZbyszekZ
Post by wloochacz
Za młody jestem na Jazz :D
Tak, to chyba przychodzi z wiekiem. Zawsze myślałem że mam pierwszy
stopien sluchu muzycznego, ale wczoraj ogladajac jakis program
przyszlo mi na mysl ze moze jednak drugi? Byly takie utwory ze
spiewali a ja sluchac nie moglem ;-)
Posluchaj Diamandy Gallas to moze i o trzecim pomyslisz ;-P
Ok, ok, pozostaję przy pierwszym. ;-) widocznie za dużo wiśniówki
próbowałem.

--
***@private

Loading...