1

Temat: Interfejs dla użytkownika końcowego

Ostatnio edytowany przez zat3 (2013-09-17 13:17:37)

2

Odp: Interfejs dla użytkownika końcowego

o ile wiem to nic takiego dla postgresa nie istnieje. Proponuję jednak byś przemyślał swoją decyzję o współpracy Accessa z Postgresem przez ODBC, a przekonasz się, że to całkiem dobra kombinacja i tak naprawdę ułatwia programiście VB tworzenie nawet sporych projektów.

3

Odp: Interfejs dla użytkownika końcowego

1) Czy taka kombinacja jest sprawdzona?
2) Czy w jakiś sposób ogranicza ona możliwości działania na bazie (w sensie, czy czegoś nie da się w ten sposób zrobić, coś robi się trudniej etc.) ?
3) Czy nie ucierpi na tym bezpieczeństwo/integralność danych (w końcu przesyłamy je pomiędzy, że tak to ujmę, oprogramowaniem różnych producentów) ?
4) Czy coś jeszcze powinienem na ten temat wiedzieć?

O ile baza będzie dość prosta, to jednak jak już wspominałem, będzie to baza produkcyjna, która ma działać jak najdłużej i danych będzie codziennie przybywać. Nie mogę sobie pozwolić na ich uszkodzenie, dostępność też jest istotna. Naprawdę wolałbym ją zrobić w Postgresie, problemem jest wyłącznie ten interfejs dla "pani Basi".

Ostatnio edytowany przez zat3 (2013-09-17 22:24:27)

4

Odp: Interfejs dla użytkownika końcowego

Ad 1) Tak - sam wykonuję podobne projekty
Ad 2) musisz pamiętać, że możliwości Postgresa są dużo większe niż accessa, część typów danych z postgresa nie przeniesie się do accessa ale wszystkie typy danych accessa są w postgresie, tak więc jeśli wiesz co robisz to postgres w żaden sposób nie ogranicza accessa
Ad 3) Bezpieczeństwo danych w accesie jest bardzo niskie ale ponieważ ty zamierzasz budować bazę w oparciu o jeden komputer to nie ma to znaczenia bo nie zapewnisz wystarczającego bezpieczeństwa w nowym rozwiązaniu. (jeśli ktoś dostanie ten komputer w swoje ręce i będzie miał wystarczającą wiedzę to i tak dostanie się do danych)
- postgres ma w sobie zaszyte kilka ciekawych mechanizmów, które możesz wykorzystać by zwiększyć bezpieczeństwo
a) łączenie się za pomocą protokołu SSL
b) współpraca z ActiveDirectory
c) wewnętrzny filtr połączeń (firewall) (możesz określić, że np tylko konkretna maszyna lub użytkownik ma mieć prawo dostępu do twojej bazy danych)
d) replikacja danych - umożliwia dokonanie w locie aktualizowania wszystkich danych  z serwera produkcyjnego na inny serwer. Co daje Ci możliwość:
- zapewnienie bezpieczeństwa danych
- stworzenie serwera raportowego
- rozłożenie obciążenia na kilka serwerów
Ad 4) jeśli masz doświadczenie tylko z Accessem to jeszcze wiele przed tobą nauki

Co do bezpieczeństwa to nie ma innego sposobu jak wykonywanie cyklicznych backupów,a to w postgresie robi się jednym poleceniem systemowym (pamiętaj tylko by nie przechowywać backupów na tej samej maszynie na której pracujesz)

5

Odp: Interfejs dla użytkownika końcowego

Baza będzie na lokalnym serwerze - niezależnie od tego czy to będzie Access czy Postgres.

Jeśli Access, to po prostu plik accdb na udziale sieciowym.
Jeśli Postgres, to daemon na Linux'ie.

Bezpieczeństwo w sensie poufności/niezaprzeczalności jest tutaj nie istotne, zależy mi tylko na integralności danych - to się po prostu nie może zepsuć.

Ostatnio edytowany przez zat3 (2013-09-18 11:40:22)

6

Odp: Interfejs dla użytkownika końcowego

Stabilność pracy postgresa zainstalowanego na linux-sie jest bardzo dobra. Dla przykłady jak weszła wersja 8.4 postgresa to postawiłem serwer był to chyba 2009 rok, a wyłączyłem go 2 miesiące temu, przez ten czas poza wykonywaniem backupów nie dotykałem się do niego.

Niestety nie ma systemów niezawodnych w 100% jak padnie ci dysk to jeśli nie pracujesz na macierzy RAID to i tak masz po bazie, dlatego wykonuje się codzienne backupy i zadania konserwacyjne lub replikuje się bazę na inny serwer.

Sam musisz zadbać o bezpieczeństwo ale w porównaniu z Accessem to postgres jest super bezpieczny

