Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Проектирование БД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 [3]      все
 Re: Сложность при проектировании многопользовательской БД на основе однопользовательской.  [new]
ВМоисеев
Member

Откуда: Редкино
Сообщений: 1996
>NewBy52, 3 июн 19, 11:43 [21900247]
>… есть основная таблица r_objects … есть масса вспомогательных таблиц … Логика обработки этих данных требует при указании конкретного объекта загрузить их все в память …
<Поддерживаю Dimitry Sibiryakov. Вопрос касается "широких" сущностей, много атрибутов, разумно растащить их по разным таблицам.
Имею MS SQL и поступаю так:
1. Формирую целостную сущность из многих её частей (у меня всего две) хранимой процедурой.
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. Храню изменения сущности так:
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. Относительно вопроса "грязного" чтения.
1 сен 19, 12:34    [21961437]     Ответить | Цитировать Сообщить модератору
 Re: Сложность при проектировании многопользовательской БД на основе однопользовательской.  [new]
Serguei
Member

Откуда: Papua New Guinea
Сообщений: 681
NewBy52
Но в многопользовательской среде 2 оператора могут корректировать один и то же объект (а время коррекции получается достаточно длительное) и каждый может перезаписать свою версию данных.


В вашем случае проблема пока еще в технологической плоскости, а не в технической. Сначала нужно решить а как все это должно работать, а потом искать техническое решение.
1 сен 19, 12:55    [21961445]     Ответить | Цитировать Сообщить модератору
 Re: Сложность при проектировании многопользовательской БД на основе однопользовательской.  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 48154

Что за нашествие некроспамеров?

Posted via ActualForum NNTP Server 1.5

1 сен 19, 13:06    [21961450]     Ответить | Цитировать Сообщить модератору
 Re: Сложность при проектировании многопользовательской БД на основе однопользовательской.  [new]
Serguei
Member

Откуда: Papua New Guinea
Сообщений: 681
Dimitry Sibiryakov
Что за нашествие некроспамеров?

Поясните, пожалуйста, что вы имели ввиду?
1 сен 19, 13:44    [21961458]     Ответить | Цитировать Сообщить модератору
 Re: Сложность при проектировании многопользовательской БД на основе однопользовательской.  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 48154

На даты сообщений в топике посмотри.

Posted via ActualForum NNTP Server 1.5

1 сен 19, 13:45    [21961459]     Ответить | Цитировать Сообщить модератору
 Re: Сложность при проектировании многопользовательской БД на основе однопользовательской.  [new]
Serguei
Member

Откуда: Papua New Guinea
Сообщений: 681
Dimitry Sibiryakov
На даты сообщений в топике посмотри.

3 июн 19 не так уж и давно это было.

Просто для интереса: какой возраст записи для Вас не считается некроманским? 2 недели? )
1 сен 19, 14:56    [21961467]     Ответить | Цитировать Сообщить модератору
 Re: Сложность при проектировании многопользовательской БД на основе однопользовательской.  [new]
ВМоисеев
Member

Откуда: Редкино
Сообщений: 1996
>Serguei, сегодня, 14:56 [21961467]
>… какой возраст записи …
<Да не суть, не берите в голову.
Ответа на поставленный вопрос так и нет. В моём варианте пользователь (клиентское приложение) после UPDATE имеет две версии сущности - сущность в базе данных и локальную сущность + код ошибки.
И как далее поступать? И если много изменений?
В настоящее время тупо отражаю сущность базы данных в локальную сущность, отображаю атрибуты в компонентах графического интерфейса и при необходимости сигнализирую об ошибке.
1 сен 19, 15:18    [21961470]     Ответить | Цитировать Сообщить модератору
 Re: Сложность при проектировании многопользовательской БД на основе однопользовательской.  [new]
полудух
Member

Откуда: планета орков, г.Зверополис
Сообщений: 732
vmag
да и не закрывает совсем...
ну получил я версию объекта после того как отдолбил 1000 параметров в течение двух часов и что?
- я должен понять и принять тот факт, что я два часа долбил зря, передо мной вроде как долбил крутой ?
- или я честно отработал день, а на утро увидел что вчера работал зря, мои труды потерли...
- а может у меня пусть 10 % но более правильная информация, которая ушла в никуда... ?
ИМХО тут блокировки и и всякие версии не сработают на все 100 ...

