Wspólna baza - realizacja dostępu

Mamy bazę danych, taką typową z biznesu: faktury, towary, pracownicy, itp.

Program czyta dane wprost z plików, w których są normalne tabele danych, niekiedy jakoś tam powiązane z lekka... wielkich cudów tu nie ma.

Można sobie łatwo uruchomić takie coś kilka razy - z kilku pecetów w sieci, i wówczas każdy miesza w tych bazach niezależnie, więc może się coś zrypać oczywiście.

I chodzi mi właśnie o sposób synchronizacji pomiędzy tymi procesami, ale niewielkim kosztem, w sensie modyfikacji aktualnego kodu.

Jak to jest realizowane w standardowych sys. bazodanowych na najniższym poziomie:
poprzez blokowanie plików, jakieś pipy, czy coś tam?

Załatwiłbym to muteksami, semaforami, itp., ale te nie działają w sieci pod Windows, tylko lokalnie, więc do kitu.

Normalnie to sie uzywa jakiejs bazy danych a nie plikow

@wilma żartujesz sobie? Zdajesz sobie sprawę z tego że są całe książki na ten temat? Nie pojmuje czemu nie trzymacie tego z zwykłej bazie.

Misiekd napisał(a)

Normalnie to sie uzywa jakiejs bazy danych a nie plikow

Bazy są trzymane w plikach.

Shalom napisał(a)

@wilma żartujesz sobie? Zdajesz sobie sprawę z tego że są całe książki na ten temat? Nie pojmuje czemu nie trzymacie tego z zwykłej bazie.

No, przecie trzymamy w bazie.
Nie ma tu serwerowców? Sami lamerzy od interfaców, czy jak?

wilma napisał(a)

Misiekd napisał(a)

Normalnie to sie uzywa jakiejs bazy danych a nie plikow

Bazy są trzymane w plikach.
Chodzi o to abyś użył silnika bazodanowego zamiast ręcznie realizować dostęp do danych. Skopałeś już na samym początku. Od teraz problemy zaczną się mnożyć w nieskończoność. Jak najprędzej przejdź na jakiś silnik bazodanowy zamiast samemu pisać takowy.

baza jest lokalnie na każdym PC czy gdzies na serwerze, a klienci się z nią tylko łączą? Jak to baza? MySQL? PostgreSQL?

misiakufal napisał(a)

baza jest lokalnie na każdym PC czy gdzies na serwerze, a klienci się z nią tylko łączą? Jak to baza? MySQL? PostgreSQL?

Tak jest: instalujesz program na swoim pc.
Chodzi i było robione na Windows, ale w Linuksie wystarczy dorzucić jakieś emulatory win i też zasuwa.

Ale można sobie łatwo uruchomić taki program zdalnie - z innego terminalna (na którym on w ogóle nie był instalowany!).
Wszystko normalnie działa, ale niekiedy zdarzają się kolizje... wiadomo.

Bazy są dość prymitywne, głównie proste tabele.
Wewnątrz leci obiektowo, jeden specjalny obiekt obraca te bazy plików,
więc wystarczy w jednym miejscu dorzucić jakąś synchronizację i cześć.

Pewnie można nawet łatwo zmienić te plikowe funkcje na bazodanowe i też gotowe,
ale wówczas te bazy trzeba by konwertować, no i serwery instalować w setkach MB...
zresztą to by zdechło ze 100 razy - ten program przekracza prędkość światła w działaniu.

wilma napisał(a)

zresztą to by zdechło ze 100 razy - ten program przekracza prędkość światła w działaniu.
tylko, że nie działa do końca poprawnie no ale to przecież it's a feature not a bug...

@wilma jak zaimplementujesz tam lockowanie rekordów i jakieś prymitywne transakcje (a to raczej minimum żeby wyeliminować możliwość jednoczesnej modyfikacji tych samych danych) to nagle sie okaże że program przestać przekraczać prędkość światła i ślimaczy się znacznie bardziej niż normalny system bazodanowy...

