powered by simpleCommunicator - 2.0.49     © 2025 Programmizd 02
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Сложность при проектировании многопользовательской БД на основе однопользовательской.
14 сообщений из 64, страница 3 из 3
Сложность при проектировании многопользовательской БД на основе однопользовательской.
    #39856079
ВМоисеев
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
>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.
ALTER PROCEDURE [dbo].[au01_ОбъектыД_Sel] 
  @pk_Entity uniqueidentifier
AS
BEGIN
  SET NOCOUNT ON;
  SELECT TOP(1)
    -- ОбъектыД
    обд.pk_Entity,
    обд.tn_ЧастьОбъ,
    обд.str_Признак,
    обд.fk_ДокВкл,
    . . .
    обд.ts_Entity,

    -- Объекты
    об.pk_Entity,
    об.fk_Дог,
    об.fk_Гос,
    об.str_NameObj,
    об.str_НаимОбъ,
    . . .
    об.str_РегНом,
    об.str_AbbrObj,
    об.str_АббрОбъ,
    об.str_Del,
    об.ts_Entity
  FROM tbl01_ОбъектыД обд
       INNER JOIN tbl01_Документы дв ON обд.fk_ДокВкл=дв.pk_Entity
       INNER JOIN tbl01_Документы дл ON обд.fk_ДокЛик=дл.pk_Entity
       INNER JOIN tbl01_Документы дф ON обд.fk_ДокФакЛик=дл.pk_Entity,
    tbl01_Объекты об
	INNER JOIN tbl01_Государства го ON об.fk_Гос=го.pk_Entity
	INNER JOIN tbl01_Договоры до ON об.fk_Дог=до.pk_Entity 
  WHERE (обд.pk_Entity=@pk_Entity) and (обд.pk_Entity=об.pk_Entity);
END


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.
ALTER PROCEDURE [dbo].[au01_ОбъектыД_Upd] 
    -- ОбъектыД
    @pk_EntityД	     uniqueidentifier,
    . . .    
    @ts_EntityД	     timestamp,
    
    -- Объекты
    @pk_Entity	     uniqueidentifier,
    . . .    
    @ts_Entity	     timestamp
AS
BEGIN
  DECLARE @ErrorVar INT;  
  SET NOCOUNT OFF
  BEGIN TRANSACTION
    UPDATE tbl01_ОбъектыД SET
      tn_ЧастьОбъ     = @tn_ЧастьОбъ,
      str_Признак     = @str_Признак,
      fk_ДокВкл       = @fk_ДокВкл,
      . . .
      str_Радиус      = @str_Радиус,
      fl_Площадь      = @fl_Площадь
	WHERE (pk_Entity=@pk_Entity) and (ts_Entity=@ts_Entity)
	SET @ErrorVar=@@error;
	IF (@ErrorVar <> 0) GOTO CORO; --Отменить транзакцию, если есть ошибки
	UPDATE tbl01_Объекты SET
      fk_Дог=@fk_Дог,
      . . .
      str_NameObj=@str_NameObj
	WHERE (pk_Entity=@pk_Entity) and (ts_Entity=@ts_Entity)
	SET @ErrorVar=@@error;

	CORO:
	IF (@ErrorVar <> 0) ROLLBACK; --Отменить транзакцию, если есть ошибки
	ELSE COMMIT;

  SELECT TOP(1)
    -- ОбъектыД
    обд.pk_Entity,
    . . .
    обд.ts_Entity,

    -- Объекты
    об.pk_Entity,
    . . .
    об.ts_Entity,
    @ErrorVar as rc
  FROM tbl01_ОбъектыД обд
    INNER JOIN tbl01_Документы дв ON обд.fk_ДокВкл=дв.pk_Entity
    INNER JOIN tbl01_Документы дл ON обд.fk_ДокЛик=дл.pk_Entity
    INNER JOIN tbl01_Документы дф ON обд.fk_ДокФакЛик=дл.pk_Entity,
    tbl01_Объекты об
	INNER JOIN tbl01_Государства го ON об.fk_Гос=го.pk_Entity
	INNER JOIN tbl01_Договоры до ON об.fk_Дог=до.pk_Entity 
  WHERE (обд.pk_Entity=@pk_Entity) and (обд.pk_Entity=об.pk_Entity);
END


При изменениях всегда получаю текущее состояние сущности в базе данных, если ок - свои изменения, иначе крайние изменения кого-то. Крайний параметр строки выборки @ErrorVar as rc - код ошибки

3. Относительно вопроса "грязного" чтения.
...
Рейтинг: 0 / 0
Сложность при проектировании многопользовательской БД на основе однопользовательской.
    #39856080
Serguei
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
NewBy52Но в многопользовательской среде 2 оператора могут корректировать один и то же объект (а время коррекции получается достаточно длительное) и каждый может перезаписать свою версию данных.

