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

Итак, речь идет о системе сбора данных о, скажем так, расследованиях.
На пальцах — смысл прост:
Вот возник у нас неприятный случай. Злоумышленник причинил некоторый ущерб. Начинается расследование, которое должно этот ущерб вернуть. И тут есть три основных задачи:
1. Отслеживать ход расследования. Ну типа дело начато тем-то, ответственным назначен такой-то, передано тому-то в связи с тем-то и т.п. Типичный workflow processing.
2. Хранение разнообразных данных. Свидетели, улики, подозреваемые, адреса и т.п. Все в центральном сервере, так чтобы из региональных филиалов все стекалось и искалось.
3. Могучая поисковая енжина. С таким интеллектом, чтобы пользоваться ей мог даже сержант ГИБДД. Ну типа повводили мы данных, а система нам и говорит "ага, мои любезные, хочу вам подсказать, что аналогичный случай имел место в городе Одесса. В связи с чем рекомендую обратить внимание на...". Причем не только не требуя от пользователя нудного указания условий поиска, а лучше и вообще безо всякой инициативы.
4. Отслеживать статистику по расследованиям — ну там типа среднее время закрытия дела, средний процент возврата ущерба, общая сумма ущерба по сравнению с аналогичным периодом прошлого года и т.п.

Начинаем проектировать. Ага, сущностей-то — всего ничего: дело, персона, улика, да прочий материал.

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

В общем мораль такая: что-то не очень у меня выходит нарисовать строго типизированную модель.

А главное — не факт, что это надо!
С точки зрения п.2, фиксация любой структуры — это
а) наличие нуднейшей формы, в которой большинство полей не заполняются никогда
б) нехватка полей для ввода какой-то информации, которую мы не предусмотрели.

Таким образом, возникает острое желание заменить это моделью, в которой с любым объектом можно проассоциировать любые именованные атрибуты. Атрибут соответственно может быть либо скаляром, либо вектором. При этом скаляр может быть значением, а может быть и ссылкой.
В общем, чистый джаваскрипт.

Однако смущает меня три вопроса:
1. Как нам приделать к этому персистенс? Не будет ли "однотабличная" модель, в которой свалены все кусочки данных (objectID, attributeName, attributeValue), слишком медленной?
2. Как насчет пункта 3?
В идеале, система должна выводить "все преступления с таким же почерком". На практике, надо искать
а) похожих людей (сходство по любому атрибуту)
б) похожие места (в смысле адреса)
в) похожие улики (типа поддельный чек выписанный на тот же банк, или там еще что)
Вот мне и интересно, есть ли опыт практического решения подобных задач для слабоструктурированных данных (окромя как за.кинуть вообще все в full-text engine, а дальше нехай враги разбираются)
3. Как быть с пунктом 4? Статистика вроде хорошо ездит по структурированным данным, а как быть со слабоструктурированными — я что-то даже не соображу.


0. Ну и, конечно, как забабахать пристойнй гуй к такой системе, где мы не очень-то чего можем сказать об ее элементах.


Так что вот остановился я и призадумался. Может, ну ее — эту строгую типизацию?