ReSQL.ru
     
powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Java [игнор отключен] [закрыт для гостей] / Проверка ставки на аукционе. В DAO или в базе?
6 сообщений из 6, страница 1 из 1
Проверка ставки на аукционе. В DAO или в базе?
    #38731538
Recreate
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Recreate
Гость
Доброго времени суток! Как лучше всего организовать добавление ставки на лот? Нужно проверить время, правильность ставки и т.д. Где лучше это делать? При инсерте в базу(триггер)? Или же в DAO сделать запрос, получить предыдущую ставку, сравнить с текущей и т.д. и потом инсерт? Мне лично кажется что в базе будет быстрее. Если ставка провалилась, то кидать эксепшн из базы, а в Java его обрабатывать. Какой вариант вообще имеет смысл?
...
Рейтинг: 0 / 0
28.08.2014, 13:21
| Ответить | Цитировать | Написать  
Проверка ставки на аукционе. В DAO или в базе?
    #38731559
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Petro123
Участник
Recreate,
быстрее на 0,000001 сек?
Как умеешь, так и пиши.
...
Рейтинг: 0 / 0
28.08.2014, 13:37
| Ответить | Цитировать | Написать  
Проверка ставки на аукционе. В DAO или в базе?
    #38731575
Фотография Blazkowicz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Blazkowicz
Участник
Recreate,

В базе будет быстрее до тех пор, пока решение не нужно масштабировать на разные сервера. В DAO бизнес-логике точно не место. Для реализации бизнес-логики используется отдельный слой.

На самом деле, достаточно просто для всех текущих аукционов держать очереди в памяти и разруливать их именно на Java. И лишь переодически персистить её снимки. Тогда можно избежать кучи SQL запросов. В highload системах, очень много оперативных данных живет в оперативной памяти. Соврешенно не обязательно на каждый пук юзера, останавливать весь процесс и ждать пока текущий шаг сохранится в базу.
...
Рейтинг: 0 / 0
28.08.2014, 13:42
| Ответить | Цитировать | Написать  
Проверка ставки на аукционе. В DAO или в базе?
    #38731678
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
RecreateГде лучше это делать? При инсерте в базу(триггер)?
На самом деле без доп. требований невозможно сформулировать основание лучшего или
худшего решения. Сколько звеньев в системе? Где что лежит? Как взаимодействует?
Где таймауты? Как быстро фиксация должна лечь в хранилище и многое прочее.

Тут в ПТ один чел говорил что триггеры в БД - это зло и их логику надо срочно переносить в Java.
Другой маргинал кодил свою собственную IMDB с "нулевым" отклкиком e.t.c. ИЧСХ даже тесты
приводил.
...
Рейтинг: 0 / 0
28.08.2014, 14:45
| Ответить | Цитировать | Написать  
Проверка ставки на аукционе. В DAO или в базе?
    #38746060
Йуный джавистЪ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Йуный джавистЪ
Участник
авторНа самом деле, достаточно просто для всех текущих аукционов держать очереди в памяти и разруливать их именно на Java. И лишь переодически персистить её снимки. Тогда можно избежать кучи SQL запросов. В highload системах, очень много оперативных данных живет в оперативной памяти.

Если так делать, то после первого же бага в логике, приводящего к банальному NPE, данные окажутся в неконсистентном состоянии и уже не будет никакой возможности их восстановить. В случае использования СУБД, исключение будет отловлено и транзакция будет отменена.
Вообще, в general purpose языке трудно реализовать Software Transactional Memory. В clojure например реализовали, но там код выглядит так:
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
(defn run [nvecs nitems nthreads niters]
  (let [vec-refs (vec (map (comp ref vec)
                           (partition nitems (range (* nvecs nitems)))))
        swap #(let [v1 (rand-int nvecs)
                    v2 (rand-int nvecs)
                    i1 (rand-int nitems)
                    i2 (rand-int nitems)]
                (dosync
                 (let [temp (nth @(vec-refs v1) i1)]
                   (alter (vec-refs v1) assoc i1 (nth @(vec-refs v2) i2))
                   (alter (vec-refs v2) assoc i2 temp))))
        report #(do
                 (prn (map deref vec-refs))
                 (println "Distinct:"
                          (count (distinct (apply concat (map deref vec-refs))))))]
    (report)
    (dorun (apply pcalls (repeat nthreads #(dotimes [_ niters] (swap)))))
    (report)))


Мне кажется, что PL/SQL проще.
авторСоврешенно не обязательно на каждый пук юзера, останавливать весь процесс и ждать пока текущий шаг сохранится в базу.
Если требуется durability, то в любом случае надо ждать запись на диск. Если durability не требуется, то можно использовать асинхронный коммит. В оракле можно вообще указывать на уровне отдельной транзакции, комитить ее синхронно или асинхронно.
...
Рейтинг: 0 / 0
13.09.2014, 19:34
| Ответить | Цитировать | Написать  
Проверка ставки на аукционе. В DAO или в базе?
    #38746114
scf
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
scf
Участник
В коде. Почему:
- проще написать, поддерживать и отлаживать
- будет хорошо работать при любой приличной нагрузке
- когда нагрузка станет неприличной, база тебя не спасет - нужно будет делать in-memory решение с хитрым персистом в базу (гугли LMAX architecture)
...
Рейтинг: 0 / 0
13.09.2014, 21:53
| Ответить | Цитировать | Написать  
6 сообщений из 6, страница 1 из 1
Форумы / Java [игнор отключен] [закрыт для гостей] / Проверка ставки на аукционе. В DAO или в базе?
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение   Полит. конфиден.  
NoSQL.ru       Кролег: Проекты, Новости, Чат       РЕД ФОРУМ       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=59&msg=38746060&tid=2126602]:
 0ms
get settings:
 10ms
get forum list:
 18ms
check forum access:
 3ms
check topic access:
 3ms
track hit:
 163ms
get topic data:
 10ms
get forum data:
 2ms
get page messages:
 55ms
get tp. blocked users:
 1ms
others: 244ms
total:  509ms
созд. / загр.: 509ms
x
x
Закрыть


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