Здравейте,

Работя по една информационна система при която няколко клиента работят с обща база данни намираща се на сървъра.
Проблема които искам да реша не е само мои, а си мисля че по принцип си го има в подобни системи.
Настъпва голямо объркване когато 2 или повече клиента добавят или изтриват информация.
Как смятате че е наи добре да се реши този проблем така че винаги при клиента да има актуална информация.
Може би едно решение е ако на сървъра има някакво приложение което да изпраща съобщение на всички клиенти за да могат те да си обновят информацията.
Пишете ако някои знае по-практичен начин за справяне с проблема.

Записваш данните във временна таблица като записваш и времето в което са въведени. След това с някаъв крон взимаш временните таблици и ако има повтарящи се записи сравняваш времето и записваш на сървъра. След това обновяваш данните на клиента.

Break The UnBreakable

.. в логиката на приложението ти.

Просто не съхранявай никаква информация при клиентите.

Научи за какво са Транзакциите (по специално т.нар. Изолация) и Заключванията - Locks

И най-вече.

Не съхранявай никаква информация откъм клиентската част от приложението.

Съдържаниет е скрито
Влезте за да го видите

Не съхранявам информация в приложението.
Става въпрос например за следния случай:
Имам една таблица с комапний. При стартиране приложението прочита цялата таблица и потребителя вижда списъка с компании. Слад това от някои друг клиент вкарват в БД нова компания или изтрива някоя компания. На първия клиент му се показва все още стария списък с компаний и той например сега може да иска да редактира данните точно на изтритата компания. Тогава ще му излезе грешка че вече този запис го няма. И тук става паника - какво стана, изчезна компанията, досега си беше тук...
Ако пък са вкарани нови компании то първия клиент няма да ги види докато не се обнови информацията при него. Тя може да се обнови когато той направи някакво добавяне или изтриване. Най-лесно е е да му сложа един бутон за обновяване ама все трябва някои да го натиска от време на време. За това си мислех дали има някакъв начин това да става автоматично.

salle съвсем правилно ти е написал да си прочетеш теорията за нивата на изолация в базите данни. Реши си на какво ниво на изолация искаш да ти работи програмата и чак след това търси конкретното техническо решение. Щото както ги описваш нещата си личи че си тръгнал да правиш конкретна реализация без да знаеш какво искаш.

Приеми че една потребителска сесия ти е една транзакция, след това определи как би искал да се държи програмата по отношение на всякакви конфликти при достъп до данните. Това ще ти помогне да си избереш ниво на изолация. като си избереш ниво на изолация вече ще можеш да си избереш подходяща база данни, език на който да си пишеш програмата, и т.н.

"като си избереш ниво на изолация вече ще можеш да си избереш подходяща база данни"

Първо защото нивата на изолация са стандарт според ANSI SQL и второ защото това не може да бъде водещ критерий за избор на един или друг продукт.

Съдържаниет е скрито
Влезте за да го видите

> Не съхранявам информация в приложението.

Там е работата, че го правиш но не го осъзнаваш

Работи в следната посока:

Раздели ясно два вида дейност или режими на клиентската част:

1) Режим четене (Само за четене)
2) Режим промени (Редактиране)


Ти смесваш двата в един общ и оттам това неявно съществуване на данни в клиентската част.


Когато клиентът влиза в режим 2) той информира по съответния начин БД за да предпази системата от конфликти.


Пример с явно заключване:


SELECT id FROM users WHERE id = 19 FOR UPDATE;

Тази заявка заключва реда за писане (изключващо) така, че никоя друга сесия не може да го променя.

Ако друг клиент се опита да промени нещо по този ред той ще трябва да чака докато първият клиент приключи работата си.


Друг вариант е при който работейки в ниво на изолация REPEATEBLE READ или SERIALIZABLE две транзакции могат да променят едновременно едни и също данни като в момента на приключване сървърът ще се погрижи да разреши конфликтите по един или друг начин.
Много е вероятно едната транзакция просто да бъде отхвърлена което осигурява цялостност на данните. Друг вариант е едната транзакция да бъде заставена да чака заради неявно заключване.


Изобщо проблемът който поставяш е основен в теорията на Базите Данни и решим във всеки един случай независимо от продукта който използваш. В смисъл, че всеки продукт предлага средства.

Съдържаниет е скрито
Влезте за да го видите

Да, сега вече разбирама че наистина този проблем е доста по сериозен от колкото си го представях.
Разбрах какво имаш предвид за неявното съхранение на информация в приложението, но си мисля че това няма как да се избегне.
За това сега се мъча да намеря начин когато някои клиент променя нещо в БД да може другите да разберат за това и да си обновят тази информация която имат при себе си.

