powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Выбор архитектуры
5 сообщений из 5, страница 1 из 1
Выбор архитектуры
    #36382027
ClearSky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Здравствуйте. Хочу спросить, насколько корректно следующее проектное решение.
Есть класс
TClient - клиент
TOrder - счет
TOrders - класс контейнер (коллекция), который является списком счетов клиента где каждый элемент имеет тип TOrder.
Объект Client ссылается на объект Orders через поле Client.Orders

При выборе клиента из базы создаются объекты Client, Orders. Поля объекта Client заполняются личными данными клиента, в коллекцию Orders добавляются объекты Order, каждый из которых содержит информацию о конкретном счете.
На основе прочитанных из БД данных строится древовидное меню вида

Клиент (Иванов Иван)
|
Счета
|
Счет №1 сумма 100
|
Счет №2 сумма 200
|
Счет №3 сумма 300

Каждый нод ссылается на соответствующий объект Order. Таким образом при двойном клике на том или ином ноде мы получаем ссылку на соответствующий объект (Order) и передаем ее в редактор счета, где оператор может отредактировать поля данного объекта. После окончания редактирования данные обновляются в базе.

Вроде бы все просто и красиво, однако получается, что данные после чтения из базы оказываются прокешированны у оператора и не синхронизированы с БД.

Например, два оператора одновременно открыли одного клиента. У обоих в приложении создались идентичные объекты с идентично заполненными полями. Затем один оператор удалил счет №1, а второй оператор в это время его отредактировал и попытался записать. Таким образом получается что в базе данных счета уже нет а программный объект у второго оператора все равно присутствует в коллекции.
Аналогичная история происходит и с обновлением данных. Один оператор редактирует счет и при этом не знает, что другой оператор его тоже редактирует. Таким образом в БД сохраниться информация от того оператора, который последним нажал кнопку "обновить".

Получается, что чем больше в приложении создается объектов тем больше вероятность рассогласования данных.

Вопрос! Приемлемо ли это проектное решение в рамках описанного прецедента или есть более рациональные решения?
Спасибо.
...
Рейтинг: 0 / 0
Выбор архитектуры
    #36382135
trdm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ClearSkyХочу спросить, насколько корректно следующее проектное решение.
нет.
...
Рейтинг: 0 / 0
Выбор архитектуры
    #36382145
ClearSky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
trdm,

Какое же тогда решение будет корректным?
...
Рейтинг: 0 / 0
Выбор архитектуры
    #36382152
trdm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ClearSkytrdm,
Какое же тогда решение будет корректным?
Которое вы примете после добросовесного изучения курса по реляционным базам данных.

Модератор: Тема перенесена из форума "Разработка информационных систем".
...
Рейтинг: 0 / 0
Выбор архитектуры
    #36382212
muk07
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Проходил это 2 раза.
Создавал систему классов.
Закачивал из БД, затем обрабатывал.
Получал
1) ужасно медленную работу
2) отсутствие изоляции транзакций
С тех пор стараюсь все операции выполнять только на сервере.
Получается компактнее, проще, меньше ошибок.
...
Рейтинг: 0 / 0
5 сообщений из 5, страница 1 из 1
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Выбор архитектуры
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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