Колонка переключателя или удаление данных

[Royal Flash]

Здравствуйте.

Возникла дилема: создавать отдельную колонку в БД MySQL с флагом на обновление кеша (колонка ENUM 0, 1), или просто удалить кеш (колонка LONGTEXT). Если текст удален empty($row['text_cache']) или установлен флаг кеша ($row['cache_flag'] == 1) - запускается процесс кеширования. Вопрос заключается в том, что: на сколько медленнее будет длиться процесс удаления, например 1000 записей из БД колонки LONGTEXT (UPDATE table SET text_cache = ""), чем смена тех же 1000 значений флага 0 на 1 колонки ENUM (UPDATE table SET cache_flag = "1")? По возможности не хочется создавать дополнительные колонки в таблице MySQL, если есть возможность обойтись без этого.

 

[tz-lom]

ну вообщем то т.к. text_cache это не удаление а запись значения,то пишется LONGTEXT медленнее чем ENUM , НО:
1- зачем для кешей использовать MySQL , если есть другие решения?
2- если уж кеш в MySQL , то почему бы просто не удалять устаревшие кеши ? зачем флаг?

 

[Royal Flash]

Флаг - на обновление кеша. Если установлен в 1 - значит заново кешировать.
А какие другие решения, можно подробнее? Кешируется новость, так как используются BB коды и др, так что "на лету" преобразовывать - ресурсоемко. Все данные по ней хранятся в БД в 2-ух экземплярах: оригинал (для редактирования) и кеш (для просмотра). После обновления информации админом, 1 или более новости необходимо кешировать заново. Чтобы не делать это из под админа (запись кеша для 1000 новостей может занять несколько минут) - кешируется только тогда, когда нужно, т.е. тогда, когда новость просматривается. Вот и нужно как-то указать, что нужно кешировать.

 

[fixxxer]

create table article (
 article_id PK,
 content text,
 updated_ts timestamp default current_timestamp on update current_timestamp
)

create table article_cache (
 article_id FK,
 content_parsed text,
 updated_ts timestamp default current_timestamp on update current_timestamp
)

select article.article_id, article.content, article_cache.content_parsed
from article
left join article_cache 
   on (article_cache.article_id=article.article_id and article_cache.updated_ts >= article.updated_ts)
where article.article_id = $article_id

if (!$content_parsed) {
      parse;
      update cache;
}

 

[Royal Flash]

Спсибо за вариант, но только получается, что в этом случае будут нужны аж 2 доп. колонки MySQL updated_ts. По идее, не важно знать, когда был сгенерирован последний кеш или обновлен источник? Нужно только обновить кеш, в случае изменения источника. Т.е. если обновился источник, это можно указать способами, которые я указал выше. Зачем Вы предлагаете хранить кеш в отдельной таблице и что такое PK и FK у article_id?

 

[tz-lom]

если убрать время то придётся в ручную следить за устареванием кеша,а так - обновились данные и условие по времени уже не проходит
PK - primary key
FK - foreign key

 

[Royal Flash]

C innoDB не работаю, использую MYISAM, но за расшифровку foreign key - спасибо. По поводу устаревания кеша - это может произойти только в случае редактирования новости, и ни в каком другом, так что буду пробовать, наверное, с удаленим данных колонки LongText, если никто не разубедит

 

[Royal Flash]

Не поленился, и протестировал, что быстрее - удаление текстовых данных или смена enum c 0 на 1.
БД: 1,1 ГБ
150000 строк.
Действия Update над 5000 строк: удаление (Update SET text = "") в среднем 0,2 сек., смена переключателя ENUM (Update SET enum = "1") в среднем 0,3 сек.
Пробовал в других вариациях - всеравно всегда незначительно, но быстрее SET text = "".
Может эти данные кому-нибуть пригодятся.

 

[tz-lom]

Royal Flash
угу,а теперь потесть DELETE и ощути разницу )

 

[Mols]

Royal Flash
нифига не понял... а админ он что, за один раз чтоли 1000 записей редактирует?
Почему нельзя в момент сохранения изменений сразу всё привести в актуальное состояние?

 

[iceman]

это же горе-оптимизатор