Прочети пак какво ти написах и след това се задълбай малко в теорията на Базите Данни. Определено е увлекателно.

Съдържаниет е скрито
Влезте за да го видите

Доколкото разбрах от написаното човека има проблем не толкова със заключванията, а с рефрешването на данните Не знам на каква СУБД го прави и може от там да идва проблема. Между другото може спокойно да си пази данни и в клиентската част, но тогава отиваме вече на частично или напълно разпределена система и трябва да се грижи за синхронизацията на данните. Ако пише на Access той си поддържа репликация на базата и проблема му е решен. Само трябва да реши през какъв период трябва да синхронизира(отнема не малко време, ако базата е големичка), но пък всеки комп си работи локално и самата програма ще си е по-бързичка.Да не говорим че при пълна репликация на практика едва ли ще загуби данни (освен ако не изгори цялата сграда)
Изобщо решения много. Но при всяко положение първо малко теория преди това

Твърде много залиташ в тази насока сървърът да актуализира данните при клиента. Твоят проблем е съвсем нормален за Client/Server приложения и по принцип в този случай не е желателно сървърът да праща каквото и да било на клиентите, освен *отговори* (представи си например, че това е HTTP-базирано приложение... но дори и да не е...)

Разучи добре нещата свързани с isolation levels, concurency, оптимистични/песимистични заключвания. Добре е да ги знаеш...

Не се отчайвай от мисълта, че на екрана можеш да виждаш данни, които междувременно са били променени, това е съвсем нормално. Имай предвид, че дори и сървърът автоматично да обновява данните на клиентите, това пак няма да те спаси в 100% от случаите ако не рабереш (и приложиш) гореспоменатите "техники". Да не говорим колко би се усложнила логиката и на сървъра и на клиента...

Все пак ще ти дам някои конкретни идеи и насоки за размисъл...

Ако вероятността ти да редактираш тези данни които виждаш е малка, а иначе доста други конкурентни потребители да проявяват интерес към същите данни е голяма, по принцип не е добре да заключваш въпросните записи при прочитането им. Тогава ще трябва просто при опит за модификация да правиш съответните проверки дали нещо не се е случило (и ако е - да направиш каквото прецениш че трябва) ....

И обратното... в други случаи това което ти предлага salle (SELECT ... FOR UPDATE) може да е по-удачния подход...

С други думи... чети за оптимистично / песимистично заключване и т.н...

От всичко написано до тук мисля че Bob ме е разбрал най-точно.

>> "Доколкото разбрах от написаното човека има проблем не толкова със заключванията, а с рефрешването на данните."

Аз потърсих информация в интернет по въпроса за синхронизация на информацията между клиентите и се оказва че най-доброто решение на проблема е чрез сървърна програма, през която минават всички заявки и тя информира клиентите за всички промени.
Но с това за мен проблема на се решава понеже базата данни е PostgreSQL, инсталиран на Linux.
А сега де ...?

И тъй като това е глобален проблем за такива ситеми се чудя защо в сървърите за бази данни няма вградени инструменти, помагащи за решаването на проблема.
Е не съм сигурен дали наистина няма.

Благодаря nasko,
Мился че с твоите насоки и теоретичните основи и препоръки на salle започвам да виждам свтлинка в тунела.

Благодаря на всички!

Access-а не прощава никому. По старото поколение DB програмисти е повредено от clipper -a, лека му пръст(на clippera, не на поколението) и за съжаление следващото върви с други средства по стъпките му.

накратко, connected приложенията стават само за дипломни работи (и в програма за магазин със 2 продажби на ден).
В реалния живот по този начин ще направиш няколко зулума наведнъж:
Ще си изпозаключиш базата както и турчин не я е заключвал(ще си позволя да цитирам соц класиците) ако тръгнеш да селектваш for update - лелята, която влиза в режим редактиране и после отива да пие кафе или вади плетката е класика в жанра.
Ще си задръстиш и мрежата със иди ми/дойди ми рефрешване. Което като цяло трябва да го правиш пак от приложението на някакъв timer event - това в случай че не държиш данни при клиета. Ако данните са при клиента, на практика пак трябва да ги локваш на сървъра(ако ги е взел някой, не трябва останалите да пипат по взетите неща).


Може би най-чисто и безболезнено е да си правиш проверка при запис/изтриване. Една нелоша стратегия е да ползваш timestamp-и. Не знам как точно е при Postgre-тo, но идеята е следната - когато си вземеш данни за редакция ги прибираш със timestamp - някакъв идентификатор за актуална версия на реда в таблицата. Ако при запис не е променена, си ОК. Ако има промяна, или ползваш hardcoded логика, или оставяш user-a да решава какво да прави.