В вашем случае проблема пока еще в технологической плоскости, а не в технической. Сначала нужно решить а как все это должно работать, а потом искать техническое решение.
...
Рейтинг: 0 / 0
Сложность при проектировании многопользовательской БД на основе однопользовательской.
    #39856083
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Что за нашествие некроспамеров?
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Сложность при проектировании многопользовательской БД на основе однопользовательской.
    #39856086
Serguei
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dimitry SibiryakovЧто за нашествие некроспамеров?
Поясните, пожалуйста, что вы имели ввиду?
...
Рейтинг: 0 / 0
Сложность при проектировании многопользовательской БД на основе однопользовательской.
    #39856087
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
На даты сообщений в топике посмотри.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Сложность при проектировании многопользовательской БД на основе однопользовательской.
    #39856090
Serguei
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dimitry SibiryakovНа даты сообщений в топике посмотри.
3 июн 19 не так уж и давно это было.

Просто для интереса: какой возраст записи для Вас не считается некроманским? 2 недели? )
...
Рейтинг: 0 / 0
Сложность при проектировании многопользовательской БД на основе однопользовательской.
    #39856093
ВМоисеев
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
>Serguei, сегодня, 14:56 https://www.sql.ru/forum/actualutils.aspx?action=gotomsg&tid=1313250&msg=21961467][21961467]
>… какой возраст записи …
<Да не суть, не берите в голову.
Ответа на поставленный вопрос так и нет. В моём варианте пользователь (клиентское приложение) после UPDATE имеет две версии сущности - сущность в базе данных и локальную сущность + код ошибки.
И как далее поступать? И если много изменений?
В настоящее время тупо отражаю сущность базы данных в локальную сущность, отображаю атрибуты в компонентах графического интерфейса и при необходимости сигнализирую об ошибке.
...
Рейтинг: 0 / 0
Сложность при проектировании многопользовательской БД на основе однопользовательской.
    #39856109
Фотография полудух
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
vmagда и не закрывает совсем...
ну получил я версию объекта после того как отдолбил 1000 параметров в течение двух часов и что?
- я должен понять и принять тот факт, что я два часа долбил зря, передо мной вроде как долбил крутой ?
- или я честно отработал день, а на утро увидел что вчера работал зря, мои труды потерли...
- а может у меня пусть 10 % но более правильная информация, которая ушла в никуда... ?
ИМХО тут блокировки и и всякие версии не сработают на все 100 ...
посмотрите, как в википедии сделано
...
Рейтинг: 0 / 0
Сложность при проектировании многопользовательской БД на основе однопользовательской.
    #39856128
L_argo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
полудухпосмотрите, как в википедии сделаноА чо туда смотреть ?
Сабж необходимо реализовывать исходя из логики задачи.
Чтобы новые данные не пропадали - ввести понятие данных-кандидатов. Т.е. разновидность черновика. Если там есть непротиворечивые ценные данные - после верификации поместить их в продакшн-данные. Сразу или спустя некот. время - зависит только от Б/Л.
Это чисто бизнес-логический процесс, кот. можно реализовать хоть в DBF, хоть в тхт-файлах.

Непонятно, зачем постить сюда портянки кода и умно рассуждать о блокировках в БД.
...
Рейтинг: 0 / 0
Сложность при проектировании многопользовательской БД на основе однопользовательской.
    #39856136
Фотография полудух
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
L_argoА чо туда смотреть ?
чтобы увидеть там всё то, что вы ниже описали
...
Рейтинг: 0 / 0
Сложность при проектировании многопользовательской БД на основе однопользовательской.
    #39856188
ldfanate
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Кот МатроскинNewBy52Более того, скажу, лет 30 назад, я, по неопытности, реализовал подобное решение.
30 лет назад (в 1989 году) Вы реализовывали многопользовательскую клиент-серверную систему? На какой платформе, если не секрет?

А что смущает? Древние фокспро 2.6 и клиппер 5 (что ещё тогда модно было - Кларион какойто досовский емнип) вполне позволяли реализовывать совместный доступ к СУБД, представляющей собой набор файловых dbf и cdx файлов на общей сетевой шаре. Доводилось немного сопровождать такие решения, доставшиеся от старших товарищей. Вполне достойно работали по тем временам.

И кстати, кое в чём могли поспорить с современными графическими "интерфейсами", - темп ввода в экранные формы, несмотря на отсутствие мышки, был вцелом я бы сказалвыше. Т.к. выбор в поле ввода из справочника обычно вешали на F-клавиши, навигация по полям ввода - enter-ом (а не уродским Табом, который ну совсем в неудобном углу клавиатуры), выбор (выделение) позиций грида для массовой обработки - обычно пробелом или Ins (который сразу сдвигал курсор вниз на 1 запись). Никто эргономически-уродские решения с галочками, в которые нужно целиться мышью, махая клешнями то на мышь то на клавиатуру (и постраничным листанием гридов) не применял (и даже не снил себе в кошмарном сне :).
Так что всё норм было на рубеже 80-90ых. И даже встроенный интерпретатор с отладчиком прямо в откомпиленную софтину клиптцер по крайней мере умел прилепливать, очень помогало в отладке-трассировке тяжёлых случаев.
...
Рейтинг: 0 / 0
Сложность при проектировании многопользовательской БД на основе однопользовательской.
    #39856367
