powered by simpleCommunicator - 2.0.49     © 2025 Programmizd 02
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Момент по проектированию БД
10 сообщений из 10, страница 1 из 1
Момент по проектированию БД
    #39627290
Sergey-2008
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Доброе время суток,

Ситуация следущая:
Имеется несколько отделов и плановый отдел.
Все отделы имеют право состовлять договора, но только плановый может назначать уже сделанным договорам номера (поле «number») и если что отправлять их в архив (статут «архив» поле «archive»).

Т.к. большинство полей совпадает, то у меня все договора по всем отделам в том числе и планового, содержатся в одной таблице.

Наверняка, в процессе работы с БД, появятся коллизии в плане редактирования одной и той же записи в одно время обычным и плановым отделом.
Например когда обычный отдел редактирует свой договор, а плановый отдел захочет присвоить ему номер, то сохранится та запись (того dataset), которая позже сохранилась, или такая же ситуация может произойти с редактированием поля «archive».

Для избежания таких ситуаций (с одновременным доступом к одной той же записи), мне наверно нужно перенести общие поля (такие как «number» и «archive») в другую таблицу с конкретным ID записи конечно. Ну а потом для просмотра инфо по договору, делать объединение.

Вопрос: Это правильный выход, чтоб избежать этой ситуации? Или есть еще вариант?

Спасибо за ответ
...
Рейтинг: 0 / 0
Момент по проектированию БД
    #39627292
Кот Матроскин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Sergey-2008Доброе время суток,

Ситуация следущая:
Имеется несколько отделов и плановый отдел.
Все отделы имеют право состовлять договора, но только плановый может назначать уже сделанным договорам номера (поле «number») и если что отправлять их в архив (статут «архив» поле «archive»).

Т.к. большинство полей совпадает, то у меня все договора по всем отделам в том числе и планового, содержатся в одной таблице.

Наверняка, в процессе работы с БД, появятся коллизии в плане редактирования одной и той же записи в одно время обычным и плановым отделом.
Например когда обычный отдел редактирует свой договор, а плановый отдел захочет присвоить ему номер, то сохранится та запись (того dataset), которая позже сохранилась, или такая же ситуация может произойти с редактированием поля «archive».

Для избежания таких ситуаций (с одновременным доступом к одной той же записи), мне наверно нужно перенести общие поля (такие как «number» и «archive») в другую таблицу с конкретным ID записи конечно. Ну а потом для просмотра инфо по договору, делать объединение.

Вопрос: Это правильный выход, чтоб избежать этой ситуации? Или есть еще вариант?

Спасибо за ответ

Команда обновления UPDATE обновляет конкретные указанные поля, а не запись целиком. Если Ваша клиентская библиотека доступа к данным ("dataset") этого не умеет - правильнее фиксить ее, а не проектировать БД специально под кривую библиотеку.
Другое дело, что если Вы активно пользуетесь встроенной в СУБД системой безопасности, то разделение на 2 таблицы
поможет выдать права на изменение number и archive только тем пользователям (в Вашем случае - плановому отделу), которым это нужно.
Т.е. сделать так, как Вы предлагаете - можно, это не то чтобы очень криво, но для решения другой проблемы :) А разруливание одновременного доступа к данным лучше решать иначе.
...
Рейтинг: 0 / 0
Момент по проектированию БД
    #39627293
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Sergey-2008Это правильный выход, чтоб избежать этой ситуации? Или есть еще вариант?

Неправильный. Лучше написать приложение с расчётом на оптимистическую блокировку. Чтобы
оно обнаруживало конфликт, анализировало его и автоматически устраняло, повторно накатывая
изменения пользователя если они не конфликтуют с уже произведёнными. Или вываливало эту
информацию пользователю чтобы он сам как-нибудь всё разрулил.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Момент по проектированию БД
    #39627294
Фотография Дедушка
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Sergey-2008Для избежания таких ситуаций (с одновременным доступом к одной той же записи), мне наверно нужно перенести общие поля (такие как «number» и «archive») в другую таблицу с конкретным ID записи конечно. Ну а потом для просмотра инфо по договору, делать объединение.используя вашу аналогию...
обычный отдел хочет редактировать свой договор, а в это время плановый меняет ему номер в этой вашей отдельной таблице
(объединение по ID, одновременный доступ, коллизия)?

любая реляционная субд имеет механизмы для управления доступом к одной и той же записи
и вы как разработчик должны их использовать как вам нужно (уровень изоляции, индексы и тд.)
если вы при запросе договора не лочите эту запись для всех остальных (что может быть нужно по вашей бизнес логике)
то совершенно не важно, что обычный отдел меняет например поле description договора, плановый спокойно поменяет ему номер.
...
Рейтинг: 0 / 0
Момент по проектированию БД
    #39627295
Sergey-2008
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Кот МатроскинКоманда обновления UPDATE обновляет конкретные указанные поля, а не запись целиком. Если Ваша клиентская библиотека доступа к данным ("dataset") этого не умеет - правильнее фиксить ее, а не проектировать БД специально под кривую библиотеку.
Я пользуюсь "TIBDataSet" для просмотра и модификации набора записей (с вкладки "InterBase" (Delphi)).

