Здравейте,

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

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

Break The UnBreakable

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

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

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

И най-вече.

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

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

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

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

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

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

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

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

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

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

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

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

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


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


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


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


SELECT id FROM users WHERE id = 19 FOR UPDATE;

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

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


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


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

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

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

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

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