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

bnk>А зачем вам тогда вообще SQL SERVER? Почему не просто файл например?

Файлы — возможное, однако НЕ удобное решение для данного круга задач. Причины следующие:

1) Нам нужно хранить определённые структуры данных, где явно имеются определённые поля (столбцы). Выбирать набор таких структур
намного проще испльзуя привычные SQL запросы, нежели городить свои процедуры работы с файлами, тем более, что SQL имеет удобочитаемый вид.
Это особенно важно, когда в команде авторов есть как программисты, так и разработчики алгоритмов, для которых понять SQL скрипт —
намного проще, чем разобраться в кодах C/C++ (то есть в кодах самого приложения).

2) Объём хранимой информации — весьма большой, по мере проведения экспериментов, он быстро увеличивается. Таким образом, возникнет
дополнительная проблема архиварования при переносе, которая при использовании MS SQL Server решается элементарно: back-up/restore.

3) По мере исследований и доработок имитационной модели, происходит изменение структур (таблиц), изменение количества полей (столбцов).
В этом случае, подкорректировать SQL скрипт будет намного проще (и быстрее), нежели изменять в кодах проекта процедуры работы с файлом.

4) В составе MS SQL Server имеется удобная утилита — MS SQL Server Management Studio. Применяя данную утилиту, я имею возможность:
a) запрашивать — через SELECT... любые данные из любых структур, при этом сразу видеть результат выполнения данного запроса;
b) изменять — выполнив UPDATE любую запись (строку) в любой из таблиц (без сложных действий — программирования файловых процедур);
c) исследовать различные запросы, выполняемые от нашего приложения, на предмет как корректности, так и оптимизации по времени.

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

bnk>А зачем вам тогда вообще SQL SERVER? Почему не просто файл например?

Файлы — возможное, однако НЕ удобное решение для данного круга задач. Причины следующие:

1) Нам нужно хранить определённые структуры данных, где явно имеются определённые поля (столбцы). Выбирать набор таких структур
намного проще испльзуя привычные SQL запросы, нежели городить свои процедуры работы с файлами, тем более, что SQL имеет удобочитаемый вид.
Это особенно важно, когда в команде авторов есть как программисты, так и разработчики алгоритмов, для которых понять SQL скрипт —
намного проще, чем разобраться в кодах C/C++ (то есть в кодах самого приложения).

2) Объём хранимой информации — весьма большой, по мере проведения экспериментов, он быстро увеличивается. Таким образом, возникнет
дополнительная проблема архиварования при переносе, которая при использовании MS SQL Server решается элементарно: back-up/restore.

3) По мере исследований и доработок имитационной модели, происходит изменение структур (таблиц), изменение количества полей (столбцов).
В этом случае, подкорректировать SQL скрипт будет намного проще (и быстрее), нежели изменять в кодах проекта процедуры работы с файлом.

4) В составе MS SQL Server имеется удобная утилита — MS SQL Server Management Studio. Применяя данную утилиту, я имею возможность:
a) запрашивать — через SELECT... любые данные из любых структур, при этом сразу видеть результат выполнения данного запроса;
b) изменять — выполнив UPDATE любую запись (строку) в любой из таблиц (без сложных действий — программирования файловых процедур);
c) исследовать различные запросы, выполняемые от нашего приложения, на предмет как корректности, так и оптимизации по времени.

5) Используя MS SQL Server Management Studio, я могу оперативно создавать новые таблицы и корректировать старые, при этом в
кодах приложения может (на текущий момент) иметься только процедура выборки данных (через SELECT...), что позволяет оперативно
изменять данные для проводимых экспериментов, не производя действий, которые впоследствии могут оказаться вообще лишними.

P.S. Вся поддержка работы с БД в кодах приложения выполнена в виде программного интерфейса (aka абстрактный класс в C++).
Посему, если возникнет необходимость, изменить тип хранилища можно относительно безболезненно.