Shalom napisał(a)

@wilma jak zaimplementujesz tam lockowanie rekordów i jakieś prymitywne transakcje (a to raczej minimum żeby wyeliminować możliwość jednoczesnej modyfikacji tych samych danych) to nagle sie okaże że program przestać przekraczać prędkość światła i ślimaczy się znacznie bardziej niż normalny system bazodanowy...

Po co mam blokować jakieś rekordy?
Co ostatni wpisze, tak też zostanie...

Kolizje w bazach polegają na zrypaniu struktury, np. dwa wpisują w to samo miejsce.

Stawiam tylko malutki serwer na tym jednym stanowisku - na którym instalowano bazę.
I on robi dokładnie to samo, co teraz sam program, czyli czyta i zapisuje pliki.

Natomiast program zamiast manipulować wprost plikami, komunikuje się tylko z tym serwerem,
więc modyfikacja kodu w zasadzie sprowadza się do zmiany nazwy wywoływanej funkcji!

Tamten serwer sam z sobą się przecież nie zderzy, więc już nie będzie kolizji.

Pozostają tylko sprawy natury serwerowej, o które właśnie pytam:
jak to jest realizowane zazwyczaj, znaczy w oparciu o jaki mechanizm
komunikacji pomiędzy różnymi procesami, w tym zdalnymi?

Mogę tu wstawić również jakiś gotowy serwer...
wówczas modyfikacje kodu byłby pewnie nieco grubsze.

Misiekd napisał(a)

wilma napisał(a)

zresztą to by zdechło ze 100 razy - ten program przekracza prędkość światła w działaniu.
tylko, że nie działa do końca poprawnie no ale to przecież it's a feature not a bug...

A te serwerowe to się niby nie sypią?
Pamiętam jakie skecze bywały w tym DBE Borlanda - tam nie można wpisać nowego rekordu bezpiecznie - niekiedy drugi walił w to samo miejsce, hihi!

A może synchronizować przez jakiś jeden centralistyczny plik?
On byłby tylko sprawdzany w momentach krytycznych i cześć!

Tamten serwer sam z sobą się przecież nie zderzy, więc już nie będzie kolizji.

Ty w ogóle wiesz o czym mówisz? Bo jeśli chcesz żeby klienci nie "wisieli" na komunikacji z serwerem to musisz ją zrobić wielowątkowo i wtedy serwer może się zderzyć sam ze sobą, jak to ująłeś...

wilma napisał(a)

Po co mam blokować jakieś rekordy?
Co ostatni wpisze, tak też zostanie...

Wtedy nigdy nie będziesz miał pewności, czy program zmienił dane i czy ma aktualne.

Przy Twoim podejściu będziesz musiał napisać cały protokół komunikacji klient<->serwer, uwierzytelnianie, autoryzację, być może obsługę sesji. Będziesz sam musiał sobie poradzić z kolizjami. W przeciwnym razie nawet średnio rozgarnięty użytkownik w każdej chwili zrobi Ci "sieczkę" z takiej bazy o ile przypadkowo się nie posypie.

Innym rozwiązaniem jest użycie jakiegoś DBMS - ot np. MySQL, MS SQL Express. Łączysz się z bazą, dodajesz/usuwasz/zmieniasz rekordy i nie masz się co przejmować kolizjami, czy tym, że struktura bazy się posypie(o to już się DBMS zatroszczy).
Zmiany w kodzie w cale duże nie będą - ot zamiana pisania po plikach wywołaniami funkcji jakichś biblioteki do obsługi bazy - proste, przyjemne i szybkie. No chyba, że Twój kod jest wielkim latającym potworem spaghetti, to może być problem.

Shalom napisał(a)

Tamten serwer sam z sobą się przecież nie zderzy, więc już nie będzie kolizji.