ВМоисеев
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
>NewBy52, 3 июн 19, 14:01 https://www.sql.ru/forum/actualutils.aspx?action=gotomsg&tid=1313250&msg=21900485][21900485]
>...Потому что многие записи расчетные…
<Мне не приходилось хранить 2000+ расчетных данных в "лоб". Имею дело с географическими объектами (сущностями) не точечного размера. Граница сущности задаётся вершинами многоугольника, кругом, эллипсом, сегментом. Число точек границы не более 20(пока). Для пробы не стал записывать параметры границы по точечно в дополнительную таблицу базы данных - сериализовал значения в byte[] и записал одним полем в запись базовой таблицы сущности. Думаю, что тоже самое можно сделать и с 2000+.
Если данных очень много, то аппроксимация сплайнами, но это уже другая задача.
...
Рейтинг: 0 / 0
Сложность при проектировании многопользовательской БД на основе однопользовательской.
    #39856452
L.Otujktd
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
NewBy52Добрый день!
Есть однопользовательская БД, которая нормально спроектирована и работает на SQLite. Сейчас возникла задача сделать её многопользовательской на основе MS SQL Server или чём-то подобном.
Сложность заключается в следующем: есть основная таблица r_objects, где находятся некие объекты, упорядоченные в виде дерева. И есть масса вспомогательных таблиц, данные в которых принадлежат конкретному объекту.
Логика обработки этих данных требует при указании конкретного объекта загрузить их все в память, и там обрабатывать (корректировать, выполнять расчеты, представлять в виде графиков и т.д.)
После выполнения всех действий, если возникли изменения в данных (а они могут кардинально поменяться), необходимо записать данные обратно. Пока это однопользовательская БД, это нормально.
Но в многопользовательской среде 2 оператора могут корректировать один и то же объект (а время коррекции получается достаточно длительное) и каждый может перезаписать свою версию данных. Ситуация усугубляется тем, что пользователи могут быть разнесены на тысячи километров.
Вопрос: как синхронизировать такие коллизии?
Насколько это будет быстро работать? По сабжу я бы делал третью базу в которую бы хранил только изменения конкретных записей и конфликты, если они будут возникать на уровне строк. А что требуется получить на выходе-то?
...
Рейтинг: 0 / 0
Сложность при проектировании многопользовательской БД на основе однопользовательской.
    #39856514
ёёёёё
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
NewBy52Добрый день!
Есть однопользовательская БД, которая нормально спроектирована и работает на SQLite. Сейчас возникла задача сделать её многопользовательской на основе MS SQL Server или чём-то подобном.
Сложность заключается в следующем: есть основная таблица r_objects, где находятся некие объекты, упорядоченные в виде дерева. И есть масса вспомогательных таблиц, данные в которых принадлежат конкретному объекту.
Логика обработки этих данных требует при указании конкретного объекта загрузить их все в память, и там обрабатывать (корректировать, выполнять расчеты, представлять в виде графиков и т.д.)
После выполнения всех действий, если возникли изменения в данных (а они могут кардинально поменяться), необходимо записать данные обратно. Пока это однопользовательская БД, это нормально.
Но в многопользовательской среде 2 оператора могут корректировать один и то же объект (а время коррекции получается достаточно длительное) и каждый может перезаписать свою версию данных. Ситуация усугубляется тем, что пользователи могут быть разнесены на тысячи километров.
Вопрос: как синхронизировать такие коллизии?
У меня есть что-то похожее.

Сделано следующим образом.
Дерево отображается так, как будто юзер работает один, не обращая внимания на других юзеров. Данные из базы в дерево грузятся не сразу, а через кэш. Кэш - небольшой, на пару экранов. Что это дает. При изменении данных одним из юзеров все заинтересованные получают извещение об изменении. Получив сообщение, клиентская часть сбрасывает кэш и выполняет команду перерисовать видимую часть дерева. В результате в кэш из базы подтягиваются свежие данные.
При этом, измененные элементы сразу отображаются. Удаленные элементы отображаются как пустые строки, поэтому на экране ничего не "прыгает". Добавленные элементы не видны, за исключением случая, когда они добавлены во вложенные свернутые уровни, при этом меняется иконка уровня (появляется "крестик" - значит, внутри что-то есть). А также подсвечивается кнопка "обновить", по которой можно заново перестроить дерево и увидеть все, что появилось.
Схема прижилась и работает уже больше 10 лет. Ничего не тормозит, но нагрузка не очень велика - до полутора сотни одновременно работающих юзеров.
Вот, на картинка синим подсвечена строчка, удаленная другим юзером.
...
Рейтинг: 0 / 0
14 сообщений из 64, страница 3 из 3
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Сложность при проектировании многопользовательской БД на основе однопользовательской.
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]