rPman

фиктивные таблицы:
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 таблицах и кешировать дополнительными полями в главной, например информация о количестве элементов в списке, значение первого элемента,..)