Ty w ogóle wiesz o czym mówisz? Bo jeśli chcesz żeby klienci nie "wisieli" na komunikacji z serwerem to musisz ją zrobić wielowątkowo i wtedy serwer może się zderzyć sam ze sobą, jak to ująłeś...

Z tym nie byłoby problemu.
Program już w obecnej wersji pracuje wielowątkowo i tam jest to realizowane tradycyjnie: EnterCriticalSection, itp.

byku_guzio napisał(a)

wilma napisał(a)

Po co mam blokować jakieś rekordy?
Co ostatni wpisze, tak też zostanie...

Wtedy nigdy nie będziesz miał pewności, czy program zmienił dane i czy ma aktualne.

Dlaczego?
Po rozpoczęciu modyfikacji ściągamy aktualne dane i użytkownik widzi co ma.
Przed zapisem sprawdzamy, czy edytowany rekord uległ zmianie w międzyczasie i robimy... co tam potrzeba.

byku_guzio napisał(a)

Przy Twoim podejściu będziesz musiał napisać cały protokół komunikacji klient<->serwer, uwierzytelnianie, autoryzację, być może obsługę sesji. Będziesz sam musiał sobie poradzić z kolizjami. W przeciwnym razie nawet średnio rozgarnięty użytkownik w każdej chwili zrobi Ci "sieczkę" z takiej bazy o ile przypadkowo się nie posypie.

Innym rozwiązaniem jest użycie jakiegoś DBMS - ot np. MySQL, MS SQL Express. Łączysz się z bazą, dodajesz/usuwasz/zmieniasz rekordy i nie masz się co przejmować kolizjami, czy tym, że struktura bazy się posypie(o to już się DBMS zatroszczy).
Zmiany w kodzie w cale duże nie będą - ot zamiana pisania po plikach wywołaniami funkcji jakichś biblioteki do obsługi bazy - proste, przyjemne i szybkie. No chyba, że Twój kod jest wielkim latającym potworem spaghetti, to może być problem.

Możliwe, ale tak w ogóle wydaje mi się, że te serwery bazodanowe znikną z czasem zupełnie.
Przecież to było tworzone w czasach, gdy sieci były straszliwie wolne,
więc takie centralistyczne sterowanie było jedynym pewnym rozwiązaniem.

@wilma ale czemu miałyby zniknać zupełnie? Już od lat wiadomo że taniej i szybciej jest kupić gotowy dbms niż pisać takiego potworka jak ten którego używacie. A to czy on będzie rozproszony czy scentralizowany to jest zupełnie inna bajka.

Shalom napisał(a)

@wilma ale czemu miałyby zniknać zupełnie? Już od lat wiadomo że taniej i szybciej jest kupić gotowy dbms niż pisać takiego potworka jak ten którego używacie. A to czy on będzie rozproszony czy scentralizowany to jest zupełnie inna bajka.

Potworki to właśnie te serwery.
Porozrastało się to do monstrualnych rozmiarów... setki MB to lekka przesada jak na prosty mechanizm dostępu do danych.

Ale raczej nie znikną, bo sama struktura - organizacja bazy jest na tyle złożonym problemem, że bez sensu byłoby programować takie coś: B-drzewa, sortowanie wg różnych kryteriów, rekordy zmiennej długości...

A chodziło mi o to, że wkrótce sam system operacyjny bez problemu zagwarantuje dostateczną synchronizację, poprzez zwyczajne rozszerzenie pola działania tych standardowych metod synchronizacji:
współdzielenie pamięci - mapowanie plików, sekcje krytyczne, monitorowanie zmian plików, itp.

No, ale teraz wystarczy rozszerzyć lekko zbiór funkcji systemu operacyjnego o te bazodanowe, i on będzie po prostu zawierał w sobie te dzisiejsze śmieszne serwery.

Byłoby tu potrzebne chyba z kilkanaście funkcji, czyli to jest faktycznie nic, zwłaszcza w porównaniu z tym obecnym bajzlem serwerowo-bazodanowym.