Ostatnio edytowany przez c_michal (2013-09-18 23:43:30)

7

Odp: Interfejs dla użytkownika końcowego

RAID jest, co do replikacji, to rozumiem masz na myśli to, że mogę gdzieś postawić drugi serwer z Postgresem i zmiana na serwerze "głównym" powoduje automatyczną zmianę na serwerze "backupowym", dobrze rozumiem? Czy trudno jest zrobić taką replikację (z punktu widzenia konfiguracji Postgresa)?

Bardziej niż o przechowywanie boje się o błędy powstałe w wyniku interakcji tych dwóch środowisk - czyli np. przy przesyłaniu danych z Accessa do Postgresa, jakichś modyfikacjach itp. Gdyby to było robione w Access'ie, to tam jednak wszystko jest z założenia zintegrowane i powinno dobrze działać, tutaj natomiast mam wrażenie (nie wiem czy właściwe), że jest to podobna sytuacja jak uruchamianie Windows'owej aplikacji przez Wine (w sensie: to raczej działa, ale nie było pod tym kątem projektowane).

Proszę mi powiedzieć: czyli generalnie nie ma innego sposobu do zarządzania danymi w bazie danych (takiej jak Postgres, MySQL, MS SQL) niż napisanie własnej aplikacji, która by tymi danymi operowała? (oczywiście znowu nie mam tu na myśli pgAdmin'a itp.)

8

Odp: Interfejs dla użytkownika końcowego

co do replikacji to dobrze wszystko zrozumiałeś. Ale dla małej bazy danych nie robi się replikacji choć oczywiście można, co do trudności to zależy jak orientujesz się w linuxie i czy umiesz czytać dokumentację. Ogólnie mówiąc najpierw zacznij od wykonywania backupów a z replikacją zawsze zdążysz.

Co do drugiej części pytania to połączenie accessa jako klienta PostgreSQL działa bezbłędnie i na pewno nic na tym połączeniu nie stracisz, a wiele możesz zyskać.

Jak każda baza danych PostgreSQL (jak również Access)  ma za zadanie zarządzać i przechowywać dane użytkownika. Tak jak w Access-sie musisz stworzyć aplikacje (napisać formularze i oprogramować zdarzenia) tak i w innych aplikacjach wykorzystujących serwery SQL-owe musisz mieć aplikację, która będzie interfejsem dla użytkownika. Może to być aplikacja typu klient-serwer jak i klient www.

9

Odp: Interfejs dla użytkownika końcowego

Dołożę swoje 3 grosze
Ja również korzystam z połączenia Access - PostgreSQL , działa jak na razie bez zarzutu. Kiedyś myślałem nad PHP - rozwiązanie bardziej "mobilne" bez rozsyłania plików mde, zmiany w "kliencie" widoczne natychmiast. Ale raporty w Accessie to piękna sprawa, do tego jest to moje "uboczne" zajęcie, dlatego zostałem przy Accessie. PostgreSQL 8.4 na linux-ie (Debian) od 3 lat ciągła praca. Oczywiście nie jest to obciążona baza, jednocześnie max 8 użytkowników. Baza działa w sieci lokalnej, ale dostęp po VPN jest również szybki.

10

Odp: Interfejs dla użytkownika końcowego

Ostatnio edytowany przez zat3 (2013-09-20 00:08:32)

11

Odp: Interfejs dla użytkownika końcowego

12

Odp: Interfejs dla użytkownika końcowego

A powiedzcie mi jeszcze, czy jest możliwość eksportu bazy już stworzonej i utrzymywanej w Access'ie do Postgres'a?
Wiem, że jest możliwość eksportu tabeli via ODBC (zakładka 'Dane zewnętrzne' -> Więcej -> Baza danych ODBC), natomiast czy można już gotową bazę, wraz z relacjami, przenieść do Postgresa?

Ostatnio edytowany przez zat3 (2013-09-20 20:01:35)

13

Odp: Interfejs dla użytkownika końcowego

Nie wiem czy z relacjami się da. Już nie pamiętam, ale chyba tworzyłem tabele na PostgreSQL na wzór Access-a, pola autonumer najpierw były jako integer żeby numeracja się nie skopała jeżeli była do relacji. Później wysłanie tabeli do bazy przez ODBC, zaciągnięcie tych danych poprzez insert do docelowej tabeli, zmiana pola z integer na serial, ustawienie sekwencji pola żeby szła od numeru o jeden większy niż końcowy w tabeli. Później relacje.

14

Odp: Interfejs dla użytkownika końcowego

OK Panowie, bardzo Wam dziękuję za wskazówki, zabiorę się do tematu w chwili wolnego. Pozdrawiam!