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

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

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

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

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) исследовать различные запросы, выполняемые от нашего приложения, на предмет как корректности, так и оптимизации по времени.