SQL Design: нужна возможность добавлять пользовательские «столбцы» в таблицу с использованием фиксированной схемы - PullRequest
Новая
       1

SQL Design: нужна возможность добавлять пользовательские «столбцы» в таблицу с использованием фиксированной схемы

1 голос
/ 22 января 2011

Использование : SQL Server 2008, Entity Framework, WCF 4 REST

У меня есть таблица для хранения данных измерений, сгенерированных системой мониторинга (приложение). В настоящее время в приложении отслеживается около 10 различных известных фрагментов данных, и каждый соответствует столбцу в таблице. Каждый клиент может «настроить» каждое из своих приложений для сбора от 1 до 10 фрагментов данных - им нужно собрать только те фрагменты информации, которые они заинтересованы в анализе. Все работает отлично (и производительность хорошая) с этой простой фиксированной схемой. Эта схема рассчитана на мультитенантность, поэтому несколько приложений от нескольких клиентов в разных местах могут перекачивать данные в одну и ту же БД - миллионы и миллионы строк данных измерений (я не удивлюсь, если мы перейдем в Azure и раньше длинный) *. * 1005

Теперь мне сказали, что приложение для измерений скоро сможет отслеживать дополнительные «вещи». Этот новый список (на данный момент, как мне сказали, составляет около 150 пунктов) может составить около 1000 единиц измерения. Кроме того, пользователь может указать свои собственные критерии для элементов, которые нужно отслеживать / измерять (т. Е. Пользовательские измерения, равные пользовательским столбцам). Хорошая новость заключается в том, что все данные измерений будут целыми числами.

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

Любая помощь приветствуется.

Текущая схема: 

CREATE TABLE MeasurementData (
    DataId bigint IDENTITY(1,1) NOT NULL PRIMARY KEY,
    ApplicationId int NOT NULL,    -- FK to Application table
    DateCollected datetime NOT NULL,
    Length int NULL,
    Width int NULL,
    Height int NULL,
    Color int NULL,
    Shape int NULL,
    Mass int NULL
)
CREATE TABLE Application (
    ApplicationId int IDENTITY(1,1) NOT NULL PRIMARY KEY,
    CompanyId int NOT NULL,    -- FK to Company table
    SerialNumber nvarchar(50) NOT NULL
)
CREATE TABLE Company (
    CompanyId int IDENTITY(1,1) NOT NULL PRIMARY KEY,
    CompanyName nvarchar(50) NOT NULL
)

И затем у нас есть таблица пользователей, таблица ролей и т. Д., Где есть отношения 1-n между компанией и пользователем.

К вашему сведению, веб-приложение затем представит данные в виде таблиц, графиков и т. Д. (Общение через уровень веб-службы REST) ​​

Ответы [ 2 ]

2 голосов
/ 22 января 2011

Можете ли вы добавить еще две таблицы? Один с типами измерений, а другой - с сопоставлением типа с самим измерением?

В основном таблица с {DataId, DataMeasurementTypeId, DataValue} и {DataMeasurementTypeId, DataMeasurementType}

Это должно позволить вам предоставить хранимые процедуры для извлечения всех данных в таблице.

Лучшим вариантом может быть решение этой проблемы с помощью таблицы «Имя», «Значение» и обеспечение того, чтобы уровень бизнес-объектов позаботился о создании правильного контента. Хотя это будет лучше подходить (и, скорее всего, будет работать) при использовании подхода BigTable в Google, чем в СУБД.

1 голос
/ 22 января 2011

Взгляните на следующие примеры SO: один , два , три .

...