tak czytam te "wynurzenia niespełnionego programisty" i zastanawiam się jak w waszym super hiper extra wypas systemie "bazodanowym" robicie takie rzeczy jak indeksy, pola o zmiennej długości, indeksy funkcyjne, triggery, klucze obce, wyszukiwanie, klucze główne, unikalność wartości w kolumnie itd. Nie mówię już o takich cudach jak tabele krzyżowe przy różnego rodzaju raportach i zestawieniach. Nie wyobrażam sobie pisać tego samemu. Nie wyobrażam sobie też pisać aplikacji, która musiała by sama zapewnić spójność danych. Przecież to jest koszmar. Ale rozumiem, że wybraliście taką drogę i jakoś trzeba sobie tłumaczyć dlaczego tak. BTW bardzo jestem ciekaw jak by się ten wasz "serwer" zachował jakby mu zapakować tak z 10GB danych do przetworzenia...

Misiekd napisał(a)

tak czytam te "wynurzenia niespełnionego programisty" i zastanawiam się jak w waszym super hiper extra wypas systemie "bazodanowym" robicie takie rzeczy jak indeksy, pola o zmiennej długości, indeksy funkcyjne, triggery, klucze obce, wyszukiwanie, klucze główne, unikalność wartości w kolumnie itd. Nie mówię już o takich cudach jak tabele krzyżowe przy różnego rodzaju raportach i zestawieniach. Nie wyobrażam sobie pisać tego samemu. Nie wyobrażam sobie też pisać aplikacji, która musiała by sama zapewnić spójność danych. Przecież to jest koszmar. Ale rozumiem, że wybraliście taką drogę i jakoś trzeba sobie tłumaczyć dlaczego tak. BTW bardzo jestem ciekaw jak by się ten wasz "serwer" zachował jakby mu zapakować tak z 10GB danych do przetworzenia...

Pewnie, że należy się trzymać gotowych i sprawdzonych rozwiązań.
Masz w tym kilka lat praktyki, więc pewnie nie interesujesz się tego typu problemami -
jak to jest realizowane w tych serwerach, a ja o to właśnie pytam.

Rozmiar w zasadzie nie ma tu dużego znaczenia, no ale te 10GB
w prostej bazie biznesowej to pewnie otrzymasz, ale gdy używasz takich serwerów.

Niech będzie, powiedzmy 1000 faktur/dokumentów dziennie, co da 300000 rocznie, albo i milion - ile to zajmuje?
Towarów, materiałów, produktów, pracowników, zleceń, magazynów, kontrahentów, itd. - ile tego może być?

Raportów, różnych zestawień kosztów, nakładów, zysków - program robi setki.
Robisz po prostu jeden schemat ogólny, a reszta idzie z automatu - różne warianty.
Wydruki podobnie.
Interfejs analogicznie.
Bazy tak samo, hihi!

Pamiętam kiedyś była taka dobra biblioteka zwana c-tree do baz danych - jest jakaś kontynuacja tego?

Włos się jeży na głowie jak sobie myśle, że są takie firmy gdzie pracują sobie tacy ludzie którzy wynajdują kwadratowe koła na nowo i uważają to za całkiem normalne.
A najgorsze jest to, że można przez przypadek trafić do takiej firmy.

0x200x20 napisał(a)

Włos się jeży na głowie jak sobie myśle, że są takie firmy gdzie pracują sobie tacy ludzie którzy wynajdują kwadratowe koła na nowo i uważają to za całkiem normalne.
A najgorsze jest to, że można przez przypadek trafić do takiej firmy.

Nie trafisz do takiej firmy, bo to nie jest jakaś programowalnia dla studentów, lecz branża budowlana.

A poza tym widziałeś w ogóle program do analizy na bieżąco kosztów, nakładów realizacji jakiejś inwestycji, budowy?
Nie zrobisz czegoś takiego i nie znajdziesz w sklepie,
więc przestań mi tu pitolić o odkrywaniu koła.

