Динамическое хранилище значений ввода данных - PullRequest
0 голосов
/ 29 мая 2010

Я создаю приложение для ввода данных, где пользователям разрешено создавать схему ввода.

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

Я не совсем доволен этим решением; Единственный положительный момент - это простота ... Я могу хранить только фиксированное количество столбцов. Мне нужно создать индексы по всем столбцам. Мне нужно пересоздать таблицу изменений схемы.

Вот некоторые из моих ключевых критериев проектирования:

  • Очень быстрые запросы (с использованием простого предметно-ориентированного языка запросов)
  • Пишет не обязательно быстро
  • Много одновременных пользователей
  • Схемы будут часто меняться
  • Схемы могут содержать много тысяч столбцов
  • Записи данных могут быть распределены и требуют синхронизации.
  • Предпочтительный MySQL и SQLite - о таких базах, как DB2 и Oracle, не может быть и речи.
  • Использование .Net / Mono

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

Решение 1. Объединяющая таблица, содержащая столбец типа и один обнуляемый столбец на тип.

Это позволяет избежать объединений, но определенно займет много места.

Решение 2: Хранилище ключей / значений. Все значения сохраняются в виде строки и конвертируются при необходимости.

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

Решение 3. Используйте базу данных xml или сохраните значения как xml.

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

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

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

PSPP имеет большую часть логики, о которой я думаю; простые типы столбцов, много столбцов, много строк, быстрые запросы и слияние. Жаль, что он не работает с базой данных ... И, конечно ... Мне не нужны 99% предоставляемых функций, но многие вещи не включены.

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

Заранее спасибо!

1 Ответ

0 голосов
/ 29 мая 2010

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

DATASET Table (Virtual "table")
ID - primary key
Name - Name for the dataset/table

COLUMNSCHEMA Table (specifies the columns for one "dataset")
DATASETID - int (reference to Dataset-table)
COLID - smallint (unique # of the column)
Name - varchar
DataType - ("varchar", "int", whatever)

Row Table 
DATASETID
ID - Unique id for the "row"

ColumnData Table (one for each datatype)
ROWID - int (reference to Row-table)
COLID - smallint
DATA - (varchar/int/whatever)

Чтобы запросить набор данных (виртуальную таблицу), вы должны затем динамически создать инструкцию SQL, используя информацию схемы в таблице COLUMNSCHEMA.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...