|
Проверка наличия записи
|
|||
---|---|---|---|
#18+
Здравствуйте. Пишу сейчас программу типа склада. Хотелось бы уточнить некоторые нюансы, а именно: Пользователь выбирает нужную запись из таблицы Товаров, в textboxе пишет нужное количество и нажимает на кнопку и запись добавляется во временную таблицу (формирование заказов). Вопрос состоит в следующем. После добавления записи может такое быть что пользователь захочет добавить эту запись еще раз (т.е увеличить количество нужного товара и добавить его к ранее добавленному). Как мне проверить наличие этой записи и если такова имеется как мне прибавить количество к ранее добавленному количеству и записать обратно в БД. Заранее спасибо за ответ ... |
|||
:
Нравится:
Не нравится:
|
|||
24.07.2013, 18:33 |
|
Проверка наличия записи
|
|||
---|---|---|---|
#18+
guest786Здравствуйте. Пишу сейчас программу типа склада. Хотелось бы уточнить некоторые нюансы, а именно: Пользователь выбирает нужную запись из таблицы Товаров, в textboxе пишет нужное количество и нажимает на кнопку и запись добавляется во временную таблицу (формирование заказов). Вопрос состоит в следующем. После добавления записи может такое быть что пользователь захочет добавить эту запись еще раз (т.е увеличить количество нужного товара и добавить его к ранее добавленному). Как мне проверить наличие этой записи и если такова имеется как мне прибавить количество к ранее добавленному количеству и записать обратно в БД. Заранее спасибо за ответСделайте хранимку для insert. Если запись существует, выполняйте update, иначе insert. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.07.2013, 18:48 |
|
Проверка наличия записи
|
|||
---|---|---|---|
#18+
guest786, все зависит от архитектуры, например если у вас есть класс заказ и он содержит коллекцию заказанных товаров, то при добавлении товара можно пройти по коллекции и определить был ли товар добавлен раннее, если был то обновить количество, если не был, то добавить товар в коллекцию, и уже когда полностью заказ сформирован только тогда добавлять его в БД, другие варианты решения более трудозатратны. И вообще использование БД на этапе ввода данных крайне неудобный вариант, работайте с классами описывающими сущности. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.07.2013, 13:27 |
|
Проверка наличия записи
|
|||
---|---|---|---|
#18+
mmnickИ вообще использование БД на этапе ввода данных крайне неудобный вариант, работайте с классами описывающими сущности. И чем тут классы помогут? igr_okСделайте хранимку для insert. Если запись существует, выполняйте update, иначе insert. +1. Стандартное решение. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.07.2013, 20:14 |
|
Проверка наличия записи
|
|||
---|---|---|---|
#18+
Cat2, без хранимки никак? ... |
|||
:
Нравится:
Не нравится:
|
|||
25.07.2013, 22:08 |
|
Проверка наличия записи
|
|||
---|---|---|---|
#18+
Cat2mmnickИ вообще использование БД на этапе ввода данных крайне неудобный вариант, работайте с классами описывающими сущности. И чем тут классы помогут? igr_okСделайте хранимку для insert. Если запись существует, выполняйте update, иначе insert. +1. Стандартное решение. автор как мне прибавить количество к ранее добавленному количеству и записать обратно в БД. Внимательно читайте вопрос, пользователь открывает заказ на редактирование , причем тут БД и хранимки, или "нехранимки", после редактирования заказа пользователь обратно записывает его в БД ... |
|||
:
Нравится:
Не нравится:
|
|||
26.07.2013, 10:15 |
|
Проверка наличия записи
|
|||
---|---|---|---|
#18+
МСУCat2, без хранимки никак? Можно и без хранимки. Открываем транзакцию на клиенте. Блокируем таблицу. Проверяем наличие записи. Если есть, делаем апдейт, если нет - инсерет. Снимаем блокровку Завершаем транзакцию. Все хорошо, но только есть риск, что клиент обрубиться и не сможет завершить транзакцию. Конечно, сейчас не 90-ые, когда зависшая на крлиенте транзакция блокировала таблицы навсегда. Сейчас "через некое разумное время" блокировка снимается. "Разумное время" засекречено производителями . Однако в некоторых случаях и 30 секунд - неприемлемое время. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.07.2013, 21:19 |
|
Проверка наличия записи
|
|||
---|---|---|---|
#18+
mmnickВнимательно читайте вопрос, пользователь открывает заказ на редактирование , причем тут БД и хранимки, или "нехранимки", после редактирования заказа пользователь обратно записывает его в БД И действительно, причем тут БД ? ... |
|||
:
Нравится:
Не нравится:
|
|||
26.07.2013, 21:21 |
|
Проверка наличия записи
|
|||
---|---|---|---|
#18+
Cat2есть риск, что клиент обрубиться и не сможет завершить транзакцию. То есть про секцию try-finally мы никогда не слышали? ... |
|||
:
Нравится:
Не нравится:
|
|||
26.07.2013, 21:49 |
|
Проверка наличия записи
|
|||
---|---|---|---|
#18+
МСУCat2есть риск, что клиент обрубиться и не сможет завершить транзакцию. То есть про секцию try-finally мы никогда не слышали? Слышал краем уха. Только если клиент грохнется, например, по отрубу питания во время выполнения блока try, то до finally дело не дойдет ... |
|||
:
Нравится:
Не нравится:
|
|||
26.07.2013, 23:40 |
|
Проверка наличия записи
|
|||
---|---|---|---|
#18+
Cat2Все хорошо, но только есть риск, что клиент обрубиться и не сможет завершить транзакцию. казалось бы причём здесь трёхзвенка..... ... |
|||
:
Нравится:
Не нравится:
|
|||
27.07.2013, 11:05 |
|
Проверка наличия записи
|
|||
---|---|---|---|
#18+
Cat2МСУпропущено... То есть про секцию try-finally мы никогда не слышали? Слышал краем уха. Только если клиент грохнется, например, по отрубу питания во время выполнения блока try, то до finally дело не дойдет 1. Ты "сервер приложений" клиентом называешь? Прости, но если сервер приложений так просто "отрубается от питания", то мне остается только плакать. Срочно читать про балансировщик нагрузки и кластеризацию. 2. Если же ты про двухзвенку, то я даже разговаривать на эту тему не хочу. Таким решениям место на свалке. Клиент ничего не должен знать про БД, никаких транзакций с клиента. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.07.2013, 11:56 |
|
Проверка наличия записи
|
|||
---|---|---|---|
#18+
МСУ, тут можно и обойти центральное хранилище, портфель заказов держать локально ( локальное хранилище) а при "Заказать" производить перелив в центральное, в любом случае после этой манипуляции, что то сделать с заказом уже нельзя - он отдан на формирование, - только новый заказ ( опять же имхо) ... |
|||
:
Нравится:
Не нравится:
|
|||
27.07.2013, 12:07 |
|
Проверка наличия записи
|
|||
---|---|---|---|
#18+
Где-то в степиМСУ, тут можно и обойти центральное хранилище, портфель заказов держать локально ( локальное хранилище) Зачем? Это отдельная специфичная задача с embedded database с последующей синхронизацией с сервером приложений . Где-то в степиа при "Заказать" производить перелив в центральное, в любом случае после этой манипуляции, что то сделать с заказом Не надо так делать. Переливать только в апп сервер, а там он сам разберется, куда и кому нужно отлить. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.07.2013, 12:30 |
|
Проверка наличия записи
|
|||
---|---|---|---|
#18+
МСУ, Ё моё ну какой ты дотошный, ну пусть будет так: Смысл моего высказывания, держать портфель заказов локально, а по кнопке заказать отправлять его на формирование. зы Санитары и мой лечащий врач с этим согласны... ... |
|||
:
Нравится:
Не нравится:
|
|||
27.07.2013, 12:44 |
|
Проверка наличия записи
|
|||
---|---|---|---|
#18+
Где-то в степидержать портфель заказов локально Ну пусть портфель заказов сразу на лету в онлайне считается (как на экзисте в корзину набираешь запчасти). Я ж говорю, какая принципиальная разница? ... |
|||
:
Нравится:
Не нравится:
|
|||
27.07.2013, 13:40 |
|
Проверка наличия записи
|
|||
---|---|---|---|
#18+
МСУ, да как бы есть разница веб и десктоп, если рассматривать формирование заказа как атомарную операцию, не стоит хранить промежуточные данные на главном хранилище, они вообще там не нужны as заказы не получившие статус законченные,( если не формировать корзину желаний) локально формировать заказ( корзину) и все, никаких обращений к серверу за сменой количества или отказа от деталей аки отказа от начатого заказа, опять же, при определенных условиях, мы можем работать в офлайне, а на сервере иметь таблицу фактических заказов, по которой идет формирование на выдачу.. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.07.2013, 14:08 |
|
Проверка наличия записи
|
|||
---|---|---|---|
#18+
guest786нажимает на кнопку и запись добавляется во временную таблицу почему во временную? ... |
|||
:
Нравится:
Не нравится:
|
|||
27.07.2013, 14:12 |
|
Проверка наличия записи
|
|||
---|---|---|---|
#18+
Где-то в степи, вообщем, два различных способа: онлайн и оффлайн. Но принципиально ничего не меняется. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.07.2013, 15:19 |
|
Проверка наличия записи
|
|||
---|---|---|---|
#18+
[quot Где-то в степида как бы есть разница веб и десктоп[/quot] Принципиально никакой разницы. В качестве embedded database на клиенте веб приложения можно рассматривать кукисы. Чем тебе не локальная БД? Где-то в степипромежуточные данные на главном хранилище, они вообще там не нужны as заказы не получившие статус законченные,( если не формировать корзину желаний) Ну про не нужны я бы не был столь категоричным. Любые данные нужны. 1. Статистика отказов 2. Пользователь может продолжить добивать заказы с другого компьютера ... |
|||
:
Нравится:
Не нравится:
|
|||
27.07.2013, 15:23 |
|
Проверка наличия записи
|
|||
---|---|---|---|
#18+
МСУ1. Ты "сервер приложений" клиентом называешь? Прости, но если сервер приложений так просто "отрубается от питания", то мне остается только плакать. Срочно читать про балансировщик нагрузки и кластеризацию. 2. Если же ты про двухзвенку, то я даже разговаривать на эту тему не хочу. Таким решениям место на свалке. Клиент ничего не должен знать про БД, никаких транзакций с клиента. Разумеется я работаю только с двузвенками. Трехзвенкам место на свалке истории, когда слабость клиентов компенсировалась промежуточным звеном. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.07.2013, 16:28 |
|
Проверка наличия записи
|
|||
---|---|---|---|
#18+
mmnickВнимательно читайте вопрос, пользователь открывает заказ на редактирование причем тут БД и хранимки Заказ в вакууме хранится? ... |
|||
:
Нравится:
Не нравится:
|
|||
27.07.2013, 16:31 |
|
Проверка наличия записи
|
|||
---|---|---|---|
#18+
Изопропилguest786нажимает на кнопку и запись добавляется во временную таблицу почему во временную? +1 В постоянную. Тогда проще задействовать всю мощь базы. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.07.2013, 16:33 |
|
Проверка наличия записи
|
|||
---|---|---|---|
#18+
Cat2МСУ1. Ты "сервер приложений" клиентом называешь? Прости, но если сервер приложений так просто "отрубается от питания", то мне остается только плакать. Срочно читать про балансировщик нагрузки и кластеризацию. 2. Если же ты про двухзвенку, то я даже разговаривать на эту тему не хочу. Таким решениям место на свалке. Клиент ничего не должен знать про БД, никаких транзакций с клиента. Разумеется я работаю только с двузвенками. Трехзвенкам место на свалке истории, когда слабость клиентов компенсировалась промежуточным звеном. Немного не понял про слабость клиентов. Ты о чем? ... |
|||
:
Нравится:
Не нравится:
|
|||
27.07.2013, 22:47 |
|
|
start [/forum/topic.php?fid=20&msg=38346091&tid=1404290]: |
0ms |
get settings: |
9ms |
get forum list: |
15ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
183ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
57ms |
get tp. blocked users: |
1ms |
others: | 15ms |
total: | 303ms |
0 / 0 |