Здравствуйте, Silver_s, Вы писали:

S_> На данный момент самая мощная и универсальная база данных-знаний это Google.
Ну, в данном случае настолько универсальной не надо.
S_>Там бывает легче найти информацию, чем в MSDN,различных хелпах, специализированных программах-справочниках.
Это тем, кто не умеет искать в MSDN,различных хелпах, специализированных программах-справочниках.

S_> Вот одна из найденых ссылок по такому запросу: "номер фальшивой банкноты"

S_>

S_>В настоящее время выявлены фалшивые банкноты номиналом 10 гривен со следующими номерами:
S_>1750104051; 2151188067; 4215311880; 4215317785; 6539776529; 8506899032; 9438344911; 9662130061.

Замечательно. Какой номер этой ссылки в запросе? Ничего, что первые три посвящены детекторам валюты?
S_> А хранятся ли в Google специальные атрибуты номера банкнот? Конечно нет.
Ну вот и искать в нем — это отдельная работа.
S_> Это к тому что может не о структуре SQL таблиц сначала думать а о концепции. Может задача почти не для реляционных БД. Маленькая часть реляционная, а остальное навороченые поисковые технологии (не имеющие отношения к SQL).
Может. Но тут больше похоже на поиск по образцу. Полнотекстовый поиск не может похвастаться релевантностью на структурированных данных.

Здравствуйте, Sinclair, Вы писали:

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

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

<...>

Хотелось бы поинтересоваться какое решение было выбрано, и с какими проблемами столкнулись в реализации ...

ЗЫ. Возникла похожая задача (слабоструктурированные данные), в какую стророну рыть пока не совсем понятно

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

Здравствуйте, ssl, Вы писали:

ssl>ЗЫ. Возникла похожая задача (слабоструктурированные данные), в какую стророну рыть пока не совсем понятно
Всю тему пока не осилил. Вы в сторону XML + RDF + OWL уже смотрели?

Who Killed the Virtual Case File?

Гм,есть, кроме перечисленных, еще одна техника, которой, например, я пользуюсь.
Если архитектура у тебя трехзвенка, то можно в БД использовать только для: хранения формализованных данных с всегда общим видом параметров и для всевозможных хитрых индексов. А все хитрое (например, улики) хранить в виде сериализованных (в XML, например) Java объектов (ну или С# объектов).

Как это работает:
ну, с просмотрами и выборками по истории дел все просто — общая табличка дел, из нее ссылки на объекты, полностью описывающие различные виды улик.
с поисками — все чуть хитрее. Пусть все улики реализовывают некий интерфейс "getDraftString" — в который выкидывается то, что можно назвать "характерной информацией" для улики. В базу при сохранении дела закидываешь эти draftString (по сути — атрибуты, но предназначенные не для отображения пользователю, а для поиска — например, не полное имя банка, а очищенное от всяких АО или вообще только вокализация и т.п.). И при поиске — ищешь только по этим индексам.
Это, во-первых, быстро, во-вторых отделяет систему "поиска данных" от "документооборота" — и можно делать одно, не сильно думая о другом.

Ну а уж как работать с сложными иерархиями или PropertyBag'ами на высоком уровне — всяко разберешься.
Главное — первую версию напишешь быстро.

Здравствуйте, <Аноним>, Вы писали:
А>Ну а уж как работать с сложными иерархиями или PropertyBag'ами на высоком уровне — всяко разберешься.
Спасибо за комментарии
А>Главное — первую версию напишешь быстро.
Ну, c учетом того, что с моего вопроса прошло два года, фактор скорости уже не очень важен.