Реляционные СУБД и TrackStudio

> только в ORACLE есть start with/connect by, работающий к тому же очень медленно

Насчёт медленно -- ели уху.
Насчёт остальных -- делается криво, ибо это нарушение реляционной модели. Что, если будет цикл? Но делается: для MS SQL пишите SP, которая вставляет во временную таблицу.

Если считаете, что очень умны и можете осчастливить мир -- качайте сорцы MySQL и пишите иерархические запросы. Подозреваю, что не сможете сделать лучше Оракла. Причины тут философские.

> большинстве РСУБД крайне примитивная security, ... Например, нельзя ограничивать доступ пользователей к данным на уровне отдельного поля

Брехня. Все нормальные поддерживают, ибо стандарт.

> или отдельной строки таблицы

Это расширение SQL стандарта. Есть Secure Oracle, он даже сертифицирован. Там это есть.

> невозможность нормально хранить длинные строки в ORACLE

БЛОБы никто не отменял. Вероятно, хотите сказать не "хранить", а "искать" -- ну так, есть мощные отдельные поисковые сервера.

Вообще Макс зря распинался и навлек на себя гнев общественности. Достаточно было сказать, что ДЛЯ НАШИХ задач реляционная СУБД, по сути, вообще не нужна. А используется она как НОК всех остальных способов хранения.

>> только в ORACLE есть start with/connect by, работающий к тому же очень медленно

> Насчёт медленно -- ели уху.
> Насчёт остальных -- делается криво, ибо это нарушение реляционной модели. Что, если будет цикл? Но
> делается: для MS SQL пишите SP, которая вставляет во временную таблицу.
> Если считаете, что очень умны и можете осчастливить мир -- качайте сорцы MySQL и пишите иерархические
> запросы. Подозреваю, что не сможете сделать лучше Оракла. Причины тут философские.

Все равно это очень тормозно, проверяли. Первые версии TrackStudio как раз использовали ORACLE 8i и start with/connect by. С более простой security, чем сейчас, вывод 5-10 задач при 2000 задач в базе занимал порядка 2-3 минут на P3-750. Нынешние версии не требуют ORACLE и работают куда быстрее даже на миллионе задач :-)

MySQL тут не поможет, проблема не в особенностях конкретной СУБД.

>> большинстве РСУБД крайне примитивная security, ... Например, нельзя ограничивать доступ
>> пользователей к данным на уровне отдельного поля

> Брехня. Все нормальные поддерживают, ибо стандарт.

Имеется в виду создание view вытягивающего только разрешенные поля и последующая работа через этот view ?

>> или отдельной строки таблицы
> Это расширение SQL стандарта. Есть Secure Oracle, он даже сертифицирован. Там это есть.

А где можно подробности почитать о возможностях. Google о "secure oracle" находит не слишком много.

>> невозможность нормально хранить длинные строки в ORACLE
> БЛОБы никто не отменял. Вероятно, хотите сказать не "хранить", а "искать" -- ну так, есть
> мощные отдельные поисковые сервера.

Не, именно хранение. BLOB-ы в ORACLE весьма кривые, вот что народ из Atlassian пишет
http://www.atlassian.com/software/jira/docs/v3.6.5/databases/oracle.html
Мой опыт работы с этим был примерно аналогичным, поэтому мы с BLOB-ами решили изначально не связываться.

> 5-10 задач при 2000 задач в базе занимал порядка 2-3 минут на P3-750.

Дело, боюсь, не в самом Оракле.

> Имеется в виду создание view вытягивающего только разрешенные поля и последующая работа через этот view ?

Какая-то кривая постановка задачи. Решений несколько способов, зависит от тонкостей того, как именно Вас понимать. Я пока не могу.

> Google о "secure oracle" находит не слишком много.

Вспомнил: trusted oracle

> BLOB-ы в ORACLE весьма кривые, вот что народ из Atlassian пишет

БЛОБ не нашёл. Нашёл CLOB, это нечто другое. Разницу видите?

Если у конкретной фирмы есть проблемы сочетать конкретный драйвер с конкретной версией клиента -- то при чём тут архитектура.

Мы сажали Коммунивер на Постгресс и Оракл, наелись реляционности по самое не балуйся. Поэтому полностью подтвержу: вся эта реляционность выходит боком, ежели природа данных не таблична.

