AriochчччДЧуть-чуть умеющий кодить прикладник с большой вероятностью создаст адекватную прикладную систему.

.....пока система маленькая и не упирается в возможности железа.

А когда надо начинать наворачивать кэши с разными срезами - это уже когда все, тупой метод "в лоб" перестал работать. И дальше.... как повезет.
Начинается увеличение сложности, это влечет за собой свои и чужие ошибки, которые нужно вовремя опознать, потом найти, потом исправить....

Но "первое блюдце" он найдёт и вылакает без вопросов, спорить глупо.
"Пока котлеты не подгорали" у топикстартер было всё отлично.
А потом данные доросли до 2ГБ и началось.....
Ну ничего, будем потихоньку расти и развиваться :). Вообще моя работа больше связана с расчётом на уже созданных мощнейших программных комплексах. Я же просто подготавливаю и визуализирую по средствам своих программы исходные данные и результаты, хотя в будущем хочу и больше сам делать.

А вообще по факту львиная доля серьёзных расчетных программ с точки зрения программирования весьма примитивны, там вся сложность в методике и математике, ну и исходных данных, конечно.

чччДАндрей ИгоревичУ данного способа есть недостаток. Если мне надо пройтись по всему массиву данных (весьма популярный "запрос"), как бы "вдоль" массива (вдоль - по времени) - то придётся поочерёдно загружать - выгружать всё БД для каждого запроса, либо дробить БД на более мелкие элементы.

если будешь использовать типизированные файлы - то размер блока может быть любым.
...
Можно данные массива хранить, "раскладывая" их по разным плоскостям. Данные будут храниться в избыточном (в разы) количестве, да, но зато ты сможешь пройтись "вдоль" массива также быстро, как и "поперек".
...
Я на всякий случай предложил: мало ли, вдруг твои алгоритмы предполагают длительную работу в отдельных "срезах" массива, зная эту особенность, можно здОрово выиграть описанным выше способом.
Ну я так и хотел по сути сделать. Так что попробую.
AriochчччД,
типизированный файл скорее всего будет глючить при размерах >2ГБ
Ну значит будет много файлов по 2Гб :).

чччДАндрей Игоревич...
И стоп в 2 раз. А сколько можно столбцов в БД сделать? 350 можно? Никаких подводных камней не будет? Это, как мне кажется, очень так ускорит заполнение.
Много можно. Видел табличку в 500 полей.
Главное, чтобы данных там не более 64кБайт (реально - чуть поменьше) на одну запись набралось.

В общем стало ещё медленней, но, возможно, из-за того, что отказался от строки в пользу Float (может операция преобразования строки в число в самой БД требует время).
Ладно, пока от БД отойду, попробую через TFileStream.

AriochАндрей ИгоревичЕсть ли какие-либо преимущества у БД для подобного вида операций?

В принципе есть, но у ДРУГИХ баз данных, их даже часто называют не базами, а хранилищами.
Firebird - чётко выраженный сервер для OLTP - https://ru.wikipedia.org/wiki/OLTP

Если же вы хотите визуализировать большие объёмы редко изменяемых данных, то ваша область - OLAP.

https://ru.wikipedia.org/wiki/OLAP

Ну и дальше по гуглю для этой аббревиатуры

https://ru.wikipedia.org/wiki/OLAP-куб
http://www.olap.ru/basic/alpero2i.asp
https://habrahabr.ru/post/126810/

и т.д.
Ну некоторый ликбез произвел, но создалось впечатление, что для меня это избыточна, может позже поподробнее изучу.

AriochКроме того, всё таки когда речь о доступе то вдоль то поперек к мега-массиву - я бы подумал о переходе на 64-битный Delphi и MMF. Сделал вид, что весь файл целиком загружен в память - и гуляй по нему как захочется, а система пусть подгружает по мере необходимости
Ну я и так 64- битный теперь использую (там где не использую БД), а вариант с файлом на жестком диске подключаемом "как из оперативы" (забыл как это называется) мне ещё в начале этой темы предлагали, у меня не получилось :), и я пошел другими путями.