Ahhhaaahahaha...
Proponuję Ci trochę poczytać w temacie baz danych. To Ty tu próbujesz wynaleźć koło do nowa pisząc synchronizację bazy zrobionej na plikach. Już w tym temacie wypowiedziało Ci się trochę osób mających konkretną wiedzę i zapewne niejednokrotnie tworzących dużo bardziej złożone projekty niż to co przedstawiasz.

Próbujesz napisać coś co już ma oprogramowanie rozwijane od lat przez np. MS czy Oracle - myślisz, że napiszesz coś takiego lepiej, szybszego, bezpieczniejszego, mniej awaryjnego? Nie bierz tego do siebie, ale gdybyś był w stanie coś takiego zrobić to nie siedziałbyś ani w "programowalni dla studentów", ani w branży budowlanej.

byku_guzio napisał(a):

Proponuję Ci trochę poczytać w temacie baz danych. To Ty tu próbujesz wynaleźć koło do nowa pisząc synchronizację bazy zrobionej na plikach. Już w tym temacie wypowiedziało Ci się trochę osób mających konkretną wiedzę i zapewne niejednokrotnie tworzących dużo bardziej złożone projekty niż to co przedstawiasz.

Przecież oni nic nie powiedzieli, dokładnie - nawet na temat samych baz danych,
a o mechanizmach, na których są robione te serwery to pewnie nawet nie słyszeli że coś takiego w ogóle istnieje, hihi!

byku_guzio napisał(a):

Próbujesz napisać coś co już ma oprogramowanie rozwijane od lat przez np. MS czy Oracle - myślisz, że napiszesz coś takiego lepiej, szybszego, bezpieczniejszego, mniej awaryjnego? Nie bierz tego do siebie, ale gdybyś był w stanie coś takiego zrobić to nie siedziałbyś ani w "programowalni dla studentów", ani w branży budowlanej.

Pffffffffeff.
Aleś dowalił. Chyba ty próbujesz.
Gdyby ludzie robili to co mogą lub potrafią, wówczas każdy byłby prezydentem i premierem naraz.

Weź sobie cały super system Windows - 20 lat to tworzą, albo raczej kradną co popadnie dookoła, no i co to jest?
Albo Borland, wcześniej coś tam, potem inaczej, teraz jakaś Barakutas - co oni tworzyli przez 20 lat?
Głównie te wizualne przechwyty kontrolek, które były już w Win31 w 1980r.
Ten sam kompilator - z 1980r będzie pewnie w Builderze 2020...

wilma napisał(a):

Gdyby ludzie robili to co mogą lub potrafią, wówczas każdy byłby prezydentem i premierem naraz.

Nie każdy, bo nie każdy może i nie każdy potrafi - piszesz kompletnie bez ładu i składu.

wilma napisał(a):

Weź sobie cały super system Windows - 20 lat to tworzą, albo raczej kradną co popadnie dookoła, no i co to jest?
Albo Borland, wcześniej coś tam, potem inaczej, teraz jakaś Barakutas - co oni tworzyli przez 20 lat?
Głównie te wizualne przechwyty kontrolek, które były już w Win31 w 1980r.
Ten sam kompilator - z 1980r będzie pewnie w Builderze 2020...

Co Ty w ogóle gadasz? Masz w ogóle jakiekolwiek pojęcie na ten temat? Zachowujesz się jak ignorant, który pozjadał wszystkie rozumy, a wygląda na to, że nie masz zielonego pojęcia o czym mówisz.

Nawiązując do pierwszego postu: jakie blokowanie plików? Edycja jednego rekordu miałaby blokować pół bazy? Przecież to jakiś żart. Czy chcesz trzymać każdy rekord w osobnym pliku? Mutexy, semafory? Czy załatwiać to komunikacją między procesami? Przecież to jest totalnie pozbawione sensu.

byku_guzio napisał(a):

