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

AG>>Вот и прорабатываю, как ограничить рост базы, но пока (да и в обозримой перспективе) ничего в пределы не упирается
C>Мне, вообще, кажется, что использование MS SQL-Server в задаче где не требуется поддержка целостности данных это перебор.
Есть две задачи:
a) Хранение данных с известной структурой;
b) Удобная выборка данных.
Разве этого НЕдостаточно, чтобы принять к применению чт-то из реляционних СУБД?
Спорить можно скорее на тему: ORACLE vs MS SQL

C>Тут надо что-то из NoSQL попробовать, MongoDB например.

Я читал статьи наподобие этой:
https://habrahabr.ru/company/ruvds/blog/324936
или этой:
https://habrahabr.ru/post/152477

...и даже и небольшую практику с MongoDB имел на старом рабочем месте.
Тем не менее, для хранилища данных (если знать структуру этих данных) — что удобнее, нежели SQL

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

AG>>Вот и прорабатываю, как ограничить рост базы, но пока (да и в обозримой перспективе) ничего в пределы не упирается
C>Мне, вообще, кажется, что использование MS SQL-Server в задаче где не требуется поддержка целостности данных это перебор.
Есть две задачи:
a) Хранение данных с известной структурой;
b) Удобная выборка данных.
Разве этого НЕдостаточно, чтобы принять к применению чт-то из реляционних СУБД?
Спорить можно скорее на тему: ORACLE vs MS SQL

C>Тут надо что-то из NoSQL попробовать, MongoDB например.

Я читал статьи наподобие этой:
https://habrahabr.ru/company/ruvds/blog/324936
или этой:
https://habrahabr.ru/post/152477

...и даже и небольшую практику с MongoDB имел на старом рабочем месте.
Тем не менее, для хранилища данных (если знать структуру этих данных) — что удобнее, нежели SQL

P.S. Хочу всё-таки напомнить, что СУБД — это всё-таки инструмент для решения задач хранения данных, а не задач по созданию лишнего геморроя.