Witam,

mam aplikację napisaną w php i częściowo w z javascript. Aplikacja powstawała rok czasu i wydaje mi się, że za około rok czasu będę mógł spróbować ją rozprowadzać komercyjnie. W związku z tym wybiegając w przyszłość mam następujące problemy i pytania:

1. Czy można połączyć aplikację znajdującą się na moim serwerze z lokalną bazą danych MySQL instalowaną przez użytkownika ? - chodzi o to, że ilość danych przechowywanych w bazie przez jednego użytkownika będzie bardzo duża, a także treść danych bardzo poufna i chciałbym się uwolnić zarówno od ciężaru przechowywania tak dużych danych jak i ryzyka, że te dane ktoś wykradnie/usunie/ja usunę/ja wykradnę. Dane będą dotyczyć chorób pacjentów, a także ich danych więc lokalna baza rozwiązywałaby sprawę.

2. Połączenie z taką bazą powinno odbywać się dość pewnie tzn. niezależnie od zmiennego ip, 30 routerów po drodze - może być ewentualnie tak, że przy każdym logowaniu użytkownik wpisuje ip, albo coś, ale najlepiej byłoby gdyby istniało rozwiązanie połączenia bez takich zabiegów.

3. Jeśli powyższe 2 punkty nie są możliwe do zrealizowania, to czy kompilacja php wpływa na wydajność - wymyśliłem, że zamiennie można spróbować instalować na serwerze danego użytkownika / klienta serwer php i bazę danych i instalować u niego skompilowany php.

Co tym sądzicie ? Czy jest to o czym napisałem możliwe, czy lepiej kupić jakiś serwer dedykowany i zainwestować (wydaje mi się, że sporo pieniędzy) w bezpieczeństwo ?

Ad 1,2 można, ale to jest kompletnie bez sensu. Próbując sprzedać takie rozwiązanie narazisz się jedynie na śmieszność....
Ad 3 kompilacja może jedynie podnieść wydajność

Pojęcie "bardzo duża ilość danych" jest bardzo względne. Czasem milion rekordów to bardzo mało, a czasem bardzo dużo.
Serwer dedykowany wcale nie musi być tańszy. Bardzo często widzę sprawnie działające serwery zbudowane ze zwykłych komputerów stacjonarnych. Na allegro również widzę oferty typu http://allegro.pl/serwer-dedykowany-i3-212...2404997306.html To nie jest architektura serwerowa, a może działać solidnie.
Do tego awaryjność i szybkość łącza internetowego ...

1. Bardzo duża ilość danych - u mnie ok. 5 - 15 GB rocznie na użytkownika.
2. Rozwiązanie z bazą danych lokalnie na komputerze, akurat jest korzystniejsze dla użytkownika, którym byłby lekarz. Nie musiałby brać zgody pacjenta na udostępnianie danych pacjenta np. mi - chcąc nie chcąc prawnie musi taka zgoda się pojawić, jeśli mam mieć dostęp do bazy. Lokalna baza rozwiązuje ten problem - więc myślę, że nikt by mnie nie wyśmiał
3. Serwer dedykowany nawet dużo droższy nie jest problemem. Raczej myślałem, że dużym kosztem byłoby utrzymanie informatyka specjalizującego się w zabezpieczeniach.

Podsumowując, najlepszym rozwiązaniem byłoby to z pkt nr 1, tylko jak to zrobić, aby to działało mimo routerów itd...

Uprość sobie życie. Zainstaluj klientowi apache, php i mysql na jego lokalnym kompie i niechaj uruchamia aplikację z localhosta

Więc teraz należy odpowiedzieć na pytanie: Jakie parametry powinien mieć komputer pełniący rolę serwera danych aby czas odpowiedzi był wystarczająco szybki??
Gdybym miał spekulować...... to powiem, że za 100.000 zł takiego komputra może da się kupić......
Obawiam się, że rozwiązanie, które proponujesz wymaga głębokiej modyfikacji.....

Przeczytaj może ten wątek
http://forum.php.pl/index.php?showtopic=197240&hl=

Właśnie taki był mój pomysł, tylko nie chciałbym, żeby ktoś skopiował moją aplikację, dlatego wymyśliłem, że aplikacja będzie online, a baza lokalnie na dysku. Tylko jak zapewnić stałe połączenie niezależnie od routerów itd...



Te dane mimo wielkiej ilości, nie będą często wykorzystywane. Może opiszę co i jak:

Aplikacja służy do zarządzania gabinetem ortodontycznym. Podczas wizyty każdego pacjenta poza danymi tekstowymi, które są używane często, zapisuje się również zdjęcia wewnątrzeustne i zewnątrzustne. To właśnie te zdjęcia są problemem. Zdjęcia służą raczej jako dokumentacja i nie są często otwierane. Osobiście nie za bardzo znam się na jakiś tunelowaniach itd... Ale myślałem, że jezeli udałoby się korzystać bazy danych zapisanej na twardym dysku, lub jakoś korzystać ze zdjęc zapisanych na twardym dysku, żeby to było płynne i zawsze dobrze działało, to problem byłby rozwiązany.