посмотрите, как в википедии сделано
1 сен 19, 18:26    [21961515]     Ответить | Цитировать Сообщить модератору
 Re: Сложность при проектировании многопользовательской БД на основе однопользовательской.  [new]
L_argo
Member

Откуда:
Сообщений: 892
полудух
посмотрите, как в википедии сделано
А чо туда смотреть ?
Сабж необходимо реализовывать исходя из логики задачи.
Чтобы новые данные не пропадали - ввести понятие данных-кандидатов. Т.е. разновидность черновика. Если там есть непротиворечивые ценные данные - после верификации поместить их в продакшн-данные. Сразу или спустя некот. время - зависит только от Б/Л.
Это чисто бизнес-логический процесс, кот. можно реализовать хоть в DBF, хоть в тхт-файлах.

Непонятно, зачем постить сюда портянки кода и умно рассуждать о блокировках в БД.
1 сен 19, 21:14    [21961548]     Ответить | Цитировать Сообщить модератору
 Re: Сложность при проектировании многопользовательской БД на основе однопользовательской.  [new]
полудух
Member

Откуда: планета орков, г.Зверополис
Сообщений: 732
L_argo
А чо туда смотреть ?

чтобы увидеть там всё то, что вы ниже описали Картинка с другого сайта.
1 сен 19, 22:53    [21961572]     Ответить | Цитировать Сообщить модератору
 Re: Сложность при проектировании многопользовательской БД на основе однопользовательской.  [new]
ldfanate
Member

Откуда:
Сообщений: 131
Кот Матроскин
NewBy52
Более того, скажу, лет 30 назад, я, по неопытности, реализовал подобное решение.

30 лет назад (в 1989 году) Вы реализовывали многопользовательскую клиент-серверную систему? На какой платформе, если не секрет?


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

И кстати, кое в чём могли поспорить с современными графическими "интерфейсами", - темп ввода в экранные формы, несмотря на отсутствие мышки, был вцелом я бы сказалвыше. Т.к. выбор в поле ввода из справочника обычно вешали на F-клавиши, навигация по полям ввода - enter-ом (а не уродским Табом, который ну совсем в неудобном углу клавиатуры), выбор (выделение) позиций грида для массовой обработки - обычно пробелом или Ins (который сразу сдвигал курсор вниз на 1 запись). Никто эргономически-уродские решения с галочками, в которые нужно целиться мышью, махая клешнями то на мышь то на клавиатуру (и постраничным листанием гридов) не применял (и даже не снил себе в кошмарном сне :).
Так что всё норм было на рубеже 80-90ых. И даже встроенный интерпретатор с отладчиком прямо в откомпиленную софтину клиптцер по крайней мере умел прилепливать, очень помогало в отладке-трассировке тяжёлых случаев.
2 сен 19, 09:56    [21961653]     Ответить | Цитировать Сообщить модератору
 Re: Сложность при проектировании многопользовательской БД на основе однопользовательской.  [new]
ВМоисеев
Member

Откуда: Редкино
Сообщений: 1996
>NewBy52, 3 июн 19, 14:01 [21900485]
>...Потому что многие записи расчетные…
<Мне не приходилось хранить 2000+ расчетных данных в "лоб". Имею дело с географическими объектами (сущностями) не точечного размера. Граница сущности задаётся вершинами многоугольника, кругом, эллипсом, сегментом. Число точек границы не более 20(пока). Для пробы не стал записывать параметры границы по точечно в дополнительную таблицу базы данных - сериализовал значения в byte[] и записал одним полем в запись базовой таблицы сущности. Думаю, что тоже самое можно сделать и с 2000+.
Если данных очень много, то аппроксимация сплайнами, но это уже другая задача.
2 сен 19, 16:21    [21962022]     Ответить | Цитировать Сообщить модератору
 Re: Сложность при проектировании многопользовательской БД на основе однопользовательской.  [new]