P.S.
Я, кстати, не исчез. Просто уже несколько дней физически не нахожусь около компьютера в приемлемое для разговоров время. Конец года, нарастающее сумасшествие вокруг, толстые деды Лайны совсем затолкали. Я попробую завтра утром связаться.

Хорошо, жду :)

Я решил более подробно описать проблему с тормозами в реляционных базах при обработке security/иерархий. Для примера рассмотрим такую задачу: нужно вывести список всех "моих" задач в доступных мне подпроектах продукта X. В системе типа bugzilla это решается одним простым SQL запросом.

Но в TrackStudio есть иерархия задач, плюс можно указывать security для проектов, конкретных задач, категорий задач, кастом-полей. Посмотрим, к каким дополнительным действиям это приведет:

1) Сначала нужно понять, какие задачи вообще относятся к продукту X. Для этого нужно взять продукт X, получить список его подзадач, для каждой из них - опять список подзадач и т.п. Если у нас 2000 задач - нужно выполнить 2000 запросов только чтоб убедится что у этих задач нет подзадач. Тут можно сократить количество запросов за счет использования "in (список номеров задач)", но тогда мы не сможем построить дерево, которое нам пригодится потом. Оракловый START WITH/CONNECT BY будет полезен именно на этом этапе, т.к. позволяет собрать все дочерние элементы одним запросом. Есть варианты другой организацией дерева (например, parent task хранит диапазон ID дочерних элементов), но тут возникают проблемы с модификацией дерева задач.

2) Теперь нужно получить какие задачи видит данный пользователь и его список ролей (групп) для каждой задачи. В TrackStudio пользователь может быть менеджером в проекте A и одновременно быть разработчиком+тестировщиком для одной конкретной задачи в проекте B.
Причем права наследуются: если мы сказали что Вася будет менеджером в проекте A, нам не нужно это повторять для каждой задачи проекта, хотя для любой из них мы можем сказать - "а вот для этой задачи Вася будет еще и тестировщиком".

Т.е. теперь мы должны для каждой задачи получить цепочку ее parent task-ов, проверить какие для них заданы роли, как и где они были переопределены и в итоге мы получим список ролей пользователя для каждой из этих 2000 задач. Если мы не храним конфигурацию дерева в памяти - нам нужно получить цепочки parent task-ов 2000 раз и куда-то сохранить результаты его обработки.

Дело осложняется правилами для групп типа: "все разработчики имеют доступ к этому подпроекту" или "для этого проекта все разработчики отдела X являются тестировщиками", они влияют на список ролей для задач самым прямым образом.

3) Теперь нужно проверить правила видимости для категорий. Т.е. может быть указано, что "клиент видит только багрепорты, которые он внес сам и только в проекте customer support." Опять проверяем все задачи, достаем их категории, достаем список ролей для каждой задачи, проверяем может ли этот пользователь видеть эту конкретную задачу. Если не может - значит и все подчиненные задачи ему не доступны и их из списка выкидываем.

4) Какие задачи можно выводить - разобрались, теперь разбираемся с полями. Для каждой задачи на основе списка ролей получаем список всех полей, которые может видеть пользователь. Т.е. легко может оказаться, что в полученном списке задач пользователь может видеть бюджет у "своих" багов, а вот у проектов - не может вообще никак. Или что клиент не может видеть затрат времени разработчиков на задачу.

Главная сложность тут в том, что если права на задачу мы проверяли один раз для задачи, то тут нужно проверять для каждого _поля_ каждой задачи: они легко могут быть разными у полностью одинаковых задач, но находящихся в разных состояниях.
Даже если проверка выводить/не выводить данное поле делается 1 запросом и у нас в фильтре 10 полей - получаем 2000*10 = 20000 запросов.

5) Только теперь можно отфильтровать из этих 2000 задач "мои". "Скрывать" информацию нужно было именно до фильтрации, иначе умные клиенты смогут довольно быстро угадать значение скрытого поля выдавая набор запросов типа "вывести задачи где затраты на разработку больше 1 часа", "а теперь больше 2", etc. Если в первом запросе задача вывелась, а во втором исчезла - значит затраты времени на нее от 1 до 2 часов.
Дело тут осложняется пользовательскими полями (значения которых хранятся в отдельных таблицах со сложными связями) и вычисляемыми полями, для которых значение считается скриптом при обращении. Причем при выполнении скрипта действуют те же самые правила: если поле не видно - его не видно и из скрипта.

