|
Вопрос # 4 521/ вопрос открыт / |
|
Доброго времени суток, уважаемые эксперты! Пишу клиентское приложение на Delphi под БД в InterBase 6.5.
Вот примерный фрагмент из структуры базы данных (http://dl.dropbox.com/u/1802652/CDM_MP.JPG).
Есть таблица заказов, связанная отношением 1:* с таблицей состава заказа, где хранятся заказанные позиции, информация о товарах храниться в отдельном справочнике.
Хотелось бы узнать, как наиболее рационально организовать процесс добавления заказа.
На данный момент решил делать так:
1. сохраняю инф-у о выбранных товарах (id товара из справочника, его количество) в отдельных переменных;
2. при подтверждении заказа, создаю новую запись в таблице заказов;
3. создаю записи о заказанных товарах в таблице состав заказа, связанные с последним добавленным заказом.
Худо-бедно такой вариант работает, но что-то мне подсказывает, что есть более рациональный способ реализовать этот момент, а велосипед изобретать не хотелось бы. Возможно, кто-нибудь подскажет литературу по теме или шаблонную реализацию этой операции.
 |
Вопрос задал: protozo (статус: Посетитель)
Вопрос отправлен: 20 августа 2010, 18:13
Состояние вопроса: открыт, ответов: 2.
|
Ответ #1. Отвечает эксперт: Вадим К
Здравствуйте, protozo!
Есть ещё два варианта.
1) никто не запрещает добавлять эти данные в таблицу сразу. То есть пользователь выбрал товар - мы добавили в таблицу. Но заведем ещё одно поле, которое хранит флажок "в состоянии заказа". Если пользователь отказался от заказа, мы просто удаляем с таблицы помеченные записи для данного пользователя. Если же пользователи анонимны, то придется делать поле "пользователь", куда писать какой нибудь уникальный номерок(например банальный инкремент), что бы их различать. Это такое универсальное решение. под любую базу.
Но есть решение покрасивее. Оно основано на управлениями транзакциями. Перед началом добавления данных стартуем транзакцию. Потом делаем с таблицами, что хотим -добавляем/удаляем записи. Когда пользователь подтвердил заказ - просто делаем commit транзакции. Если пользователь отказался - делаем rollback и все возвращается на свои места.
Если же будет два пользователя или более одновременно, то ничего плохого не случиться - InterBase как нормальная база умеет разруливать такие ситуации.
Единственное, что бы показывать пользователю выбранные им товары, нужно делать чтение в том же подключении, иначе добавленные данные не будут видны (на самом деле можно подключиться в режиме сырого чтения и видеть все данные, но это для отладки:) ).
 |
Ответ отправил: Вадим К (статус: Академик)
Время отправки: 20 августа 2010, 18:51
|
Ответ #2. Отвечает эксперт: Тов. Женька
Здравствуйте, protozo!
Я присоединяюсь к Вадиму и рекомендую вам пользоваться преимуществами, которые предоставляет Interbase.
Со своей стороны могу предложить подход с временными таблицами типа ClientDataSet или MemTableEh.
При формировании заказа необходимые сведения о заказе можно разместить в них, и уже потом при сохранении заказа, запустить транзакцию, внести данные из временной таблицы в реальную, через триггер "списав" необходимое количество товара или сообщить о его недостаточности.
Опять же тут можно поиграться с фиксацией транзакции. Можно ее коммитить после каждой записи, или же блоком - после внесения всех записей. Первый подход несколько повышает нагрузку на сервер, но дает возможность сохранить какую-то часть заказа в случае потери связи с сервером. Во втором случае нагрузка снижается (всего одна транзакция), но и в случае чего заказ придется полностью перезабивать.
В общем случае такой подход имеет и недостаток. Суть его заключается в том, что записи не блокируются и выбранный вами товар сможет "перехватить" другой заказчик.
Можно, конечно, поступить, как предложил Вадим, заблокировать нужные записи через транзакции и сколь угодно долго с ними развлекаться. Но такой подход не позволит другим пользователям обратиться к этому же товару, они будут вынуждены ждать завершения вашей транзакции. А вдруг она затянется?
Если же попробовать совместить эти два варианта, и помня, что читающие транзакции могут быть сколь угодно длинными, а пишущие максимально короткими, то получим следующее. В момент выбора товара, списываем сразу же необходимое количество (тогда другие заказчики уже не перехватят ваш товар и смогут работать с тем, что осталось), вносим данные по выбранному товару во временную таблицу. В конце, когда заказ окончательно подтвержден, из временной таблицы вносим данные в реальную таблицу одним из предложенных в начале способов. А в случае отмены. опираясь на те же сведения из временной таблицы, возвращаем товар на место.
 |
Ответ отправил: Тов. Женька (статус: 3-ий класс)
Время отправки: 21 августа 2010, 10:28
|
Мини-форум вопроса
Мини-форум пуст.
Чтобы оставлять сообщения в мини-форумах, Вы должны авторизироваться на сайте.
|