Относно concurrent updates, базата би трябвало да се оправи без много услия от твоя страна.

Споменах ти защо идеята сървърът да обновява клиентите не е препоръчителна, освен ако наистина имаш причини да правиш това... (Не казвам, че не трябва да го правиш. Въпросът е да прецениш дали е оправдано.)

1. Не винаги сървърът има тази физическа възможност (когато протоколът например е HTTP). В такива случаи има подходи като периодични запитвания от страна на клиента (например с JavaScript) но това е съвсем друг въпрос.

2. Дори и сървърът да може да инициира връзка с клиентите и да им праща каквото и когато реши, това има своите сериозни недостатъци, като например, че софтуерът и на клиента, и на сървъра се усложнява значително, както и протоколът за комуникация м/у тях...

3. Това автоматично актуализиране няма да те спаси само по себе си от проблеми с неактуални данни при клиента (освен ако не реализираш специална логика с допълнителни проверки дали си успял да актуализираш данните му и т.н.)...

4. Performance. Помисли си защо...

Всъщност още доста може да се изпише по темата... но мисля, че и гореспоменатото не е слаба причина да се замислиш дали е оправдано всичко това...

Колкото до това дали СУБД-то което ползваш е Postgre или някакво друго, това няма особено значение, тъй като каквато и яка база да ползваш, тя няма как просто ей така да те отърве от всички проблеми свързани с този начин на работа... Впрочем тази функционалност обикновено се реализира чрез някакво приложение което ползва базата, т.е. такова дето стои между базата и клиентите.

А BTW колкото до performance-a, проблемите с него идват не само от слаб хардуер или "слаба" база, но и от неправилна работа с последната... Salle наскоро даде много подходящ пример със SELECT COUNT(*) from Tbl a, Tbl b, Tbl c, Tbl d... А когато говорим за транзакции и isolation levels има още доста какво да се каже по въпроса;)

Има няколко начина по които можеш да реализираш рефрешване на информацията на клиента, които в зависимост от инициативата могат да се класифицират:
1. Event от сървъра. В тригер палиш event (в някои сървъри механизма за ивънта го има вграден, в други може да се изпраща от външна функция)
2. Трислойна структура. Ползва се Application server, който уведомява клиентите за промените.
3. Периодична проверка за настъпили промени инициирана от клиента.

Всеки от горепосочените принципи може да има различни реализации.

Но.....
Както вече те предупредиха, към това трябва да се пристъпва много внимателно и мотивирано.
Защото:
1. Да си представим, че в един момент имаме 300 клиенти (за прегледност нека да са блондинки), които работят с данните (не е чак толкова страшно число)
2. В момента, в който някоя блондинка промени един запис, трябва да се изпълнят 300 заявки за рефрешване (и това няма да забие сървъра)
3. Да си представим, че тези блондинки в един момент ги обхване работохоликата (много опасно заболяване) и те почнат да начукват по два записа в минута (нещо съвсем реално)
===================================
Да видим сега какво трябва да върши сървъра за да държи данните на всички блондинки актуални.
2х300=600 променени записа в минута или 10 записа в секунда (средно)
10*300=3000 заявки в секунда за да се държат актуални данните на блондинките.
Като включиш в сметката и мрежовия трафик, който се генерира при това, няма да остане много за полезна работа.

Така че не е невъзможно, но внимателно прецени наистина ли ти трябва.

Успех

opitai drug podhod! zapomni koi kakvo i koga? ne go replikirai i ne go obnovqvai, dokato vsi4ki "blondinki" ne sprat rabota "(prez no6ta)"...posle davai na vsqka "blondinka" neiniq profil( promeni) i ne se griji za gluposti.............taka 6te ima6 100_1000 profila....vsi4ki 6te sa dovolni....spisuka s kompanii 6te e pulen
( vinagi)...ni6to nqma da e iztrito . 4rez (parolata)6te znae6 koi (profil )da pokazva6 , i na kogo !
uspeh

Пич ...слушай са ква е истината.. аз отдавна съм го решил този проблем...
===
btw....БАЗАТА НЯМА ЗНАЧЕНИЕ....ако имаше то тогава всички трябваше да си купуват самолети а нямаше да търсят алтернативни решения с тирове микробуси и кораби например..ако ме разбираш...
===
ЗАПОМНИ...
В БАЗА ДАННИ НИКОГА НЕ ИЗТРИВАЙ В ТАБЛИЦИ ОТ ТИП РЕГИСТРИ И ПОДОБНИ...
единствено в темпорални таблици можеш да си го позволиш
===
Когато се каже мрежово приложение това означава че не може да се разчита на клиента... дори напротив ..търсиш начин ако някой зорлем иска да го счупи да не може..защото мераклии за зулуми колкото щеш...:))))
====
Във всяка такава такава таблица добавяш едно поле например STATUS.