Макс, ну фильтрацию по вычисляемым полям все равно на уровне СУБД не сделаешь, так что зря ты столько расписывал :)

6) Теперь проверяем данные. Например, если нужно вывести в качестве значения поля ссылку на задачу, а прав доступа к той задачи нет - выводим просто ее номер, иначе - полный путь. Т.е. для каждого _значения_ нам опять нужно повторять пункты 1-3, заранее собрать эту инфу невозможно.

В итоге получаем, что для не самого сложного случая вывода 1 страницы со списком багов нам придется получать список parent-ов/children-ов обрабатываемых задач десятки тысяч раз. В реальных условиях метод получения children-ов/parent-ов может вызываться сотни тысяч и даже миллионы раз для обработки одной страницы.

Решение - держать в памяти конфигурацию дерева, права и группы пользователей на все, значения полей от которых могут зависеть права (submitter/handler/state), и самим управлять этими данными. Но в этом случае состояние БД не полностью отражает состояние системы и все синхронизации кешей, обработки rollback-ов, выставления блокировок, борьбу с deadlock-ами нам надо делать для внутренних структур ручками.

Как только мы пошли по этому пути - про поддержку СУБД атомарности, уровней изоляции транзакций, работы в кластере и прочее можно забыть: если сами сделаем репликацию блокировок внутренних структур между узлами кластера - хорошо, не сделаем - будет глючить под нагрузкой.

Думаю, не мы одни на эти грабли встали. Microsoft когда-то анонсировала что в Windows Vista будет WinFS, революционная файловая система на основе РСУБД, а в итоге
http://en.wikipedia.org/wiki/WinFS
"While it was then assumed by observers that WinFS was done as a project, in November 2006 Steve Ballmer announced that WinFS was still in development, though it was not clear how the technology was to be delivered."

Подозреваю, что иерархия папок + что-то вроде NTFS security очень плохо ложится на реляционную модель.

Много ковырялся с внутренностями MS Exchange/Active Directory - они почему-то тоже вместо реляционной СУБД (того же SQL Server) используют ESE, который очень быстрый, но совсем не SQL.

На предпоследнем JUG-е elizarov (http://elizarov.livejournal.com) рассказывал на примере обработки биржевых сигналов, что для массовой обработки сообщений JMS вообще не пригоден (жутко тормозной и решает не те проблемы), а ему никто почему-то не верил :-)

Ну, изначальный пост содержит довольно много неправды.

start with/connect by есть в postgresql, например, аналоги есть и для других РСУБД.
security по полю есть вообще много где.

Другой пост, более подробный, выглядит так, будто матчасть изучена неполно (не знаю, может это просто так выглядит, но писать про деревья и не упомянуть Селко, при этом упомянуть два других аглоритма - ну как это можно понять?) Плюс наверняка многое решается другой структурой данных (возможно, денормализованной). Вообще, я не понимаю, зачем BL складывать на РСУБД, когда проще сделать ORM (с lazy заполнением пропертей и с memoize), и всю BL делать на стороне приложения, тогда и кучи запросов не будет (по памяти просядем, конечно). Ну и если вы делаете BL на стороне РСУБД, то видимо логичнее использовать stored procedures, а не гонять туда-сюда запросы и результаты запросов. И не стоит недооценивать алгоритмы кеширования РСУБД, там чуваки очень мощные сидят, довольно сложно их переплюнуть.

Конечно, вам виднее, но ваши слова не выглядят убедительными, по крайней мере для меня.

А по сути наверное соглашусь.

> start with/connect by есть в postgresql, например, аналоги есть и для других РСУБД.

Ну, выбирать как с этим работать нам приходилось в где-то в 2001 году, тогда start with / connect by в postgresql был доступен только в виде патча. Мы с этим тогда поигрались, но учитывая опыт с ORACLE связываться с этим не хотелось, плюс не понятно что с другими базами СУБД делать.

> security по полю есть вообще много где.

Хочется примеров. Пока то что я видел - это не та security, т.е. формально что-то делается, но не то. Т.е. я не знаю как сделать на уровне SQL, чтоб попытки от имени работников запросить зарплату директора возвращали NULL, и при это нормально работали для других полей и записей. Или чтоб при вычислении AVG(SALARY) зарплата директора исключалась из рассмотрения. Причем это решение должно обеспечивать нормальное управлениями тысячами правил доступа без особенного мудрежа со стороны пользователя.

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

BL мы на РСУБД не складываем, бесперспективность этого стала понятна быстро. ORM с lazy-заполнением и хранением в памяти результатов запросов (query-level cache) в лице Hibernate используем где нужно уже несколько лет. Попытки отказаться от наших структур и использовать только кеши ORM (это позволило бы сильно упростить код) приводили к падению скорости на порядок и более.

В общем я не думаю, что мы сделали где-то большую глупость и задача легко решается средствами РСУБД. Я ведь этой тематикой давно интересуюсь: когда был студентом (эх, молодость:) - довольно серьезно интересовался реляционной теорией, внутренним устройством РСУБД, читал умные книжки (Мейер и пр.), переводы буржуйских статей в "открытых системах", трепался с Лилией Козленко из Линтера в фидонете и даже собирался туда устраиваться на работу :-) Потом была возможность посмотреть как оно все на самом деле сделано - долго работал (да и сейчас работаю) в проекте, включающем большой кусок ковыряний внутренностей SQL Server/SyBase/ORACLE/PostgreSQL/MySQL/Exchange. Потом TrackStudio.

