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

Сначала позвольте мне описать мою ситуацию, чтобы вы могли помочь мне лучше. Есть две части.

1: У меня есть программа, которая запускает и анализирует кучу файлов. Он генерирует "отчет", который позже будет загружаться на веб-сайт для хранения и просмотра БД. Этот отчет может содержать практически любой тип данных, так как пользователи могут запрашивать почти что угодно. Я оставил его очень открытым.

2: Веб-сайт анализирует этот отчет, добавляет запись для вещей, которые являются общими. Но также создает новую таблицу для любых новых данных, которые она находит. Он также сохраняет сопоставление от report_id ко всем этим динамически созданным таблицам. Например, если в отчете кто-то хотел рассчитать стандартное отклонение, и это имело смысл для этого отчета, чем была бы таблица STD.

Прямо сейчас этот сайт написан на PHP, и выглядит немного грязным. Есть ли лучший способ сделать этот PHP. Кроме того, я рассматриваю переработку этого в Rails, потому что организация ради. Есть ли лучший способ в рельсах "method_missing?".

Я не очень разбираюсь в создании сайтов и дилетантских в БД, поэтому, пожалуйста, будьте добрыми.

Спасибо Эрик

Ответ 1

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

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

monitoring_model_01

Ответ 2

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

Ответ 3

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