Я правильно вас понял: что в таком случае, в "IBDataSet" (для простых отделов), нужно отредактировать свойство "ModifySQL" а именно убрать из него "номер договора" и "статус архива"..., а в "IBDataSet" (для планового отдела), отредактировать свойство "ModifySQL", так чтобы при выборе записи ( составленной в простом отделе ) обновлять только "номер договора" и "статус архива"...

Т.е. в плановом отделе при просмотре договоров, нужно все время менять свойство "ModifySQL" (оставлять все поля или только поля "номер договора" и "статус архива"), взависимости от того какой договор просматривается (сделанный простым отделом или плановым)
...
Рейтинг: 0 / 0
Момент по проектированию БД
    #39627297
Фотография Дедушка
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Sergey-2008,

по Delphi есть отдельный форум
вопрос использования конкретного компонента это не вопрос проектирования БД
напишите на уровне БД процедуры изменения/доступа к данным и используйте в вашем компоненте
...
Рейтинг: 0 / 0
Момент по проектированию БД
    #39627298
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Sergey-2008Я пользуюсь "TIBDataSet" для просмотра и модификации набора записей

А, ну тогда Вам туда можно.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Момент по проектированию БД
    #39627313
Фотография vmag
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Sergey-2008Ситуация следущая:
Имеется несколько отделов и плановый отдел.
Все отделы имеют право состовлять договора, но только плановый может назначать уже сделанным договорам номера (поле «number») и если что отправлять их в архив (статут «архив» поле «archive»).

Ситуация не очень:
Может получиться каша, допустим договоров много, отдел рождает очередной договор (он что без номера вообще или какой-то временный счетчик ?), потом плановый отдел присваивает номер - как потом искать договор если временный номер поменяли на реальный ?
Мне понравилась система в одной из контор:
- юзеры логинятся в системе договоров и идентифицируют себя по принадлежности к отделу.
- естественно при этом видят не всю кашу, а только свои договора, с возможностью переключения отображения действющие/архивные/все договора
- при создании нового договора, номер договора автоматически генерируется процедурой, например:
* 1-ОЗ-2018 это значит первый договор отдела закупок в 2018 году
* 3-ОР-2018 это значит третий договор отдела реализации в 2018 году
Ну а плановому отделу остается только перемещать договора в архив...
Какая может быть проблема в связи с этим в Вашем случае ?
Только одна - если плановому отделу в конце концов нужна сплошная нумерация за всю организацию...
Её можно решить так - добавить еще одно поле договора для планового отдела, которое доступно для корректировки только плановому отделу, а другим отделам в интерфейсе только для просмотра, в этом случае другим отделам будет видно - если это поле пустое, значит договор плановым отделом еще не обработан...
В выше описанной конторе обходятся без этого дополнительного поля и по номеру договора уже понятно откуда ноги растут...
...
Рейтинг: 0 / 0
Момент по проектированию БД
    #39627513
Фотография битый
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Sergey-2008Доброе время суток,

Ситуация следущая:
Имеется несколько отделов и плановый отдел.
Все отделы имеют право состовлять договора, но только плановый может назначать уже сделанным договорам номера (поле «number») и если что отправлять их в архив (статут «архив» поле «archive»).

Т.к. большинство полей совпадает, то у меня все договора по всем отделам в том числе и планового, содержатся в одной таблице.

Наверняка, в процессе работы с БД, появятся коллизии в плане редактирования одной и той же записи в одно время обычным и плановым отделом.
Например когда обычный отдел редактирует свой договор, а плановый отдел захочет присвоить ему номер, то сохранится та запись (того dataset), которая позже сохранилась, или такая же ситуация может произойти с редактированием поля «archive».

Для избежания таких ситуаций (с одновременным доступом к одной той же записи), мне наверно нужно перенести общие поля (такие как «number» и «archive») в другую таблицу с конкретным ID записи конечно. Ну а потом для просмотра инфо по договору, делать объединение.

Вопрос: Это правильный выход, чтоб избежать этой ситуации? Или есть еще вариант?

Спасибо за ответДобавляете поле статус. При создании значение "Черновик". Сотрудник обычного отдела может менять все поля, кроме номера и переводить статус в "Готово". После этого никто не может изменять запись, кроме планового отдела, который может присвоить номер или перевести статус в "Черновик", если договор требует доработки.
...
Рейтинг: 0 / 0
Момент по проектированию БД
    #39627881
Cane Cat Fisher
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Мне кажется, все гораздо проще. Насколько я понимаю, плановый отдел не правит содержимое чужих договоров, а только присваивает номер и меняет статус на архивный.

Если так, то для работы с чужими договорами плановому отделу нужен инструмент с двумя кнопками: "Назначить номер" и "Отправить в архив (или обратно)", которые будут посылать

Код: sql
1.
update ДОГОВОРА set НОМЕР = xxxxx


и
Код: sql
1.
update ДОГОВОРА set АРХИВНЫЙ = 1



соответственно.

А редактор содержимого договора (для простого отдела) настроить так, чтобы он в своем update поля НОМЕР и АРХИВНЫЙ вообще не посылал.

Тогда и конфликта никакого не будет - технически работать можно одновременно.

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


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