Można używać programu do obsługi baz danych, który pracuje bezpośrednio na plikach, jak np. SQLite, w wersji zdalnych plików - w dowolnym miejscu, znaczy: mamy dostęp do bazy z dowolnego miejsca na świecie?
0
1
Brzmi na problem X/Y - dlaczego chciałbyś coś takiego robić?
2
Tak, jak napisał @AnyKtokolwiek - ten pomysł jest bardzo średni. Niemniej nie ma technicznych przeciwwskazań, żeby go wdrożyć. Jedynie musisz ogarnąć w jakiś sposób dostęp zdalny do tego pliku - np. jakiś udział SMB/NFS wystawiony na świat (bardzo nie polecam, ale teraz nie zastanawiamy się, czy to ma sens, tylko czy się da), albo jakieś wpinanie sie przez VPN.
Ogólnie - jeśli z poziomu komputera, który ma korzystać z bazy plik będzie widoczny, z możliwością zapisu i odczytu, to da się z niego korzystać. Ale to głupie, niebezpieczne, mało wydajne i ... ogólnie ciężko mi znaleźć jakiekolwiek plusy tego rozwiązania. Może poza jednym - że to będzie (jakoś) działać. Lepiej napisz, jak sugeruje @Patryk27, o co chodzi i w czym jest problem, bo mamy wrażenie, że kombinujesz na siłę z dziwnymi rozwiązaniami, a pewnie da się to zrobić o wiele lepiej, niż Ty sobie to wymyśliłeś.
0
Patryk27 napisał(a):
Brzmi na problem X/Y - dlaczego chciałbyś coś takiego robić?
Po to aby mieć dostęp do swojej bazy danych: w dowolnym czasie i z dowolnego miejsca.
4
Dlaczego zatem nie wykorzystasz rzeczywistej bazy danych w architekturze klient-serwer (np. Postgresql)?
0
Aby mieć dostęp z dowolnego miejsca w dowolnym czasie to kupujesz hosting, kosztuje to kilkadziesiąt PLN na rok, na nim już masz odpalonego jakiegoś MySQL, czyli prawdziwą bazę SQL.
Jedyny problem może być taki, że hostingi (zwłaszcza te tańsze) często mają blokadę zdalnych połączeń. Da się korzystać z takich baz pisząc np. w PHP, które jest odpalane na tym samym serwerze, ale jakbyś chciał się podłączyć przy wykorzystaniu np. aplikacji desktopowej, to z dużym prawdopodobieństwem tak się nie uda.
Jakbyś bardziej szczegółowo opisał swój przypadek/problem, to łatwiej by było coś sensownego doradzić.
0
Chyba nie czujecie problemu.
jest już gotowa aplikacja do obsługi bazy na Windows, która działa na plikach,
co znaczy że ona używa openfile, read, write, lock, itp. funkcje do obsługi plików.
Zagadnienie:
czy ta aplikacja - bez modyfikacji, może nadal działać, tyle że na plikach które leżą gdzieś w internecie, zamiast na lokalnym dysku?
0
No to Ci odpowiedzieliśmy - da się to zrobić, ale to jest bardzo zły pomysł. Trochę jak (autentyczna sytuacja - dzisiaj mi koleżanka z pracy pokazała dzieło wybitnego fachowca, który "naprawił" samochód jej matki) podłączenie w samochodzie zamiast przewodu olejowego, kawałka węża ogrodowego. Niby będzie działać, ale tak się nie powinno postępować :D
3
będzie działać, ale niezgodnie z prawem - tak? zabawny jesteś.
Nie o to chodzi, tylko takie rozwiązanie będzie niezgodne z zasadami sztuki (na to jeszcze można przymknąć oko, bo czasami da się pewne rzeczy nagiąć i nic złego się nie dzieje), ale przede wszystkim będzie:
- mało wydajne (uzależnione od prędkości obu łączy, które będą wykorzystane)
- awaryjne: transfer pliku może się przerwać/plik może się uszkodzić (np. zerwane połączenie w połowie przesyłu)
- w wypadku dużych plików ich przesył może być tak długotrwały, że mogą występować jakieś timeouty
- dostęp jednoczesny przez więcej niż 1 użytkownika może być bardzo utrudniony.
Oczywiście - to wszystko zależy, bo jeśli plik waży np. 2MB, a korzystasz z łącza 500/100MBit, to będzie działać prawie, jakby to było odpalone lokalnie. Gorzej, jeśli plik z bazą ma kilkadziesiąt MB, a łącze to jakiś DSL 40/4Mbit - wtedy widzę wiele potencjalnych problemów. Niestety, powtórzę - dałeś za mało konkretów, więc to są tylko domysły.
0
cerrato napisał(a):
będzie działać, ale niezgodnie z prawem - tak? zabawny jesteś.
Nie o to chodzi, tylko takie rozwiązanie będzie niezgodne z zasadami sztuki (na to jeszcze można przymknąć oko, bo czasami da się pewne rzeczy nagiąć i nic złego się nie dzieje), ale przede wszystkim będzie:
- mało wydajne (uzależnione od prędkości obu łączy, które będą wykorzystane)
- awaryjne: transfer pliku może się przerwać/plik może się uszkodzić (np. zerwane połączenie w połowie przesyłu)
- w wypadku dużych plików ich przesył może być tak długotrwały, że mogą występować jakieś timeouty
- dostęp jednoczesny przez więcej niż 1 użytkownika może być bardzo utrudniony.
Oczywiście - to wszystko zależy, bo jeśli plik waży np. 2MB, a korzystasz z łącza 500/100MBit, to będzie działać prawie, jakby to było odpalone lokalnie. Gorzej, jeśli plik z bazą ma kilkadziesiąt MB, a łącze to jakiś DSL 40/4Mbit - wtedy widzę wiele potencjalnych problemów. Niestety, powtórzę - dałeś za mało konkretów, więc to są tylko domysły.
Chodzi o dostęp do bazy danych, a nie o transfer całych plików.
Cała baza danych ma rozmiar 100MB, powiedzmy, i nieważne czy to jest jeden plik, czy 600.
4
czy ta aplikacja - bez modyfikacji, może nadal działać, tyle że na plikach które leżą gdzieś w internecie, zamiast na lokalnym dysku?
Zależy od aplikacji - niejednokrotnie aplikacje pisane z myślą o działaniu na pojedynczym komputerze (a nie konkretnie przez sieć) nie obsługują prawidłowo rzeczy takich jak timeout'y, zrywanie połączeń w trakcie przesyłu czy konkurencyjność (głównie dlatego, że tych problemów praktycznie nie ma w przypadku zapisu danych na lokalny dysk twardy).
Tak naprawdę bez analizy kodu aplikacji nie da się stwierdzić nic ponad może, ale raczej nie, ale może.
0
Patryk27 napisał(a):
czy ta aplikacja - bez modyfikacji, może nadal działać, tyle że na plikach które leżą gdzieś w internecie, zamiast na lokalnym dysku?
Zależy od aplikacji - niejednokrotnie aplikacje pisane z myślą o działaniu na pojedynczym komputerze (a nie konkretnie przez sieć) nie obsługują prawidłowo rzeczy takich jak timeout'y, zrywanie połączeń w trakcie przesyłu czy konkurencyjność (głównie dlatego, że tych problemów praktycznie nie ma w przypadku zapisu danych na lokalny dysk twardy).
Tak naprawdę bez analizy kodu aplikacji nie da się stwierdzić nic ponad
może, ale raczej nie, ale może.
Aplikacja działa niezawodnie na swoich plikach, nie ma znaczenia liczba użytkowników.
Używa zwyczajnego blokowania plików (w trybie wirtualnym) w celu uniknięcia jednoczesnego wpisywania do plików.
Lock -> modify -> Unlock.
2
Co to jest zwyczajne blokowanie plików (w trybie wirtualnym)?
2
Chodzi o dostęp do bazy danych, a nie o transfer całych plików.
Ale to nie jest takie proste, bo równie dobrze najpierw aplikacja może próbować wczytać cały plik do pamięci, a dopiero potem zacząć na nim działać. Poza tym inaczej system plików działa z plikami na dysku lokalnym, a inaczej na sieciowym.
0
Patryk27 napisał(a):
Co to jest
zwyczajne blokowanie plików (w trybie wirtualnym)?
To znaczy że blokowanie jest dostateczne = minimalne dla zachowania integralności danych.
0
cerrato napisał(a):
Chodzi o dostęp do bazy danych, a nie o transfer całych plików.
Ale to nie jest takie proste, bo równie dobrze najpierw aplikacja może próbować wczytać cały plik do pamięci, a dopiero potem zacząć na nim działać. Poza tym inaczej system plików działa z plikami na dysku lokalnym, a inaczej na sieciowym.
Przecież nie mówimy o nadzorowaniu działania systemu operacyjnego.
3
To znaczy że blokowanie jest dostateczne = minimalne dla zachowania integralności danych.
Ok, ale dla mnie to nic nie znaczy; opowiadasz z punktu widzenia marketingowego, nie technicznego, dlatego też nie jestem Ci w stanie nic sensowniejszego podpowiedzieć.
0
Patryk27 napisał(a):
To znaczy że blokowanie jest dostateczne = minimalne dla zachowania integralności danych.
Ok, ale dla mnie to nic nie znaczy; opowiadasz z punktu widzenia marketingowego, nie technicznego, dlatego też nie jestem Ci w stanie nic sensowniejszego podpowiedzieć.
Wspomniałem na wstępie, że program pracuje na sofcie typu: SQLite,
a jak wiadomo SQLite gwarantuje w 100% integralność bazy danych na której pracuje;
takie coś robi się za pomocą tzw. transakcji, czyli operacji atomowych - niepodzielnych: wszystko albo nic.
1
Można używać programu do obsługi baz danych, który pracuje bezpośrednio na plikach, jak np. SQLite, w wersji zdalnych plików - w dowolnym miejscu, znaczy: mamy dostęp do bazy z dowolnego miejsca na świecie?
Jak masz jakiś NFS/Network File System, to taki program nawet nie będzie wiedział że działa na pliku który jest zdalny, wiec tak, nie powinno być problemów. Rozwiazanie raczej bardzo dziwne i bez sensu, ale to przecież @bonifacy więc nie spodziewam się zobaczyć tu czegoś co ma sens.
1
bonifacy napisał(a):
a jak wiadomo SQLite gwarantuje w 100% integralność bazy danych na której pracuje;
Ale nie w sytuacji, w której zerwie się połączenie sieciowe i plik bazy SQL jest urwany w połowie.
takie coś robi się za pomocą tzw. transakcji, czyli operacji atomowych - niepodzielnych: wszystko albo nic.
Tak, tylko zarówno system operacyjny, system plików, protokół sieciowy jak i aplikacja muszą to wspierać.
0
Shalom napisał(a):
Można używać programu do obsługi baz danych, który pracuje bezpośrednio na plikach, jak np. SQLite, w wersji zdalnych plików - w dowolnym miejscu, znaczy: mamy dostęp do bazy z dowolnego miejsca na świecie?
Jak masz jakiś NFS/Network File System, to taki program nawet nie będzie wiedział że działa na pliku który jest zdalny, wiec tak, nie powinno być problemów. Rozwiazanie raczej bardzo dziwne i bez sensu, ale to przecież @bonifacy więc nie spodziewam się zobaczyć tu czegoś co ma sens.
Właśnie o to chodzi żeby nie wiedział - ma robić nadal swoje i cześć.
System operacyjny ma udostępniać te zdalne pliki, a jak on zrobi to już nie moja sprawa.
somekind napisał(a):
bonifacy napisał(a):
a jak wiadomo SQLite gwarantuje w 100% integralność bazy danych na której pracuje;
Ale nie w sytuacji, w której zerwie się połączenie sieciowe i plik bazy SQL jest urwany w połowie.
Niby co miałoby się wtedy stać?
Transakcja nieukończona = zero: brak jakichkolwiek zmian danych, czyli jest OK.
takie coś robi się za pomocą tzw. transakcji, czyli operacji atomowych - niepodzielnych: wszystko albo nic.
Tak, tylko zarówno system operacyjny, system plików, protokół sieciowy jak i aplikacja muszą to wspierać.
No to się właśnie o to pytam!:
czy obecne systemy operacyjne są zdolne do udostępniania zdalnych plików w internecie - globalnie?
Tak/Nie?
Jeśli TAK, to jak to należy skonfigurować w Windowsie, np. 7 czy 10?
2
bonifacy napisał(a):
Niby co miałoby się wtedy stać?
Transakcja nieukończona = zero: brak jakichkolwiek zmian danych, czyli jest OK.
No wtedy stanie się coś takiego, że plik będzie zepsuty, więc SQLite nawet nie uzna go za bazę danych.
Zapis pliku na dysku przez system operacyjny to zupełnie inna operacja niż wstawianie danych do bazy w tymże pliku przez sterownik SQLite.
Nie prościej zrealizować to jakimś OneDrive czy inną chmurą plikową?
0
somekind napisał(a):
bonifacy napisał(a):
Niby co miałoby się wtedy stać?
Transakcja nieukończona = zero: brak jakichkolwiek zmian danych, czyli jest OK.No wtedy stanie się coś takiego, że plik będzie zepsuty, więc SQLite nawet nie uzna go za bazę danych.
Zapis pliku na dysku przez system operacyjny to zupełnie inna operacja niż wstawianie danych do bazy w tymże pliku przez sterownik SQLite.
Niby dlaczego poprawny i nienaruszony plik miałby zostać zepsuty?
Podczas transakcji jest realizowany scenariusz w stylu:
lock, a potem leci: write, write, ... i na końcu: unlock (i + flush ewentualnie).
zatem każdy normalny system powinien to realizować poprawnie,
co znaczy że od momentu:
lock, system ma czekać na unlock, zanim zacznie zapisywać na dysk... a nie od razu!
co znaczy że w międzyczasie musi buforować te zapisywane dane, a nie walić prosto w pliki!
Proste?
Nie prościej zrealizować to jakimś OneDrive czy inną chmurą plikową?
To nie jest aplikacja dla dzieci...
7
Ja tylko nie rozumiem, czemu w ogóle pytasz o coś na forum, skoro masz taką wybitną wiedzę? :)
0
Pytam bo nie znam perfekcyjnie możliwości obecnych systemów, np. Linuks, android, itp. pierdoły.
A generalnie wiadomo po co: szukam dobrej konkurencji... do zatrudnienia w moim biznesie.
3
bonifacy napisał(a):
lock, a potem leci: write, write, ... i na końcu: unlock (i + flush ewentualnie).
zatem każdy normalny system powinien to realizować poprawnie,
co znaczy że od momentu:
lock, system ma czekać na unlock, zanim zacznie zapisywać na dysk... a nie od razu!co znaczy że w międzyczasie musi buforować te zapisywane dane, a nie walić prosto w pliki!
To się wywala nawet na jednym komputerze, a co dopiero w rozproszonym systemie, wystarczy ubić aplikację/system przy flushowaniu (i buforowanie nic tu nie da, bo bufory mogą być utracone albo race condition może zapisać je wielokrotnie itp). To da się zrobić ze wsparciem transakcyjnego modyfikowania plików albo innymi sztuczkami na systemie plików (na przykład dwie wersje pliku + wskaźnik do aktualnej + podwójny zapis + podwójny odczyt), ale trudno powiedzieć, czy Twoja baza to robi (a jeżeli Twój opis jest zgodny ze stanem faktycznym, to tego nie robi).
Oczywiście przy bazie w jednym pliku wzrasta ryzyko awarii przez problemy sieciowe. Znowu przy wielu plikach wzrasta trudność zarządzania transakcją na plikach (i nie mówię tu o logicznej transakcji na danych, to jest trudność jeszcze wyżej).
SMB wspiera blokowanie plików, więc po prostu udostępnij katalog i próbuj.
1
Witam kolegę od "zabezpieczeń":
Z innego wątku autora.
MarekR22 napisał(a):
Brattanek napisał(a):
Generalnie dopiero zaczynam przygodę z C++
Szczerze to wszyscy się tego domyślaliśmy.
Głownie początkujący, bujają w obłokach, rozmyślają o wielkich sukcesach swoich dzieł i zanim je zrealizują, zamartwiają się, że ktoś ukradnie im pomysł, więc szukają różnych zapieczeń.
Nie zrobiłeś jeszcze kroków A B C, a już planujesz X Y Z.
1
Afish napisał(a):
bonifacy napisał(a):
lock, a potem leci: write, write, ... i na końcu: unlock (i + flush ewentualnie).
zatem każdy normalny system powinien to realizować poprawnie,
co znaczy że od momentu:
lock, system ma czekać na unlock, zanim zacznie zapisywać na dysk... a nie od razu!co znaczy że w międzyczasie musi buforować te zapisywane dane, a nie walić prosto w pliki!
To się wywala nawet na jednym komputerze, a co dopiero w rozproszonym systemie, wystarczy ubić aplikację/system przy flushowaniu (i buforowanie nic tu nie da, bo bufory mogą być utracone albo race condition może zapisać je wielokrotnie itp). To da się zrobić ze wsparciem transakcyjnego modyfikowania plików albo innymi sztuczkami na systemie plików (na przykład dwie wersje pliku + wskaźnik do aktualnej + podwójny zapis + podwójny odczyt), ale trudno powiedzieć, czy Twoja baza to robi (a jeżeli Twój opis jest zgodny ze stanem faktycznym, to tego nie robi).
Oczywiście przy bazie w jednym pliku wzrasta ryzyko awarii przez problemy sieciowe. Znowu przy wielu plikach wzrasta trudność zarządzania transakcją na plikach (i nie mówię tu o logicznej transakcji na danych, to jest trudność jeszcze wyżej).
SMB wspiera blokowanie plików, więc po prostu udostępnij katalog i próbuj.
Ale transakcyjność na tym, to już nie.
Transakcyjność trudno "próbować". Testy będzie przechodzić, ale się pie...e w najważniejszym momencie na produkcji.
2
bonifacy napisał(a):
Nie prościej zrealizować to jakimś OneDrive czy inną chmurą plikową?
To nie jest aplikacja dla dzieci...
Ale zrealizowana przez dzieci, nawet nie mające oglądu, co na rynku - zawężając, darmowym rynku - się dzieje i używa.
0
AnyKtokolwiek napisał(a):
Ale transakcyjność na tym, to już nie.
No to trzeba samemu wyklepać i tyle. To nie jest jakaś czarna magia (ale też nie jest prosta sprawa).