Думаю, что все-таки есть задачи, с которыми РСУБД справляются крайне криво и наш случай - это оно.

Безотносительно к СУБД, в которых я не силён (ну не мой профиль, мало работал с ними), но о критике технических решений вообще.

Мне очень часто приходилось реализовывать самому что-то, что вроде бы уже существует в готовом виде. Приходилось даже выслушивать по этому поводу упрёки в некомпетентности и незнании чего-то. Даже слова о велосипедах много раз звучали. Правда, при детальной проверке упрёка обычно выяснялось, что существовать-то оно существует, но по каким-то параметрам чуть-чуть не совсем в том виде, в каком бы хотелось, а довести это "чуть-чуть" до ума либо проблематично вообще, либо по трудоёмкости вполне соспоставимо с реализацией функциональности своими силами. В этом смысле я вообще как-то больше доверяю "доморощенным" решениям, если они вообще возможны, чем "полному использования функциональности продукта икс". Слишком много ограничений на будущую свободу развития архитектуры такие "полные использования возможностей" накладывают.

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

Мне это напоминает балансировку АВЛ-дерева, когда при изменениях может меняться точка подвеса многих поддеревьев. При этом никому не нужно идеально сбалансированное дерево, как и "идеальная архитектура". Нужен определённый уровень сбалансированности. Соответственно, квалифицированный архитектор -- это тот, кто умеет заложить в основу достаточно разумную модель, а потом, в условиях постоянно меняющихся требований, умеет балансировать -- идеи, модели, концепции, взаимоотношения частей системы -- так, чтобы всё время существовал некий минимальный уровень стройности концепции. При этом даже метафора системы может со временем претерпевать радикальные изменения. Лишь бы она вообще продолжала существовать, пусть и в другом виде. Вот когда метафора вообще теряется за грудой подпорок -- начинается моральное устаревание системы, период, когда она "доживает своё" (впрочем, часто это самый долгий этап жизни систем).

Собственно, после этих общих рассуждений хочу подвести итог. Жёсткая критика конкретного технического решения обычно говорит о том, что критикующий за деревьями не видит леса. Зачастую в принципе невозможно понять, разумно ли конкретное решение, не понимая системы в целом достаточно чётко. Я не могу сказать, разумно ли конкретное Ваше решение, но интуитивно жёсткое запихивание в РСУБД данных такой структуры кажется не самым лёгким путём.

Ужос, наймите архитектора, прежде чем кодить !

