Цитата(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 значений, спецсиволов в значениях строк, пустых списков и прочей белиберды).

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