Доброго дня

Напроектировали со товарищи. Хочется видеть возможные сценарии дальнейшего (развития).
Уважаемые коллеги, очень Вас прошу, какой бы дурной реализация Вам не показалась, поделитесь ссылками на похожее, замеченными потенциальными проблемами (и решением, если есть), мне как-то нужно это разруливать. Иногда я в ужасе.

В чем, собственно, дело: задача была спроектировать хранилище данных с историчностью. Начиналось с обычной реляционной со многими таблицами, но постепенно пришло практически к одной таблице - логу, в которую валится полное состояние объекта сразу после его изменения. Т.е. в логе все состояния всех объектов, чтобы добыть состояние объекта указываем Ид объекта и время, сервер находит в логе последнюю версию до указанной даты.

Когда нужен более сложный запрос с пересечением нескольких множеств разнотипных объектов, то во времянки получаем "снимки" множеств объектов базы на указанное время и уже на этих снимках строим запрос. Пример:
Select * from @Пользователи201602081345 U inner join @Машины201602081345 M on U.id =M.UserId

Пожалуйста, я в ужасе. Логически схема рабочая, но беспокоят проблемы производительности, они - это сразу ясно - огромны, но фатальны или «ещё можно побороться»?

alexeyvgНепонятно, зачем вообще тогда сервер RDBMS? Хранили бы просто этот массив в файле, типа "собственной СУБД". Это вполне нормальный рабочий вариант, для многих задач. Тем более у вас структура простая, одинаковые нехитрые записи одной структуры для всей системы, на массив байт и на файл хорошо ложится.
При запуске проги файл читается в память, потом записывается обратно.

Что дали, то и юзаем. На больших проектах нет возможности принимать вообще все решения. Критерий "простоты структуры" оценить затрудняюсь.
Из плюшек базы хотелось бы иметь индексы, распараллеливание, что при самостоятельной реализации на "файлах" требует отдельных стопицот человекочасов.

alexeyvg...Андрей...Из плюшек базы хотелось бы иметь индексы, распараллеливание, что при самостоятельной реализации на "файлах" требует отдельных стопицот человекочасов.Этих плюшек не будет, из за используемой модели.

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

Как подтолкнуть сервер к распараллеливание не знаю, но возможно, что эта функция и так задействуется.

Кот Матроскин...Андрей...,

Не совсем понятно, что значит "валится полное состояние объекта сразу после его изменения" - ведь у объектов разный набор атрибутов?

Вся строка с объектом переводится в форму XML.

Прекиньте, пацаны, это мы сделали MongoDB, внатуре.

Поражаюсь, какими путями инженерная мысль идёт в РФ.

skyANA...Андрей..., да вы там походу знатные велосипедисты :)

Атож.. Зато какая гордость за Державу: из чё хошь можем сделать чё хошь. (кривой смайл)

skyANA...Андрей..., кстати а не хотите выложить на GitHub, как http://neventstore.org/ ? Глядишь найдутся умельцы, что решат вам проблемы с производительностью :)

Контора дюжe опасная. К тому жe я уволилсо. Нe стыдитe – и бeз того нeловко.