ReSQL.ru
     
powered by simpleCommunicator - 2.0.60     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Схема добавления записи в отношении один-ко-многим
6 сообщений из 6, страница 1 из 1
Схема добавления записи в отношении один-ко-многим
    #32694772
Stas Tristan
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Stas Tristan
Участник
Иcходные данные:
1. Произвольный сервер баз данных
1.1. Родительская таблица Customers:
-CustomerID - первичный ключ
-CustomerName - обязательное
-Еще много каких-то полей
1.2. Дочерняя таблица Orders:
-OrderID - первичный ключ
-CustomerID - внешний ключ [следящий за тем, чтобы небыло записей без родителя] (заключил в квадратные скобки для того, чтобы можно было убрать это правило)
-OrderDate - обязательное
-Еще много каких-то полей
1.3. Вся бизнес-логика и поддержка целостности запрограммирована на сервере
2. Клиент
2.1. Форма ввода для пользователя, где запись из таблицы Customers выглядит в виде последовательности различных элементов управления, представляющих каждый отдельное поле, а подчиненные записи Orders - встроенная табличная sub-форма
2.2 Форма ввода при открытии (если задан режим добавления) запрашивает у сервера новый CustomerID и заполняет соответствующее поле этим значением

Собственно мне нужно правильно выбрать схему добавления такой комплексной записи.
Обратить внимание следует на обязательные поля в обоих таблицах. Рассмотрим ситуацию когда пользователь начинает добавлять записи в табличную подформу, не заполнив при этом обязательное поле CustomerName в родительской записи. В этом случае получается такая последовательность:
1. Пользователь заполнил одну строку в табличной подформе и пытается ее сохранить (при этом CustomerID копируется автоматически из CustomerID родительской записи)
2. Сервер обнаруживает, что записи с таким CustomerID в таблице Customers еще нет и выдает ошибку, на которую я вешаю программу для сохранения родительской записи
3. Сервер говорит что не может сохранить родительскую запись, так как не заполнено обязательное поле CustomerName
4. И вот эту ошибку я выдаю, наконец, пользователю, автоматически направив курсор на нужный элемент управления.

Интересно услышать мнение гуру по этой теме – мне хочется, чтобы пользователь смог добавлять записи в дочернюю подформу (и чтобы сервер при этом проверял обязательные поля в этих дочерних записях), при этом не заполняя пока все обязательные поля в родительской записи. Как можно (если вообще возможно) реализовать такое?
...
Рейтинг: 0 / 0
14.09.2004, 23:48
| Ответить | Цитировать | Написать  
Схема добавления записи в отношении один-ко-многим
    #32694784
Фотография ASCRUS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ASCRUS
Участник
Для каждого средства будут свои приемы. Например, у меня на PB сложные формы ввода данных (документов) через визарды делаются, где пользователь заполняет все поочередно странички визарда данными, а потом при нажатии на кнопку "Готово" сохраняется первая (главная) страничка и все последующие (дочерние). которые уже при сохранении используют полученный IDENTITY добавленной записи главной таблицы. Во время сохранения статусы записей страничек не сбрасываются, поэтому если произошла ошибка, то визард автоматом вызывает ROLLBACK, в БД все откатывается, а измененные записи остаются помеченными для сохранения их в БД, что позволяет юзеру исправить найденные сервером ошибки и снова попробовать операцию сохранения данных. После успешного сохранения всех страничек визард делает COMMIT и прекращает работу, передавая IDENTITY на выход формы, чтобы его мог считать вызвавший ее обьект. Однако все это возможно благодаря тому, что PB работает по принципу "отложенных изменений" (то есть набор данных отвязан от БД, его можно менять сколько угодно, потом все изменения ложаться на базу методом Update). Во вторых в PB поддерживается Embedded SQL (возможность прямо писать в коде программы SQL операторы). В третьих он обьектно-ориентированный, что позволило мне сделать этот визард в виде отдельного окна-компоненты и легко пользоваться в приложениях, рисуя в наследниках от визарда просто нужные странички и правила их редактирования, без затрагивания центральной логики управления самого визарда, которая полностью реализована в предке, отлажена и общается со страничками посредством событийной модели PB.

P.S. Кстати если вопрос не чисто "теоретический", а практический, то есть именно к гуру Access-а, то по идее Вам этот вопрос нужно бы задавать в том форуме. Однако в любом случае я считаю, что ввод любого документа с множеством подчиненной информации в БД должен происходить в пределах одной транзакции БД, чтобы не получилось, что шапка документа введена, а на детализации юзера выбило в ошибку и он просто вышел из программы.
...
Рейтинг: 0 / 0
15.09.2004, 00:43
| Ответить | Цитировать | Написать  
Схема добавления записи в отношении один-ко-многим
    #32694794