Właśnie przyszło mi do głowy jeszcze jedno rozwiązanie (4). Użytkownik wpisuje w opcjach ścieżkę do zdjęć i w mysql zapisuje się ta ścieżka w ten sposób: file://c:/plik.jpg - jest to najsłabszy pomysł, ponieważ ucina mi możliwość np. kadrowania zdjęć.

Czyli dalej dylemat

1 - kompilować i instalować wszystko u klienta - gorsze rozwiązanie ze względu na to, że chciałem wprowadzić płatność miesięczną - stracę częściowo kontrolę nad programem

2. "Jakoś" - łączyć się z bazą danych po stronie usera - tak byłoby najlepiej

3. Korzystać z plików zapisanych na u usera na dysku file://c:/plik.jpg - też mało eleganckie rozwiązanie i jakieś takie mało stabilne.

- ale dzisiaj miejsce na dysku nie jest chyba jakimś szczególnym problemem?

- chyba nie chcesz zapisywać zdjęć w bazie danych?

Zdjęcia można skompresować a nawet jeśli będzie to 10 GB zdjęć na jednego użytkownika rocznie (co wydaje mi się absurdem, bo nawet jak zdjęcie będzie miało 10MB to użytkownik musiałby wrzucać kilka zdjęć dziennie). I przy założeniu, że użytkowników będzie tysiąc wystaczy dysk jeden tera, a dzisiaj jeden tera przestrzeni dyskowej to nie jest chyba lot na Marsa?

A jeśli aplikacja działa na zasadzie pomysłu "a, napisze sobie arkusz kalkulacyjny w PHP i JS" to ja się pytam po co? Czy użyta technologia jest tutaj właściwa? Jeśli to ma być tylko aplikacja do zarządzania pacjentami na komputerze użytkownika to jaki sens używać do tego PHP i JS?

Może zacznijmy od początku.
Dla kogo przeznaczona jest ta aplikacja?
Jeżeli jest to serwis przeznaczony dla pojedynczego gabinetu ortodontyczny (jeden ortodonta i jego pacjenci) stosowanie php jest znakomitym przykładem wyboru niewłaściwej technologii do realizacji zadania.

Wykorzystanie tej technologii jest słuszne, gdy z tej samej bazy danych korzysta wiele różnych gabinetów. W tym przypadku gdy pacjent przychodzi do dowolnego gabinetu lekarz może uzyskać informacje o pełnej historii leczenia chorego (kwestie prawne do rozstrzygnięcia). Rozwiązanie takie niewątpliwie stanowi przyszłość w systemie opieki zdrowotnej naszego kraju, a w wielu innych już funkcjonuje. Jest to do wprowadzenia w skali gabinetu, przychodni, kraju.
Szpitale w większości posiadają już systemy informatyczne umożliwiające dostarczenie pełnej informacji o historii pacjenta w danej placówce. Lekarze dostają gotowe informacje o grupie krwi, leczeniu na innych oddziałach, wynikach wcześniejszych badań i zabiegów itd. Jest to kluczowy system w dużych placówkach leczniczych. Pamiętać należy, że pacjent nie wszystko wie, nie wszystko rozumie, czasem jest nieprzytomny itd

Jeżeli Twoje rozwiązanie jest przeznaczone dla jednego ortodonty, to nie należy oczekiwać, że będzie on posiadał komputer zdolny do obsługi bazy danych o rozmiarze 70GB, więc pomysł z bazą danych u klienta, a serwerem web u dostawcy nie ma szans powodzenia.

Jeżeli jest to rozwiązanie dla przychodni (szpitala) to nie ma żadnego powodu, aby uzależniać działanie kluczowego systemu informatycznego od sprawności łącza internetowego jakie posiada dana placówka. Jeżeli placówka taka wyłoży duże pieniądze na serwer danych, czemu nie miała by kupić maszyny za trzy tysiące na serwer www?

W tym przypadku nie jest problemem miejsce na dysku lecz ilość RAM i zdolności obliczeniowe. Polecam wygenerowanie zobie testowej bazy danych o rozmiarach kilku GB i odpalenie tej aplikacji. Życie pokaże.....

Rozmiar bazy danych sugeruje nierozsądną jej konstrukcję. Istnieją już programy dla gabinetów stomatologicznych przechowujących pełne historie leczenia ze zdjęciami i nie mają one takich wymagań.

Wybaczcie, ale rozważania teoretyczne nad przydatnością takiego rozwiązania pozostawię sobie. Jak pisałem wcześniej aplikacja jest pisana od roku i już się sprawdziła. Moje pytanie postawione w pierwszym poście było inne - zastanawiałem się nad możliwością połączenia z lokalną bazą danych. Czy ktoś zna odpowiedź na tak postawione pytanie ?

