On 2011-06-28, Lukasz <k...@a...pl> wrote:
> ostatnio zastanawiam się nad poprawną architekturą aplikacji
> bazodanowej, by była bezpieczna. Nie rozważam tutaj kwestii że będzie to
> aplikacja na urządzenia mobilne, lub takie które mają bardzo ograniczone
> zasoby. Język C++, może z wykorzystaniem Qt, relacyjna baza danych.
> Program byłby pewną ewidencją na której wykonywałoby się odpowiednie
> operacje(dodaj, usuń rekord, wystaw dokument itp. - bez większej
> filozofii). Widzę dwa rozwiązania:
>
> 1) aplikacja w postaci grubego klienta - łączy się z bazą danych,
> wykonuje operacje, posiada wszelkie funkcjonalności.
>
> ZALETY:
> - mniej roboty, jeden program
>
> WADY:
> - słaby stopień bezpieczeństwa bo np. mamy 100 użytkowników i każdy
> program zna parametry dostępowe do bazy danych i można stosunkowo łatwo
> je podpatrzeć.

- Źle się synchronizuje dostęp przez wielu klientów.
- Na dłuższą metę duże problemy z aktualizacją (nie da się wyłączyć
klientów w starej wersji).

> 2) aplikacja typu cienki klient - na serwerze przy bazie danych byłby
> napisany serwer a klient jedynie wysyłałby żądania.
>
> ZALETY:
> - centralizacja dostępu,
> - możliwość autoryzacji i autentykacji na maszynie gdzie dostęp ma tylko
> admin,

Co to jest autentykacja? Chodzi ci o uwierzytelnianie?

> WADY:
> - konieczność stworzenie dwóch aplikacji: klient i serwer,
> - program klienta działa jedynie gdy jest on-line(ewentualnie byłbym
> ciekaw jak tutaj można coś zaradzić).

Uważasz że dostęp do centralnej bazy danych nie wymaga dostępu
sieciowego? Może za pomocą TTP, Telepathic Transmission Protocol?

> Przy okazji zapytam: jest sens np. trzymania zapytań tylko w aplikacji
> serwera? Chodzi mi o to że klient nic nie wie o zapytaniach a jedynie
> wysyła np. numer kontekstu z którego żądane są dane? Wtedy serwer
> wyszukuje u siebie kontekst i wie jakie ma być zapytanie - wykonuje je i
> wyniki odsyła do klienta. Dobry jest to zamysł czy przekombinowany?
> Jakie są alternatywy?

Alternatywą jest odbieranie zapytań SQL (albo ich dużych fragmentów) od
klienta, co jest niedorzeczne, albo stworzenie własnego języka zapytań,
co z kolei chyba przekracza twoje możliwości, skoro pytasz o komentarze
do architektury.

--
Secunia non olet.
Stanislaw Klekot