Stas Tristan
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Stas Tristan
Участник
Сервер БД - PostgreSQL, клиент на платформе .NET с отсоединенными Dataset
...
Рейтинг: 0 / 0
15.09.2004, 02:24
| Ответить | Цитировать | Написать  
Схема добавления записи в отношении один-ко-многим
    #32695186
Один
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Один
Участник
ASCRUS
P.S. Кстати если вопрос не чисто "теоретический", а практический, то есть именно к гуру Access-а, то по идее Вам этот вопрос нужно бы задавать в том форуме. Однако в любом случае я считаю, что ввод любого документа с множеством подчиненной информации в БД должен происходить в пределах одной транзакции БД, чтобы не получилось, что шапка документа введена, а на детализации юзера выбило в ошибку и он просто вышел из программы.
Поддерживаю.
Но есть одна тонкость. Если существует вероятность, что с БД будут общаться не только из "родного" приложения, имеет смысл продумать сохранение таких документов единым пакетом. Например формировать XML, CSV и т.п., который целиком отправляется на сервер и там распарсивается и добавляется в БД. Организовать это с помощью SP и запретить добавлять строки в таблицы напрямую. Иногда этим удается добиться увеличения скорости добавления.
Потому что "левая" программа может сделать как раз такую бяку, о которой Вы говорили, шапку ввели, а остальное забыли.
Я понимаю, что ситуация редкая, а трудоемкость такого подхода возрастает, но иногда бывает нужно.
...
Рейтинг: 0 / 0
15.09.2004, 11:08
| Ответить | Цитировать | Написать  
Схема добавления записи в отношении один-ко-многим
    #32695438
Фотография Old Nick
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Old Nick
Участник
В системе NEXUS как реализован такой подход.

Есть таблица Details в которую каждый эелемент заносится в виде строки, подчиненные таблицы также имеют парентом ID шапки и свои элементы тоже в виде строк заносят. Например, случай с Customers будет выглядеть так (приблизительно):

ID Name Value ParentID
1 CustomerName 'Петров' 0 - поле шапки, если будет еще адрес, то второй строкой
2 Orders 'Заказы' 1 - описание таблицы
3 Record '1' 2 - первая строка таблицы
4 GoodName 'Хлеб' 3 - поле первой строки
5 GoodProce '10 р.' 3 - поле первой строки
6 Record '2' 2 - вторая строка
7 GoodName 'Масло' 6 - поле второй строки
8 GoodProce '20 р.' 6 - поле второй строки

к этой таблице клиент имеет свободный доступ и еще имеет доступ к одной процедуре, которая обрабатывает события, например для сохранения, вызывается событие, назовем его 'Save', эта процедура зная класс объекта Заказ вызывает хранимые процедуры циклически начиная от базового до текущего <ClassName>_Save которые из этой таблички данные кладут уже туда куда нужно. И все это в транзакции.
...
Рейтинг: 0 / 0
15.09.2004, 12:32
| Ответить | Цитировать | Написать  
Схема добавления записи в отношении один-ко-многим
    #32696142
Фотография ASCRUS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ASCRUS
Участник
Если СУБД поддерживает глобальные временные сессионные таблицы (то есть таблица видна для каждой сессии, но данные в ней у каждой сессии свои), то все можно реализовать через них: сохранять все данные с клиента сначала в них, а потом уже через ХП с них переносить данные в базовые таблицы. Так же вместо ХП можно создать в времянке, которая хранит шапку, что то типа флага "Проведено" и повесить на эту таблицу триггер, который при выставлении флага автоматом все проверяет и переносит данные в соотвествующие базовые таблицы. В общем все зависит от возможностей СУБД - чем она функциональнее, тем больше подходящих решений под конкретные задачи можно красиво и граммотно реализовать. Например, казалось бы - такой пустяк в ASA - возможность писать свои события на разные ситуации, а позволяет создать событие на подключение сессии и например, контролировать, что к БД не может быть подключено больше 3 сессий. А событие на отключение сессии позволяет очень красиво разруливать искусственно созданные блокировки, которые например, контролируют, что во время редактирования документа никто его больше изменить не может. Ну и т.д. и т.п. :)

Код: plaintext
1.
_________________________
работаю, никого не трогаю
...
Рейтинг: 0 / 0
15.09.2004, 16:49
| Ответить | Цитировать | Написать  
6 сообщений из 6, страница 1 из 1
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Схема добавления записи в отношении один-ко-многим
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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