L.Otujktd
Member

Откуда:
Сообщений: 69
NewBy52
Добрый день!
Есть однопользовательская БД, которая нормально спроектирована и работает на SQLite. Сейчас возникла задача сделать её многопользовательской на основе MS SQL Server или чём-то подобном.
Сложность заключается в следующем: есть основная таблица r_objects, где находятся некие объекты, упорядоченные в виде дерева. И есть масса вспомогательных таблиц, данные в которых принадлежат конкретному объекту.
Логика обработки этих данных требует при указании конкретного объекта загрузить их все в память, и там обрабатывать (корректировать, выполнять расчеты, представлять в виде графиков и т.д.)
После выполнения всех действий, если возникли изменения в данных (а они могут кардинально поменяться), необходимо записать данные обратно. Пока это однопользовательская БД, это нормально.
Но в многопользовательской среде 2 оператора могут корректировать один и то же объект (а время коррекции получается достаточно длительное) и каждый может перезаписать свою версию данных. Ситуация усугубляется тем, что пользователи могут быть разнесены на тысячи километров.
Вопрос: как синхронизировать такие коллизии?

Насколько это будет быстро работать? По сабжу я бы делал третью базу в которую бы хранил только изменения конкретных записей и конфликты, если они будут возникать на уровне строк. А что требуется получить на выходе-то?
2 сен 19, 21:59    [21962171]     Ответить | Цитировать Сообщить модератору
 Re: Сложность при проектировании многопользовательской БД на основе однопользовательской.  [new]
ёёёёё
Member

Откуда:
Сообщений: 729
NewBy52
Добрый день!
Есть однопользовательская БД, которая нормально спроектирована и работает на SQLite. Сейчас возникла задача сделать её многопользовательской на основе MS SQL Server или чём-то подобном.
Сложность заключается в следующем: есть основная таблица r_objects, где находятся некие объекты, упорядоченные в виде дерева. И есть масса вспомогательных таблиц, данные в которых принадлежат конкретному объекту.
Логика обработки этих данных требует при указании конкретного объекта загрузить их все в память, и там обрабатывать (корректировать, выполнять расчеты, представлять в виде графиков и т.д.)
После выполнения всех действий, если возникли изменения в данных (а они могут кардинально поменяться), необходимо записать данные обратно. Пока это однопользовательская БД, это нормально.
Но в многопользовательской среде 2 оператора могут корректировать один и то же объект (а время коррекции получается достаточно длительное) и каждый может перезаписать свою версию данных. Ситуация усугубляется тем, что пользователи могут быть разнесены на тысячи километров.
Вопрос: как синхронизировать такие коллизии?

У меня есть что-то похожее.

Сделано следующим образом.
Дерево отображается так, как будто юзер работает один, не обращая внимания на других юзеров. Данные из базы в дерево грузятся не сразу, а через кэш. Кэш - небольшой, на пару экранов. Что это дает. При изменении данных одним из юзеров все заинтересованные получают извещение об изменении. Получив сообщение, клиентская часть сбрасывает кэш и выполняет команду перерисовать видимую часть дерева. В результате в кэш из базы подтягиваются свежие данные.
При этом, измененные элементы сразу отображаются. Удаленные элементы отображаются как пустые строки, поэтому на экране ничего не "прыгает". Добавленные элементы не видны, за исключением случая, когда они добавлены во вложенные свернутые уровни, при этом меняется иконка уровня (появляется "крестик" - значит, внутри что-то есть). А также подсвечивается кнопка "обновить", по которой можно заново перестроить дерево и увидеть все, что появилось.
Схема прижилась и работает уже больше 10 лет. Ничего не тормозит, но нагрузка не очень велика - до полутора сотни одновременно работающих юзеров.
Вот, на картинка синим подсвечена строчка, удаленная другим юзером.

К сообщению приложен файл. Размер - 16Kb
3 сен 19, 10:08    [21962266]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 [3]      все
Все форумы / Проектирование БД Ответить