1. ваша задача просто создана для оракла с его connect by
2. ВСЕ современные субд имеют иерахические запросы mssql, db2 это WITH, postgres есть патч с connect by
3. если вдруг у вас отсалый mysql есть патерн Celko Tree, ВСЕ ваши запросы при этом патерне сводится к ОДНОМУ селекту по нескольким индексам.
4. Я тестировал, connect by из oracle 10.2 как примерно равен по скорости Celko Tree - значит варианта 2: у вас руки кривые или 15 лет назад 8i был еще не на высоте. короче планы в студию.
5. закрытие полей для тех пара ролей, что есть багтрекерах элементарно делаются через вьюшки. row level security в оракле уже 7 лет, но только в EE редакции, вам за глаза хватит вьющек на каждую роль. если вьюшками не обойтись, простенькая логика на список полей и динамический SQL (если уж так лень расписывать все варианты в if'ах).

Re: Ужос, наймите архитектора, прежде чем кодить !

Всю переписку читали ?

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

А база у нас любая - ORACLE, MySQL, MS SQL, PostgreSQL, HSQLDB, Firebird, DB2.

Хотя на первый взгляд пульты кажутся очень похожими, это серьезное внутреннее ограничение магнитофонов, а не досадная недоработка разработчиков пульта.
Не в силах понять, что же было написано во всех предыдущих абзацах, могу прокомментировать этот тезис.
Во-первых, кнопки перемотки по трекам есть на любом более-менее нормальном стационарном приборе, а также почти во всех кассетных плеерах. Поиск трека осуществляется по паузе (что очень логично, не правда ли?). Во-вторых, есть профессиональная аппаратура, где поиск на плёнке ведётся по индексу, который записывается параллельно данным. Так что отсутствие кнопок нельзя сводить к ограничению магнитофонов (как устройств воспроизведения). Скорее, это издержки технологии, основы которой закладывались тогда, когда с электроникой было туго.

Понял, спасибо. У нас тут проблема очень близкая - хотя поиск в магнитофонах как бы есть, но он сделан не в лучшем виде и использовать его сложно. Если им приходится пользоваться раз-два в день - нормально, а если мы захотим на его основе сделать "интерактивную кассету" (например, обучалку ПДД), где такие поиски происходят раз в несколько секунд - получится очень медленно. А что если сделать файловую систему на кассете ? :-)

Аналогично и с security/иерархиями в реляционных СУБД - они как бы есть и поддерживаются, но коряво и в самых дорогих версиях отдельных продуктов, делать это основой своего продукта не хочется.

> Проблема тут в том, что реляционные СУБД вообще плохо подходят для написания приложений типа TrackStudio по принципиальным соображениям:

Мягко говоря, спорно - слишком много таких систем написано и успешно работает. В целом все сказанное здорово напоминает очередной гимн объектной либо сетевой СУБД, вся прелесть которых в том, что автор их еще не пробовал (не собираюсь утверждать - пробовал или нет; говорю лишь - напоминает).

> Из всех популярных РСУБД только в ORACLE есть start with/connect by,

Я люблю и ценю Oracle, но утверждение запоздало лет на пять...

> Маленький пример из другой области: у кассетных магнитофонов и DVD-плееров пульты почти одинаковые, но на пульте магнитофона нет кнопок перехода к следующей/предыдущей записи. Хотя на первый взгляд пульты кажутся очень похожими, это серьезное внутреннее ограничение магнитофонов,

Маленький пример: берите хорошие магнитофоны. На моей Вега-122МП такое кнопки есть. Удачно иллюстрирует логику сказанного :)

> Мягко говоря, спорно - слишком много таких систем написано и успешно работает. В целом все сказанное
> здорово напоминает очередной гимн объектной либо сетевой СУБД, вся прелесть которых в том, что автор их
> еще не пробовал (не собираюсь утверждать - пробовал или нет; говорю лишь - напоминает).

А можно примеры ? То что я видел - там системы не совсем такие, т.е. или количество уровней в иерархии ограничено, или количество элементов, или значительную часть опций security можно задавать только для проектов и прочих контейнеров.

Гимн объектной или сетевой СУБД не пою :-) Одно время игрался с Cache' и db4o, совсем не впечатлило, но от этого наши проблемы с реляционными СУБД меньше не стали.

> Я люблю и ценю Oracle, но утверждение запоздало лет на пять...

Да, именно тогда мы и выбирали вариант реализации :-). Еще был патч для PostgreSQL, но производительность была "не очень", так что ковырять в этом направлении дальше смысла не было.

> Маленький пример: берите хорошие магнитофоны. На моей Вега-122МП такое кнопки есть.
> Удачно иллюстрирует логику сказанного :)

