rPman

Поиграйся так, не идеальное решение но иногда спасает:

SET <hh user=rank>=0;
SELECT <hh user=rank>:=<hh user=rank>+1 AS rank, id FROM menu;

Если я не ошибаюсь, практически любые DDL операции с myisam у mysql — это почти полное копирование, т.е. создается временная таблица, туда переливаются данные, после этого удаляются старые и переименовываются созданные.
Значит проблем не должно быть.

p.s. бакап/восстановление myisam таблиц возможен просто в виде файлов самих таблиц (скопируй всю папку /var/lib/mysql/база_данных )

Меняется ли sum(field2) для каждого field и как часто? Критично ли скорость его записи?
Если быть более точным, изменяется ли поле field2? или только добавляются и удаляются новые записи?

Я к тому что такие задачи решаются гораздо проще просто доп-таблицей (field, sum_cache) и обновлением на основе триггеров или самостоятельно… кстати на сколько я знаю есть БД поддерживающие кеш-индексы на основе выражений (фактически они и создают поле и наполняют его триггерами)

Иногда бывает эффективнее заранее пронумеровать записи пользователей в отдельном поле (однократно старые данные и затем при добавлении и удалении записей заново перенумеровывать), тогда запрос станет очень простым:

select * from статьи t where t.номер<=:limit

Какие сложные запросы и почти наверняка засовываются в главные страницы (т.е. будут всегда запрашиваться), неужели сложно добавить поле boolean need_translate, и на время, отсутствия перевода, вставить английский во все языки.

p.s. лучше делать так: таблица towns {id, ru,en,fr,...} т.е. по полю на язык, соответственно запросы будут проще и шустрее.

фиктивные таблицы:
select 1 from dual union
select 2 from dual union
…

комбинируя разные такие таблицы, можно много что наворотить… только остается вопрос эффективности, но вдруг это решение будет эффективнее создания специальной таблицы.

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

Это какой то тихий ужас… когда то писал на .net базы, с mysql работа на запись была на уровне 200 запросов в секунду, и не просто табличку а с индексами и т.п. при этом комп древний и слабый был.

Уверены что не нужно ничего дополнительно тюнить при использовании ключевого слова base(...)?

Хранить в базе смещение (можно поделить на размер сектора или больше 4096...) и размер файла, при должном красноглазии можно завернуть оба числа в 64bit long и пользоваться им как идентификатор файла, сами файлы хранить в одном большом контейнере (можно не сильно заморачиваться с файловыми системами и складывать прямо в /dev/sda), как результат — максимально быстрый доступ к файлам (быстрее — только при самостоятельной организации кеширования под задачу) и максимально неудобное обслуживание при частых удалениях/изменениях файлов (запись только в конец контейнера, по окончании места — полная реорганизация хранилища, с выдачей новых id… но это может оказаться приемлемой платой и в некоторых задачах ее даже не придется платить).

p.s. посчитали это шуткой? просто все зависит от задачи и особенностей использования данных.
Вышеописанный способ использовался достаточно давно для не web-проекта, обеспечивал 'максимальную из возможных' производительность при резервном копировании, чтении и добавлении новых файлов, позволял организовать версионность 'из каропки',…

Ответы очевидны.
Помечать флагом — растет база, удалять — понижение производительности (фрагментация, сама операция удаления может оказаться дорогой) и часто усложнение бизнеслогики.

Я бы не рекомендовал удалять данные из сложных баз данных, особенно если это справочники, например выставив в freign key — RESTRICT, чтобы разрешить удаление только для 'свободных' записей. Удаление записей в сложных базах данных, обычно очень сложная операция, обычно перед этим приходится проводить кучу проверок и изменений для связанных данных, поэтому флаг 'deleted' используется как упрощение или даже часть механизма для введения временной составляющей в хранение данных (база данных может являться как средством для хранения текущего состояния, так и для хранения лога изменений данных во времени)

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

Описанное вами — это развитие реляционной модели в сетевую… в mysql как я знаю средств для этого нет, в postgresql есть поддержка массивов, только производительность не ля всех случаев оптимальна.

Ваша задача лучше всего решается все таки сериализацией. Проблема обновления данных при расширении функционала не на столько критична чтобы только на основании этого отказываться от сериализации.

Так же не стоит закрывать глаза штатную реализацию списков второй таблицей M-1.

И конечно же никто не мешает совместить оба подхода (хранить данные в 2 таблицах и кешировать дополнительными полями в главной, например информация о количестве элементов в списке, значение первого элемента,..)