При нов запис го сетваш 1 - ЖИВ
При изтриване го сетваш 3 - МЪРТЪВ (демек изтрит)


ПРИ РЕДАКЦИЯ ГО СЕТВАШ 2 - ЗАКЛЮЧЕН (досега не ми се е налагало но идеята е че първия който го хване за редакция го заключва и другите само го виждат. Ако въпросната блондинка го отвори за редакция и иде да си лакира ноктите при шефа то има няколко начина ....или чред друго допълнително поле да знаеш кога е започнала редакцията и да си избереш таймаут според ситуациата или чрез таймер в клиенската част формата за редакция сама да се изключва разбира се с подходящи съобщения....има и други решения

И така ..с това поле STATUS записа или е ЖИВ или... в "АРХИВ"... и ако спазваш идеологията на базите то няма да имаш загубени данни в релации поради изтриване...т.е. имаш документ доставка с вече избран доставчик и след 5 дена някой го изтрива(предполага се че в таблицата с документите доставчика присъства като ID а не като стринг както в някои велики програми като ДЕКАРТ или ORAK systems....) и когато се върнеш за справка на този токумент ...хоп ..доставчика липсва...
=====
Ако трябва да задълбаем то има не много труден начин да се запазят и всички редакци на определен запис и така ако доставчика преди година е бил с друг телефон а после го е сменил ...то тогава като извадиш справка за този доставчик ще можеш да покажеш цялата "история" на записите....

ОК???

(разделям го на 2 за по прегледно)

И така ГОЛЕМИЯ въпрос....РЕФРЕША

=====
имаме овен А който сяда и пуска приложението и отваря таблицата X.
След отварянето седи тъпо и гледа...

в същото време овца Б отваря същата таблица и започва да цапа....
=====
да речем че А вижда записа N и се е втурачил в него...
през това време Б го редактира....
А не разбира защото бавно сграва за кво е отворил таблицата и се опитва да постигне нирвана чрез хипноза на запис....(т.е. нещата са зле защото нямаме РЕФРЕЕЕЕШШШШ.... при Б и всичките му подобни /Б може да са стотици/)
====
Б зацепва за кво е отворил таблицата след минута и щрака върху същия запис N за редакция нпр...

(след всяка операция запис редкц или изтриване програмата трябва да изпълнява рефреш на таблицата)
---
И така ...ако записа вече е изтрит Б получава грешка "Няма такъв запис"...и тука трябва да му е ясно че работи в мрежа и някой друг вече го е изпреварил...
Ако записа е редактиран то в момента на започване на редакцията се извлича новата стойност и в прозореца за редакция Б вижда последното състояние(редакцията трябва задължително да е в отделен прозорец/форма а не в стил DBGrid...(F2 в Excel)...

--- ако Б прави нов запис то тогава ще получи грешка за дублиране(разбира се това е грижа на програмиста при инсърт най добре чрез процедура) и така отново трябва да му е ясно че някой го е изпреварил...разбира се РЕФРЕШ след затваряне на грешката и той вижда новия запис...

---
тука веднага някой капацитети ще ме оборят и може би ще са много прави... но за съжаление такава е практиката и фактите го доказват....
Това е като на борсата....чудиш се чудиш ....решаваш се ...щрак купувам ...но сори ..закъснял съм... както казах вече най важното е да се каже на клиента при обучението че при обща база и много клиенти всички започват с равни приоритети....
Но пък каква е вероятноста шефа да даде едни и същи задачи на 2ма или повече служутели...тва вие ще кажете....

Ако пък имаме 20 души които събират и една и съща информация то тогава те са наясно че са част от екип и след като получат грешка при запис или редакция в следващия момент ще се убедят че не са сами....


====
това е едва 10% от цялата врътка с този проблем но тука трябва са загубя дни за да изложа цялата идеология защото това решение има още няколко ключови модули/решения за да се затвори кръга....
----

Ако се навиеш на този принцип със сигурност ще ти се наложи да пренапишеш доста....но идеята ми е ако някой следваш тръгне да прави нещо подобно..ако му приляга да се възползва....ГАРАНЦИЯ за дуракоусточивост и гъвкавост на базата...- ОТ МЕН...:)))))))

Хора, а от къде може да се про4ете по обстойно по темата-online, на български имам предвид.Също книги някакви ако ми препоръ4ате

___________________________________