Co Ty w ogóle gadasz? Masz w ogóle jakiekolwiek pojęcie na ten temat? Zachowujesz się jak ignorant, który pozjadał wszystkie rozumy, a wygląda na to, że nie masz zielonego pojęcia o czym mówisz.

Wystarczające, żeby wyśmiewać pozorantów, fałszerzy i złodziejów.
Sprawdź historię sporów i łapówek MS:
http://en.wikipedia.org/wiki/Microsoft_litigation
Przecież to jest zwyczajna mafia... albo i gorzej.

Intel podobnie robi; np. procesory AMD są słabie... ale tylko na softwerze intela, hihi!

Nawiązując do pierwszego postu: jakie blokowanie plików? Edycja jednego rekordu miałaby blokować pół bazy? Przecież to jakiś żart. Czy chcesz trzymać każdy rekord w osobnym pliku? Mutexy, semafory? Czy załatwiać to komunikacją między procesami? Przecież to jest totalnie pozbawione sensu.

Widać że nie masz o tym zielonego pojęcia... synchronizacja bez komunikacji, hihi!

wilma napisał(a):

hihi!
co ty prostytutka jakaś różowa 15-latka jesteś czy co? Przecież nawet jakby ktoś chciał cię brać na poważnie to te hihi od razu dyskwalifikują całą wypowiedź

Wilmo. Albo będziesz się utwierdzać w swoich przekonaniach albo zaakceptujesz odpowiedź jaką dostałaś.

Fakt jest taki, że pisanie tego własnoręcznie jest złym wyjściem. O ile udałoby ci się coś naskrobać prostego, o tyle zaraz by się okazało, że to jednak nie wystarcza i trzeba wprowadzać kolejne zmiany. Bardziej się namordujesz w ten sposób niż przechodząc na jakiś gotowy system bazodanowy.

Nie dostałaś konkretnej odpowiedzi co do detali technicznych i funkcjonowania baz danych nie dlatego, że nikt nie wie jak to się robi, tylko dlatego, że właśnie niektórzy mają pojęcie z czym to się je i wiedzą, że temat jest niezwykle obszerny i nie można odpowiedzieć na twoje pytanie. Pytając "czy tu się używa jakichś muteksów czy coś?" to tak jakbyś pytała "czy do programowania używa się palców i klawiatury czy coś?".

adf88 napisał(a):

Wilmo. Albo będziesz się utwierdzać w swoich przekonaniach albo zaakceptujesz odpowiedź jaką dostałaś.

Fakt jest taki, że pisanie tego własnoręcznie jest złym wyjściem. O ile udałoby ci się coś naskrobać prostego, o tyle zaraz by się okazało, że to jednak nie wystarcza i trzeba wprowadzać kolejne zmiany. Bardziej się namordujesz w ten sposób niż przechodząc na jakiś gotowy system bazodanowy.

Bez przesady.
Z takim podejściem pewnie internet powinni zrobić od razu w obecnej postaci już w 1980r.

adf88 napisał(a):

Nie dostałaś konkretnej odpowiedzi co do detali technicznych i funkcjonowania baz danych nie dlatego, że nikt nie wie jak to się robi, tylko dlatego, że właśnie niektórzy mają pojęcie z czym to się je i wiedzą, że temat jest niezwykle obszerny i nie można odpowiedzieć na twoje pytanie. Pytając "czy tu się używa jakichś muteksów czy coś?" to tak jakbyś pytała "czy do programowania używa się palców i klawiatury czy coś?".

Kto pytał, czy tam używa się muteksów? One są używane do lokalnej synchronizacji, zwykle pomiędzy wątkami.
Pipy mogą być zdalne...

Może zna ktoś namiary na źródła c-tree ISAM, i najlepiej przerobione na obiekty w c++.
To taka ekstremalnie szybka realizacja bazy sieciowej, czyli jakby ortogonalnej do relacyjnych.
Nie ma tam tego całego zbędnego bajzlu, który wlecze się z SQL i relacyjnymi,
więc to pewnie lepiej by mi spasowało.