Иллюстрирует даже более удачно, чем кажется на первый взгляд :-) Попробуйте на том магнитофоне использовать перемотку для реализации "интерактивной кассеты" (типа обучалки ПДД), т.е. пользователь жмет кнопки, а ему в соответствии с нажатиями проигрываются разные куски. Или файловую систему сделать :-)

Тут ситуация ровно та же - формально реляционные СУБД с иерархиями работать умеют, если их не сильно этим грузить - справятся, но это не является их сильной стороной.

по отношению к самой задаче

Если сужения прав ниже той точки, где они были выданы, не бывает. То можно эксплуатировать очень простой факт: права доступа на системе в эксплуатации будут выдаваться руками, поэтому количество точек выдачи доступа будет меньше, чем любых других объектов.

Тогда можно обойти все точки дерева, где отмечено изменение прав доступа, и выбрать из них те, в которых у текущего пользователя он есть, индивидуально ли, в силу ли членства в группах.

От выбранных точек древовидно вниз дальше можно делать все, не заботясь больше о security.

Re: по отношению к самой задаче

Кроме того, field-level security на уровне базы данных не нужна, можно сперва выбирать из базы небольшой subset объектов, разрешенных для отображения вообще, и уже при отображении разбираться с правами доступа к отдельным полям.

В худшем случае в выборку попадет объект, у которого все поля недоступны, и поэтому он не должен был попадать в выборку. Если такая ситуация, -- пользователю по row-level security разрешен доступ к объекту, а поля его запрещены все, -- не частая, то это можно как-нибудь замаскировать, никто не пожалуется.

Re: по отношению к самой задаче

Во-первых, и сужается, и расширяется.
Во-вторых, все и так чудесно работает, спасибо. Мы не суровые Челябинские программисты настолько принципиальны, чтобы обязательно использовать SQL

Про Exchange 2007

Читаю тут Windows IT Pro за октябрь 2007, там есть статья про Exchange 2007. Ну и начало там такое:

No SQL Server ?
The biggest change that many expected to occur in Exchange 2007 was a transition to Microsoft SQL Server as the database engine for the Store. However, when the Exchange developers investigated the challenges of forcing a database engine designed for structured transactions to handle the work generated by Exchange and its clients, they decided they couldn't do it for Exchange 2007.

Ну т.е. ровно та же история: большинство пользователей считают - можно и нужно, разработчики считают - нельзя, и объясняют это именно особенностями генерируемой нагрузки и неприспособленностью реляционных СУБД к такой нагрузке.

Re: Про Exchange 2007

странные у вас ассоциации. имхо скорее покапавшись они обнаружили что система спроэктирована так, что дешевле забить чем пытаться "это" натянуть на реляционную структуру. например они не придумали способов как mssql бы не просела от долбежа запросов в цикле.

Triffids.

Хм, когда мне надо было много и эффективно работать с деревьями в БД, я просто оптимизировал хранение и разменивал скорость чтения на скорости вставки/изменения.
Например, сортировка дерева и хранение для каждой ветви кода "брата" - очень упрощает и ускоряет запросы. Особенно если по этому полю еще и физически сортировать. При вставках и модификациях, конечно, требуются довольно большие update - но это не так часто и все равно одним-двумя операторами.
На нормальных БД (мне пришлось делать на MS SQL, но гораздо лучше такое делать на DB2) все работает очень даже шустро. С учетом потребностей трекера - хоть на бесплатной версии и поставлять с продуктом )

Ну а права, конечно, нужно каким-то образом предвычислять (стратегий там много, зависит от конкретных требований). Но ничего неимоверно сложного там тоже есть, да и объемы у вас достаточно маленькие, да и нагрузка тоже весьма ограничена.

Мы в итоге пошли не по пути предвычисления, а по пути кеширования всего в памяти. Лучше это или хуже - затрудняюсь сказать.

Из соображений скорости нам в принципе хватило бы in-memory движка, поддерживающего persistence на диск. Т.е. который требовал бы, чтобы база целиком помещалась в память, но который при этом мог бы выполнять десятки тысяч поисков по ключу в секунду. Фактически, 60% кода TrackStudio - это и есть реализация подобного движка, но т.к. изначально ничего такого не задумывалось - движок получился довольно корявым.