Ситуация:

есть таблица с двумя десятками записей. В ней два столбца: строка и число (0 или 1).
На ее основе формируется страница с двумя десятками флажков. Пользователь вносит изменения, нажимает submit. Но ведь отправляться будут только отмеченные элементы.

Вопрос: как лучше вносить изменения в базу? Вижу два варианта обработки запроса:
1. Записать 0 во все строки, потом перезаписать отмеченные на 1.
2. С помощью JS или hidden-полей передавать имена неотмеченных флажков в запросе.

Это сообщение отредактировал(а) Lamer George - 31.5.2005, 15:17

Цитата(Lamer @ 31.5.2005, 15:05)

есть таблица с двумя десятками записей. В неесть страница с двумя десятками флажков

и наверное неотмеченные чекбоксы не приезжают в посте ?

а если сперва записать все отмеченные с 1
а потом все оставшиеся с 0

Это сообщение отредактировал(а) maximb - 31.5.2005, 15:14

Это у меня комп колбасит, в три захода писал. Но ты и так ситуацию понял верно

Вопрос, собсно, в том, как лучше?

А что если в сессию положить число, если твоя табличка состоит только лишь из 20 строк, то 32 бита должно хватить вполне. Битовая маска этого числа будет являтся отображением твоих 0/1 в базе.

Цитата(Dancer @ 31.5.2005, 16:31)

А что если в сессию положить число, если твоя табличка состоит только лишь из 20 строк, то 32 бита должно хватить вполне. Битовая маска этого числа будет являтся отображением твоих 0/1 в базе.

Но ведь положить-то его можно только при серверной обработке. Юзер из своей странички сделать этого не сможет.

Цитата(Lamer @ 31.5.2005, 15:05)

1. Записать 0 во все строки, потом перезаписать отмеченные на 1.

я бы так сделал + смотрел на "<" и ">" с приходящих значений // секьюрити.

зачем ещё ява скрипт городить

Цитата(polosatij @ 31.5.2005, 17:02)

смотрел на "<" и ">" с приходящих значений

Не понял. Что ты имеешь в виду?

1. перед тем как сформировать страничку кладешь в сессию все данные по которым формируются чекбоксы
2. генеришь пользователю страничку с чекбоксами
3. пользователь отмечает интересующие его чекбоксы
4. пользователь жмет сабмит
5. все отмеченные чек боксы приезжают на сервер
6. пишешь в базу все данны которые соответствуют отмеченным чекбоксам с "1"
7. те данные для которых не было найдено соответствующего чекбокса в реквесте пишешь в ДБ с "0"

Похоже, равноценные варианты получаются (с точки зрения количества обращений к базе). Наверное, все же возьму

Цитата

Записать 0 во все строки, потом перезаписать отмеченные на 1.

Вроде как покороче будет.

Ну если "0" во все строки будет вставляться в одном запросе к ДБ тогда это лучше,
но если все выполняется отдельными, небольшими запросами тогда надо еще подумать
какой вариант более подходит

Буду делать одним запросом с кучей "OR".

Цитата(Lamer @ 31.5.2005, 16:23)

Буду делать одним запросом с кучей "OR".

тогда да

Наверняка можно подменить OutputStream к-ым пользуется драйвер для обращение к БД на BufferedOutputStream, посмотрел бы сам да времени сейчас в обрез, в этом случае думаю что все INSERT запросы отослались бы за одно образение к БД.

Да я и так все делаю в один UPDATE, так что не стоит заморачиваться.

Цитата(Lamer @ 31.5.2005, 16:23)

Буду делать одним запросом с кучей "OR".

Пара замечанией: если будешь делать одним запросом, можно вместо OR воспользоваться констркуцией where <column-name> in (value1, value2, ... , valueN). Никакой особой разницы, просто код чуть проще.

Но не будет особой беды и вызвать 20 апдейтов, если сделать через PreparedStatement - вопрос миллисекунд. Зато код будет чище. Просто динамическая генерация SQL - это такое средство, к которому лучше прибегать в самом последнем случае.

ЗЫ. А у тебя где обработка сабмита происходит? В сервлете?

Цитата(Stampede @ 31.5.2005, 19:38)

если будешь делать одним запросом, можно вместо OR воспользоваться констркуцией where <column-name> in (value1, value2, ... , valueN).

Угу, воспользуюсь.

Цитата(Stampede @ 31.5.2005, 19:38)

Но не будет особой беды и вызвать 20 апдейтов, если сделать через PreparedStatement - вопрос миллисекунд.

Думаю, нет смысла - не часто будет использоваться.

Цитата(Stampede @ 31.5.2005, 19:38)

А у тебя где обработка сабмита происходит? В сервлете?

В кастом теге.

Цитата(Lamer @ 31.5.2005, 18:40)

Цитата (Stampede @ 31.5.2005, 19:38) Но не будет особой беды и вызвать 20 апдейтов, если сделать через PreparedStatement - вопрос миллисекунд. Думаю, нет смысла - не часто будет использоваться.

Если не часто будет использоваться, тогда разница в миллисекунды вообще никакого рояля не играет. А что касается PreparedStatement, то его смысл в данном случае не в том, чтобы сохранять откомпиленный запрос между вызовами страницы (поскольку он в кэше ДБ сервера до следующего вызова, вероятно, просто не доживет), а в том, чтобы:

а) сохранять его между отдельными апдейтами в процессе обработки одной страницы, и

б) избежать генерации SQL кода.

То есть если ты напишешь примерно такую функцию, то она будет мослать очень быстро:

Код

private static final String updFlag = "UPDATE FLAGS SET FLAG_ON=1 WHERE FLAG_NAME=?"; private void updateFlag(String flagName, Connection con) throws SQLException {   PreparedStatement pstm = con.prepareStatement(updFlag);   pstm.setString(1, flagName);   pstm.executeUpdate();   pstm.close(); }

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

Цитата(Stampede @ 31.5.2005, 18:38)

Просто динамическая генерация SQL - это такое средство, к которому лучше прибегать в самом последнем случае.

Цитата(Stampede @ 31.5.2005, 19:01)

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

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

Самое неприятное, что такой случай может наступить когда угодно: сегодня, завтра, через месяц, через год... короче, никогда не знаешь, где рванет

Я не говорю, что SQL совсем не надо генерировать - иногда, действительно, это бывает более простым, а подчас и единственно возможным решением. Но каждый раз, когда это делаешь, нужно относиться к этому как к мине замедленного действия и _очень_ внимательно анализировать (и тестировать) на предмет специальных ситуаций (null значений, спецсиволов в значениях строк, пустых списков и прочей белиберды).

А еще лучше - по возможности вообще не связываться, целее будешь