Генерация динамических таблиц

Похоже, вы неструктурировали или, в лучшем случае, полуструктурированные данные. Классические реляционные таблицы DB не идеальны для этого, если вы не используете XML в качестве хранилища. Вы можете подумать о том, чтобы придумать промежуточный язык определения отчета, а затем сохранить его в БД, как правило, как XML. Сервер MS SQL, Oracle и DB2 поддерживают хранение и запрос данных XML.

После некоторого размышления ..
Вы также можете изучить шаблон наблюдения и посмотреть, можно ли его адаптировать к этому примеру. Хотя шаблон OO, это можно сделать в SQL.
Это немного длинное объяснение, но я опубликовал упрощенную модель здесь ; Надеюсь, вы найдете это полезным.

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

Автоматическое создание таблиц может дать вам головные боли, если количество таблиц становится огромным. Списки каталогов в ext3 для dirs с более чем 5000 наименованиями начинают чувствовать себя дорогими и, конечно же, занимают много времени, когда вы получаете более 100 000 файлов. (CLI mysql попытается кэшировать все имена таблиц при его подключении, и, чтобы пропустить это, вам нужно подключиться к -A-коммутатору.)

Вы могли бы рассмотреть возможность использования временных таблиц для создания отчета, а затем, возможно, впоследствии уменьшите результаты до строки отчета для извлечения. Или, как отмечает JP, структура таблицы, которая тегирует значения и отчеты в одной и той же таблице:

create table stddev ( report_id int(11), field_name int(11), -- fk to field field_value double ); create table reports ( report_id int(11); report_name varchar(255); ); 

И чтобы получить данные только для одного отчета, вы бы сделали выбор, указав report_id:

 select * from stddev where report_id = 123; 

Я бы создал таблицы для ваших имен отчетов, имен полей, и вы, вероятно, захотите разделить входные значения от выведенных / вычисленных значений, сохраненных для ваших отчетов.

В зависимости от того, как часто вы вводите новые данные, я бы не стал преждевременно оптимизировать от нескольких больших таблиц до большого количества небольших таблиц. Правильно проиндексированный, большой стол может работать хорошо.

Однако какова величина данных, обрабатываемых этим приложением? Были ли причины для использования стольких небольших таблиц?

Я использую PHP для обработки большого количества данных. Если ваша схема имеет смысл, это также делает PHP-код более понятным. Если бы это был я, я бы не переключился на другой язык программирования, я бы придерживался того, что начал, пока не натолкнулся на реальное структурное ограничение языка; для меня переключение на Rails было бы пустой тратой времени.