А в поле чудес часто промахивался с цифрой на барабане :) Странно оно крутилось: иногда резко замедлялось и останавливалось, а иногда после быстрого замедления долго крутилось
Первая и большая часть совершенно излишняя да и аналогии какие-то совершенно неприменимые.
Допустим, что блокировок совсем нет: каким образом тогда данные будут одновременно обновляться? Для аналогии возьмите java(увидел в профиле) и синхронизацию. Не говоря уже о кешировании о котором у них заявляется.
А про стопку карточек это аналогия скорее сиквенсам и их параметру кэша.
В первом случае (который и предполагается использовать) всё просто — счётчик дважды увеличится
Да не так уж и просто… Параллельное изменение каким образом сделано? не приведут ли простые два селекта с incr к дедлоку или вообще к критической ошибке параллельного доступа? Лень пробовать этот Cubrid, но знать хочется :)
SELECT header, text, INCR(read_count) FROM articles WHERE article_id = :requested_id;
Имхо это не совсем красиво давать апдейты в селектах… Особенно наверное прелестно коммиты после селектов делать. И ведь rollback to savepoint не поможет для промежуточного отката.
Оракловый returning нравится гораздо больше:
update articles
set
read_count=read_count+1
where
article_id = :requested_id
returning
header, test, read_count
into
v_header,v_text,v_read_count
Так что — нет, для меня появление лишних столбцов в коде не неожиданно, потому как поведение кода не изменится.
Про клопов по ссылке не прочитали значит? Допустим, в коде вам нужно 5 полей, а в таблице их 10-20-30, да еще и row-chaining… Поведение кода-то не изменится, но замедление будет фантастическим, кэш забьется ненужным мусором, да еще и таскать между базой и клиентом лишние мега/гигабайты ненужных данных…
В таблице возможно, что необходимо искать по всем полям — для всех полей создавать индексы? Это тема вообще слишком большая, чтобы хоть что-нибудь категорично утверждать. Не говоря уже о том, что не так уж редко что фулскан быстрее беготни по индексам.
Изменение плана — достаточно непредсказуемо? Или исчезновение строк при использовании VPD и появлении в таблицы колонки, где прав не хватает? И еще куча примеров, которые там обозначены.
А еще… каждый индекс будет замедлять изменения значений и советовать создание индексов на все поисковые поля — это чересчур категорично. Особенно битмапы.
И это тоже, конечно, но это не такая проблема — можно на серверах разворачивать тяжелое, мне важнее, что это неудобно — я привык к двум мониторам и хочется даже уже третий, полноразмерной удобной клавиатуре и тд…
Допустим, что блокировок совсем нет: каким образом тогда данные будут одновременно обновляться? Для аналогии возьмите java(увидел в профиле) и синхронизацию. Не говоря уже о кешировании о котором у них заявляется.
А про стопку карточек это аналогия скорее сиквенсам и их параметру кэша.
Тоже напоминает оракл :)
Имхо это не совсем красиво давать апдейты в селектах… Особенно наверное прелестно коммиты после селектов делать. И ведь rollback to savepoint не поможет для промежуточного отката.
Оракловый returning нравится гораздо больше:
Или функции с автономными транзакциями.
Про клопов по ссылке не прочитали значит? Допустим, в коде вам нужно 5 полей, а в таблице их 10-20-30, да еще и row-chaining… Поведение кода-то не изменится, но замедление будет фантастическим, кэш забьется ненужным мусором, да еще и таскать между базой и клиентом лишние мега/гигабайты ненужных данных…
Появление лишних столбцов в запросе тоже?
То есть в mysql надо писать как попало? Странно…
VPD — citforum.ru/database/oracle/vpd/
А я плачу налоги куда дольше…