Jeżeli można, to w jaki sposób można wykonać takie połączenie.

Odnośnie samej aplikacji, to obecnie korzysta z niej kilkanaście osób, jednak przed wejściem na rynek jako komercyjna aplikacja, chciałbym móc zapewnić prawidłowe działanie dużym gabinetom, które są z wiadomych względów lepszymi klientami, niż pojedyncze małe placówki.


Jeszcze raz bardzo proszę o trzymanie się tematu, zamiast rozważać sens aplikacji, pracy, życia

Tak sobie myślę, że prosto połączysz się z taką bazą danych zainstalowaną na komputerze klienta, jeśli ma on stałe, publiczne IP (no i szybkie łącze może być potrzebne do normalnej pracy). A jeśli ma zmienne, prywatne IP (za NATem), no to cóż, ciekawe zagadnienie do rozpracowania.

Skoro to takie poufne dane, to połączenie powinno być szyfrowane.

Tylko obawiam się, że te dane przechowywane u klienta, będą 100-1000x bardziej narażone na utratę/kradzież, niż gdyby były przechowywane na Twoim serwerze... ale jak rozumiem, nie będzie to już Twój problem.

I jeszcze dochodzi sprawa wykonywania backupów tych danych u klienta.

A nie możesz np. trzymać tych wszystkich danych/zdjęć na swoim serwerze, ale zaszyfrowanych w ten sposób, że dane do odszyfrowania pobierane są z aplikacji użytkownika (bądź kluczem szyfrującym będzie jakaś kombinacja loginu/hasła użytkownika, którą tylko on zna). Zakładając, że nie zapiszesz w swoim systemie nigdzie tego hasła użytkownika, to w ten sposób zabezpieczysz się w dużej mierze przed możliwością wykradzenia tych danych ze swojego serwera. Najlepiej było by tu używać kluczy publicznych/prywatnych do szyfrowania/odszyfrowywania. Albo można napisać applet w Java, który będzie pobierał takie zaszyfrowane dane i po odszyfrowaniu u klienta w przeglądarce, wyświetlał mu na stronie (czyli nawet by user nie wysyłał przez sieć hasła do odszyfrowania). Wszystko na SSL.

A jak to robi np Skype ?

Baza danych u klienta ma przede wszystkim taką zaletę, że nie trzeba wysyłać tych zdjęć na serwer. Dużo osób ma wolny wysył i przesłanie 9x ilość pacjent x 1Mb jest dość czasochłonne na wolniejszych łączach.

Szyfrowanie - dzięki za dobry pomysł, to jest podstawowa sprawa, a ja do tej pory o tym nie myślałem.

Jeżeli chodzi o sam pomysł, to wydaje mi się, że błędnie myślisz większość komputerów nie ma się co oszukiwać to windows, mysql postawisz jako usługę pomijam już samą instalację którą pewnie ty sam będziesz przeprowadzał ale co gdy usługa padnie z niewyjaśnionych przyczyn ? Jeżeli twoja aplikacja ma 15 stronicowy formularz a usługa bazy danych padnie to klient się wkurzy bo albo będzie musiał zrestartować mysql przez linie komend, albo zresetować komputer. Drugi minus postępując w ten sposób zmuszasz klienta do pozostawienia komputera 24h online. Bo to, że baza jest na komputerze w domu nie znaczy, że nie będzie on chciał ze strony skorzystać ze smartfona, laptopa, komputera w pracy itp.

Sam problem połączenia z bazą jest prosty

[PHP] pobierz, plaintext 
 
$user='xxx';
$pass='yyy';
$dbh = new PDO('mysql:host=ip.klienta;port=port_bazy;dbname=baza', $user, $pass);
[PHP] pobierz, plaintext 

takie coś zadziała, jeżeli ip jest dostępne z zewnątrz jest stałe. Jeżeli klient ma router, musisz mu skonfigurować przekierowanie portów, jeżeli ma zmienne ip hmm nigdy nie próbowałem ale być może serwisy typu DynDNS lub rozwiązania VPN tutaj pomogą.

Następny minus to oczywiście nadzór nad wersją mysql, jeżeli masz 50 klientów, i wychodzi 0-day na wersję mysql którą im zainstalowałeś to albo świadomie wystawiasz ich na atak albo w panice biegasz i aktualizujesz im serwer (sami raczej tego nie zrobią) nie ma się co łudzić, że to nigdy nie nastąpi należy się modlić żeby klientów było niewielu.

Co do bezpieczeństwa to nawet nie ma sensu się rozpisywać pierwsza lepsza wizyta w serwisie z komputerem na którym stoi serwer i ciekawski pan serwisant (lub syn kolegi po liceum informatycznym) będzie miał dostęp do bazy danych.

Jak to robi skype ? bardzo prosto , odpalasz klienta na komputerze wpisujesz login i hasło, serwer skype zapisuje twój adres ip, jeżeli adres ip się zmieni podejrzewam , że klient wyślę aktualizację do serwera z nowym adresem.