|
Сложность при проектировании многопользовательской БД на основе однопользовательской.
|
|||
---|---|---|---|
#18+
>NewBy52, 3 июн 19, 11:43 https://www.sql.ru/forum/actualutils.aspx?action=gotomsg&tid=1313250&msg=21900247][21900247] >… есть основная таблица r_objects … есть масса вспомогательных таблиц … Логика обработки этих данных требует при указании конкретного объекта загрузить их все в память … <Поддерживаю Dimitry Sibiryakov. Вопрос касается "широких" сущностей, много атрибутов, разумно растащить их по разным таблицам. Имею MS SQL и поступаю так: 1. Формирую целостную сущность из многих её частей (у меня всего две) хранимой процедурой. Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35.
2. Храню изменения сущности так: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56.
При изменениях всегда получаю текущее состояние сущности в базе данных, если ок - свои изменения, иначе крайние изменения кого-то. Крайний параметр строки выборки @ErrorVar as rc - код ошибки 3. Относительно вопроса "грязного" чтения. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.09.2019, 12:34 |
|
Сложность при проектировании многопользовательской БД на основе однопользовательской.
|
|||
---|---|---|---|
#18+
NewBy52Но в многопользовательской среде 2 оператора могут корректировать один и то же объект (а время коррекции получается достаточно длительное) и каждый может перезаписать свою версию данных. В вашем случае проблема пока еще в технологической плоскости, а не в технической. Сначала нужно решить а как все это должно работать, а потом искать техническое решение. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.09.2019, 12:55 |
|
Сложность при проектировании многопользовательской БД на основе однопользовательской.
|
|||
---|---|---|---|
#18+
Что за нашествие некроспамеров? Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
01.09.2019, 13:06 |
|
Сложность при проектировании многопользовательской БД на основе однопользовательской.
|
|||
---|---|---|---|
#18+
Dimitry SibiryakovЧто за нашествие некроспамеров? Поясните, пожалуйста, что вы имели ввиду? ... |
|||
:
Нравится:
Не нравится:
|
|||
01.09.2019, 13:44 |
|
Сложность при проектировании многопользовательской БД на основе однопользовательской.
|
|||
---|---|---|---|
#18+
На даты сообщений в топике посмотри. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
01.09.2019, 13:45 |
|
Сложность при проектировании многопользовательской БД на основе однопользовательской.
|
|||
---|---|---|---|
#18+
Dimitry SibiryakovНа даты сообщений в топике посмотри. 3 июн 19 не так уж и давно это было. Просто для интереса: какой возраст записи для Вас не считается некроманским? 2 недели? ) ... |
|||
:
Нравится:
Не нравится:
|
|||
01.09.2019, 14:56 |
|
Сложность при проектировании многопользовательской БД на основе однопользовательской.
|
|||
---|---|---|---|
#18+
>Serguei, сегодня, 14:56 https://www.sql.ru/forum/actualutils.aspx?action=gotomsg&tid=1313250&msg=21961467][21961467] >… какой возраст записи … <Да не суть, не берите в голову. Ответа на поставленный вопрос так и нет. В моём варианте пользователь (клиентское приложение) после UPDATE имеет две версии сущности - сущность в базе данных и локальную сущность + код ошибки. И как далее поступать? И если много изменений? В настоящее время тупо отражаю сущность базы данных в локальную сущность, отображаю атрибуты в компонентах графического интерфейса и при необходимости сигнализирую об ошибке. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.09.2019, 15:18 |
|
Сложность при проектировании многопользовательской БД на основе однопользовательской.
|
|||
---|---|---|---|
#18+
vmagда и не закрывает совсем... ну получил я версию объекта после того как отдолбил 1000 параметров в течение двух часов и что? - я должен понять и принять тот факт, что я два часа долбил зря, передо мной вроде как долбил крутой ? - или я честно отработал день, а на утро увидел что вчера работал зря, мои труды потерли... - а может у меня пусть 10 % но более правильная информация, которая ушла в никуда... ? ИМХО тут блокировки и и всякие версии не сработают на все 100 ... посмотрите, как в википедии сделано ... |
|||
:
Нравится:
Не нравится:
|
|||
01.09.2019, 18:26 |
|
Сложность при проектировании многопользовательской БД на основе однопользовательской.
|
|||
---|---|---|---|
#18+
полудухпосмотрите, как в википедии сделаноА чо туда смотреть ? Сабж необходимо реализовывать исходя из логики задачи. Чтобы новые данные не пропадали - ввести понятие данных-кандидатов. Т.е. разновидность черновика. Если там есть непротиворечивые ценные данные - после верификации поместить их в продакшн-данные. Сразу или спустя некот. время - зависит только от Б/Л. Это чисто бизнес-логический процесс, кот. можно реализовать хоть в DBF, хоть в тхт-файлах. Непонятно, зачем постить сюда портянки кода и умно рассуждать о блокировках в БД. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.09.2019, 21:14 |
|
Сложность при проектировании многопользовательской БД на основе однопользовательской.
|
|||
---|---|---|---|
#18+
... |
|||
:
Нравится:
Не нравится:
|
|||
01.09.2019, 22:53 |
|
Сложность при проектировании многопользовательской БД на основе однопользовательской.
|
|||
---|---|---|---|
#18+
Кот МатроскинNewBy52Более того, скажу, лет 30 назад, я, по неопытности, реализовал подобное решение. 30 лет назад (в 1989 году) Вы реализовывали многопользовательскую клиент-серверную систему? На какой платформе, если не секрет? А что смущает? Древние фокспро 2.6 и клиппер 5 (что ещё тогда модно было - Кларион какойто досовский емнип) вполне позволяли реализовывать совместный доступ к СУБД, представляющей собой набор файловых dbf и cdx файлов на общей сетевой шаре. Доводилось немного сопровождать такие решения, доставшиеся от старших товарищей. Вполне достойно работали по тем временам. И кстати, кое в чём могли поспорить с современными графическими "интерфейсами", - темп ввода в экранные формы, несмотря на отсутствие мышки, был вцелом я бы сказалвыше. Т.к. выбор в поле ввода из справочника обычно вешали на F-клавиши, навигация по полям ввода - enter-ом (а не уродским Табом, который ну совсем в неудобном углу клавиатуры), выбор (выделение) позиций грида для массовой обработки - обычно пробелом или Ins (который сразу сдвигал курсор вниз на 1 запись). Никто эргономически-уродские решения с галочками, в которые нужно целиться мышью, махая клешнями то на мышь то на клавиатуру (и постраничным листанием гридов) не применял (и даже не снил себе в кошмарном сне :). Так что всё норм было на рубеже 80-90ых. И даже встроенный интерпретатор с отладчиком прямо в откомпиленную софтину клиптцер по крайней мере умел прилепливать, очень помогало в отладке-трассировке тяжёлых случаев. ... |
|||
:
Нравится:
Не нравится:
|
|||
02.09.2019, 09:56 |
|
Сложность при проектировании многопользовательской БД на основе однопользовательской.
|
|||
---|---|---|---|
#18+
>NewBy52, 3 июн 19, 14:01 https://www.sql.ru/forum/actualutils.aspx?action=gotomsg&tid=1313250&msg=21900485][21900485] >...Потому что многие записи расчетные… <Мне не приходилось хранить 2000+ расчетных данных в "лоб". Имею дело с географическими объектами (сущностями) не точечного размера. Граница сущности задаётся вершинами многоугольника, кругом, эллипсом, сегментом. Число точек границы не более 20(пока). Для пробы не стал записывать параметры границы по точечно в дополнительную таблицу базы данных - сериализовал значения в byte[] и записал одним полем в запись базовой таблицы сущности. Думаю, что тоже самое можно сделать и с 2000+. Если данных очень много, то аппроксимация сплайнами, но это уже другая задача. ... |
|||
:
Нравится:
Не нравится:
|
|||
02.09.2019, 16:21 |
|
Сложность при проектировании многопользовательской БД на основе однопользовательской.
|
|||
---|---|---|---|
#18+
NewBy52Добрый день! Есть однопользовательская БД, которая нормально спроектирована и работает на SQLite. Сейчас возникла задача сделать её многопользовательской на основе MS SQL Server или чём-то подобном. Сложность заключается в следующем: есть основная таблица r_objects, где находятся некие объекты, упорядоченные в виде дерева. И есть масса вспомогательных таблиц, данные в которых принадлежат конкретному объекту. Логика обработки этих данных требует при указании конкретного объекта загрузить их все в память, и там обрабатывать (корректировать, выполнять расчеты, представлять в виде графиков и т.д.) После выполнения всех действий, если возникли изменения в данных (а они могут кардинально поменяться), необходимо записать данные обратно. Пока это однопользовательская БД, это нормально. Но в многопользовательской среде 2 оператора могут корректировать один и то же объект (а время коррекции получается достаточно длительное) и каждый может перезаписать свою версию данных. Ситуация усугубляется тем, что пользователи могут быть разнесены на тысячи километров. Вопрос: как синхронизировать такие коллизии? Насколько это будет быстро работать? По сабжу я бы делал третью базу в которую бы хранил только изменения конкретных записей и конфликты, если они будут возникать на уровне строк. А что требуется получить на выходе-то? ... |
|||
:
Нравится:
Не нравится:
|
|||
02.09.2019, 21:59 |
|
Сложность при проектировании многопользовательской БД на основе однопользовательской.
|
|||
---|---|---|---|
#18+
NewBy52Добрый день! Есть однопользовательская БД, которая нормально спроектирована и работает на SQLite. Сейчас возникла задача сделать её многопользовательской на основе MS SQL Server или чём-то подобном. Сложность заключается в следующем: есть основная таблица r_objects, где находятся некие объекты, упорядоченные в виде дерева. И есть масса вспомогательных таблиц, данные в которых принадлежат конкретному объекту. Логика обработки этих данных требует при указании конкретного объекта загрузить их все в память, и там обрабатывать (корректировать, выполнять расчеты, представлять в виде графиков и т.д.) После выполнения всех действий, если возникли изменения в данных (а они могут кардинально поменяться), необходимо записать данные обратно. Пока это однопользовательская БД, это нормально. Но в многопользовательской среде 2 оператора могут корректировать один и то же объект (а время коррекции получается достаточно длительное) и каждый может перезаписать свою версию данных. Ситуация усугубляется тем, что пользователи могут быть разнесены на тысячи километров. Вопрос: как синхронизировать такие коллизии? У меня есть что-то похожее. Сделано следующим образом. Дерево отображается так, как будто юзер работает один, не обращая внимания на других юзеров. Данные из базы в дерево грузятся не сразу, а через кэш. Кэш - небольшой, на пару экранов. Что это дает. При изменении данных одним из юзеров все заинтересованные получают извещение об изменении. Получив сообщение, клиентская часть сбрасывает кэш и выполняет команду перерисовать видимую часть дерева. В результате в кэш из базы подтягиваются свежие данные. При этом, измененные элементы сразу отображаются. Удаленные элементы отображаются как пустые строки, поэтому на экране ничего не "прыгает". Добавленные элементы не видны, за исключением случая, когда они добавлены во вложенные свернутые уровни, при этом меняется иконка уровня (появляется "крестик" - значит, внутри что-то есть). А также подсвечивается кнопка "обновить", по которой можно заново перестроить дерево и увидеть все, что появилось. Схема прижилась и работает уже больше 10 лет. Ничего не тормозит, но нагрузка не очень велика - до полутора сотни одновременно работающих юзеров. Вот, на картинка синим подсвечена строчка, удаленная другим юзером. ... |
|||
:
Нравится:
Не нравится:
|
|||
03.09.2019, 10:08 |
|
|
start [/forum/topic.php?fid=32&msg=39856514&tid=1539914]: |
0ms |
get settings: |
9ms |
get forum list: |
14ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
142ms |
get topic data: |
11ms |
get forum data: |
2ms |
get page messages: |
53ms |
get tp. blocked users: |
1ms |
others: | 13ms |
total: | 251ms |
0 / 0 |