SQL таблица для каждого метаданных других таблиц

Question

Привет, у меня есть разные временные ряды, каждый из которых имеет уникальный идентификатор временного ряда. При наличии идентификатора серии выглядят примерно так (очевидно, с разными датами и данными соответственно)

datetime    data
1/1/1980    11.6985
1/2/1980    43.6431
1/3/1980    54.9089
1/4/1980    63.1225
1/5/1980    72.4399
1/6/1980    79.1363
1/7/1980    82.2778
1/8/1980    86.0785

Эти временные ряды имеют разные «типы». Например, предположим, что некоторые временные ряды относятся к типу «WindData», некоторые - к типу «SolarData», а некоторые - к типу «GasData». С учетом идентификатора временного ряда это будет принадлежать к какому-либо типу. Например:

• Идентификаторы 1, 2, 3 могут принадлежать SolarData
• ID 4,5 могут принадлежать Wind Data
• ID 6 может принадлежать GasData.

Временные ряды одного типа (для instanec 1, 2, 3) используют одни и те же поля метаданных (но не одинаковые значения!). Например, WindData может иметь поля:

• WindTurbineNumber, WindFarmName, Страна

в то время как SolarData может иметь поля:

• SiteName, SolarPanelType

и GasData может иметь:

• номер трубопровода, CountryOfOrigin, CountryOfDestination

Теперь, проблема в том, что со временем у меня может появиться еще много других типов. Поэтому мне нужен способ обобщения этой структуры метаданных данных. Как? Моя идея будет иметь:

• Таблица, в которой задан идентификатор временных рядов, сообщает тип этой серии (т. Е. Для 1 - SolarData)
• Таблица, в которой указан тип, она даст мне имена столбцов (и, необязательно, их типы)
• таблица, в которой указан идентификатор, он будет возвращать данные.

Какая структура базы данных мне понадобится?

Я не могу понять, как я мог бы создать таблицу (или несколько таблиц), которая могла бы сказать мне, учитывая seriesid, какие поля метаданных ему нужны ..

Answer 1

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

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

Тем не менее, звучит так, как будто вы хотите сохранить ваши данные в том виде, в котором вы их получили, какой бы ни была эта форма, а затем применить философию «Схема на чтение», извлекая полезные биты позже, в той форме, которую требует запрос. Для этого потребуется решение NoSQL или NewSQL. Для этого можно использовать любое количество устройств, от Hadoop и связанных с ним структур, таких как HBase (но не Hive), до CouchDB или Apache Cassandra.

Answer 2

Общий идеал идет так, как показано ниже. Вы должны быть своего рода таблицей серии и таблицей серии "папа", а также несколькими дочерними таблицами серии.

create table dbo.Seriekind
(
    Id int not null primrary key
   ,Description varchar(50) not null
   ,ListOfColumns varchar(500) not null
)

create table dbo.Series
(
   Id int not null indentity primary key
  ,TimeStamp datetime not null
  ,SerieKindId int not null
)

create table dbo.SolarData
(
     Id int not null primary key identity
    ,SerieId int not null
    ,SiteName
    ,SolarPanelType
)

create table dbo.WindData
(
     Id int not null primary key identity
    ,SerieId int not null
    ,WindTurbineNumber
    ,WindFarmName
    ,Country
)

create table dbo.GasData
(
     Id int not null primary key identity
    ,SerieId int not null
    ,PipelineNumber
    ,CountryOfOrigin
    ,CountryOfDestination
)

Для того, чтобы вы потеряли сознание, нужна новая таблица для любого нового типа данных. ФК тривиальны.

Редактировать

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

Лучшим решением может быть гибридное решение, возможно, хранение данных в виде гибкого формата, такого как json, в таблице Series или даже использование решения NoSql или гибрид SQL x NoSQL.

Главное здесь - сколько серий вам нужно и как часто могут появляться новые. Дюжина: SQl, Тысяча: NoSQL.