AriochчччД,

1) в уровне подготовки, вплоть до того, что ТС настоячиво спрашивает азы по FB в форуме по Delphi
2) в требованиях к надежности и скорости управления ядерными реакторами ( привет внезапной сборке мусора в FB например)

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

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

Arioch1. При необходимости хранить и обрабатывать гигабайты данных таки желателен программист

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

2. Я сильно сомневаюсь, что для хранение гигабайтов однородных данных, без необходимости автоматически отслеживать сложную "ссылочную целостность / referential integrity", SQL вообще правильный инструмент.

2а. Часто SQL используют для удобства, не глядя на ухудшение скорости. Например хранение настроек программы в SQLite и аналогично. Это удобно. А потери в скорости и дисковом пространстве незаметны и их справедливо игнорируют.
2б. Хранение однородных данных в SQL с "обвязкой" в виде дополнительной информацией вполне вероятно увеличит общий размер файлов.
2в. Может казаться соблазнительным использовать SQL дял расчетных задач. Вместо ручного написания циклов, бегающих по миллионам записей - пишем один UPDATE и он все "делает сам". Я так экспериментировал с Firebird, и решил такого не повторять. Как тоьлко начинаются какие-то ошибки, типа слишком малое значение округляется в ноль, лезут ошибки вычисления и понять где именно на каких конкретно данных я чего=-то не учёл и словил "деление на ноль" становится очень сложно. Удобство "одного UPDATE'а" мгновенно компенсируется ужасом поиска и исправления ошибок, если что-то идёт не так.

Желателен, знаешь сколько будет стоить профессиональный программист с фундаментальными знаниями в прочности, нейтронной физике, конструкции РУ? Да и ещё и только на время решения конкретной задачи.

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

Данные(значение полей) я планировал в БД хранить как строку типа "2.08406E+13", а в дальнейшем работать просто с данными через запросы по индексам, не думаю, что это может привести к каким-то ошибкам.

Как тут уже писалось, БД начал использовать из-за очень большого объема значений (до 10кккк), для которого не хватало оперативной памяти и возникли проблемы при прокручивании такого объема массивов (при том мне для большей части задач весь массив нужен не был).

Были варианты через типизированные файлы, на данный момент через них и сделал. Но не всё меня устраивало, решил попробовать БД. Сейчас добью и опять вернусь к типизированным файлам.

чччДТы в IBEpert сей EB испытывал?
Начни с него, с одного insert, потом добавляй.
Может, в ibx глюк. А может, в FB. А может, в твоём коде. Искать надо.
В общем в IB работает, почему не работает через Делфи - разбираться что-то не хочется. Фиг с ним,с этим способом.

чччД,

Иии при достижении размера базы в 2.133.901.312 байт начались проблемы (примерно на таком же размере, кстати, начинались проблемы с типизированными файлами). Добавляет некоторое количество данных и выпадает с ошибкой добавления нового значения (база перед добавлением значений была очищена), создал рядом новую базу и тем же кодом спокойно ей заполнил.
Может это виндовские заморочки?

AriochАндрей Игоревич,

файловая система какая на диске, где лежат файлы с данными ?

не FAT32 случайно ?
Нет - NTFS. В общем завтра поковыряюсь, сегодня рабочий день катится к концу.

AriochАндрей ИгоревичДанные(значение полей) я планировал в БД хранить как строку типа "2.08406E+13"

зачем, если в SQL есть "родной" тип DOUBLE PRECISION ?

конечно, если точности стандартных типов не хватает и нужны гораздо более длинные числа с плавающей запятой, чем поддерживает стандартный процессор (и стандартная Delphi), тогда только текстом и имитировать "вычисления в столбик" (библиотеки типа big number).

но если вычислительная часть у вас сделана на стандартном типе double, то это лишнее

-------------

Андрей Игоревичпрофессиональный программист с фундаментальными знаниями в прочности, нейтронной физике, конструкции РУ

А что, работа командой уже не в моде, всё должен один единственный Левша-многостаночник сделать?

В принципе, конечно, компьютеры не обязательны, при расчете РБМК от численного моделирования отказались принципиально, но и результат не самый лучший.

Андрей ИгоревичБыли варианты через типизированные файлы, на данный момент через них и сделал.

1) Тут могут быть проблемы в скорости, поскольку писались эти типизированные файлы оооочень давно, когда памяти в компьютерах было мало. Буферизация там крохотная. Лучше бы найти что-нибуд ьс буферизующим чтением-записью.
Например тут один товарищ выложил свою библиотеку CachedBuffers, но насколько она надежна и крута не знаю, не пользовался.

2) В любом случае на таких объёмах возможны случайные повреждения данных. Пролетела частица, переключила пару бит, число поменялось, никто не заметил. В типизированых файлах желательно кроме самих данных добавлять информацию для детектирования и, по возможности, исправления повреждённых данных. Можете, конечно, сказать что у вас настолько много сырых данных, что случайные изменения в паре десятков чисел ни на что не повлияют, может быть так и есть.

3) для потоковой обработки больших объямов данных возможно стоит купить два отдельных жёстких диска.
С первого файлы читаем, выполняем вычисления, на второй диск пишем.
Если вычисления идут в несколько этапов, и каждый этап кладется в файл, то делаем по очереди ,с 1-го диска на 2-1, потом со 2-го на первый и так далее. Цель - перевести аппаратуру дисков из режима случайного доступа в режим потоковой работы, который быстрее.

Можно и в Double, сейчас глянув как распухает файл БД, может лучше и Double, всё таки строка в 11 символов - 22 байта, против 8.

Работа в команде это хорошо, но по факту вместо одного человека нужно уже два. Скажем так, пока я делаю программы "для себя", для визуализации и обработки исходных данных и результатов расчетов аттестованных программ (которые, данным"бонусами" в большинстве своем не обладают). Но это пока, а там посмотрим.

1. Найти - это хорошо, но сложно :).
2. По поводу повреждения данных, я в условиях нейтронного облучения не работаю :), повреждение данных в обычных условиях кажется мне маловероятным, да и современные носители информации, думаю, имеют всякие там суммы и прочие данные для восстановления битых секторов.
3. В таком случае проще купить больше оперативной памяти и гонять вообще всё в ней, но это "фантастика" для бюрократизированной организации. Есть ВоркСтешен - на ней и работайте. Даже суперкомпьютер есть, просто мороки для его использования слишком много.

чччДАндрей ИгоревиччччД,

Иии при достижении размера базы в 2.133.901.312 байт начались проблемы (примерно на таком же размере, кстати, начинались проблемы с типизированными файлами). Добавляет некоторое количество данных и выпадает с ошибкой добавления нового значения (база перед добавлением значений была очищена), создал рядом новую базу и тем же кодом спокойно ей заполнил.
Может это виндовские заморочки?

Ну ты бы код показал. Может, и решили бы эти проблемы.
Ну в конце рабочего дня вторая БД, которую решил протестировать на возможность с работой уже бОльших массивов разрасталась до 4GB, так что не знаю, что было с первой базой, хотя надо и новую будет попробовать записать уже разросшуюся, но это уже завтра.
В принципе 50ккк значений было записано минут за 15-20, что не так уж и плохо.
А, стоп, я же сразу по 2 значения записывал в одну строку, значит формально я записал 100ккк значений.

И стоп в 2 раз. А сколько можно столбцов в БД сделать? 350 можно? Никаких подводных камней не будет? Это, как мне кажется, очень так ускорит заполнение.