SQL 设计:需要能够添加自定义“列”使用固定模式的表
使用:SQL Server 2008、Entity Framework、WCF 4 REST
我有一个表,用于保存监控系统(也称为应用程序)生成的测量数据。目前,该应用程序内正在监控大约 10 个不同的众所周知的数据,每个数据都对应于表中的一列。每个客户都可以“定制”他们的每个应用程序以捕获 1 到 10 条数据 - 他们只需要捕获他们有兴趣分析的那些信息。通过这种简单的固定模式,一切都运行良好(并且性能良好)。此架构设计为多租户,因此多个位置的多个客户的多个应用程序可以将数据注入同一个数据库 - 数以百万计的测量数据行(如果我们之前也使用 Azure,我不会感到惊讶)长的)。
我现在被告知测量应用程序很快就能够监控其他“事物”。这份新清单(据我所知大约有 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 关系。
仅供参考,Web 应用程序随后将通过表格、图表等呈现数据(通过 REST Web 服务层进行通信)
Using: SQL Server 2008, Entity Framework, WCF 4 REST
I have a table for holding the measurement data generated by monitoring system (aka the app). There are currently about 10 different well-known pieces of data being monitored within the app - and each corresponds to a column in the table. Each customer can "customize" each of their apps to capture from 1 to 10 pieces of data - they only need to capture those pieces of info they are interested in analyzing. Everything's working great (and performance is good) with this straight-forward fixed schema. This schema is designed to be multi-tenant, so multiple applications across multiple customers in multiple locations could be pumping data into the same DB - millions and millions of rows of measurement data (I wouldn't be surprised if we go to Azure before too long).
I have now been told that the measurement application will soon be able to monitor additional "things". This new list (so far I'm told is at around 150 items) could wind up being about 1000 items being measured. Add on top of that, the user could specify their own criteria for items to monitor/measure (i.e. custom measurements equating to custom columns.) The good news is that all the measurement data will be integers.
Now the fun - how do I design the schema for this situation? I would really like to keep the schema fixed. I would also like to keep it as performant as possible given the high volumes of data.
Any help is appreciated.
Current Schema:
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
)
And then we have the user table, the roles table, etc, where there's a 1-n relationship btw company and user.
FYI, the web app will then present the data with tables, graphs, etc (communicating via the REST web service layer)
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
可以再添加两张桌子吗?一个包含测量类型,另一个包含从类型到测量本身的映射?
基本上是一个包含 {DataId, DataMeasurementTypeId, DataValue} 和 {DataMeasurementTypeId, DataMeasurementType} 的表,
它应该允许您提供存储过程来检索表中的所有 Datameasurement。
更好的选择可能是使用名称、值表来解决它,并让业务对象层负责构建正确的内容。不过,与 RDBMS 相比,这更适合(并且可能执行)Google 的 BigTable 方法。
Can you add two more tables? One with the types of measurements and the other with a mapping from the type to the measurement itself?
Basically A table with {DataId, DataMeasurementTypeId, DataValue} and {DataMeasurementTypeId, DataMeasurementType}
That should allow you to provide stored procedures to retrieve all Datameasurements in a table.
The better optiom might be to solve it with a Name,Value table and have the business object layer take care of constructing the right content.. That would fit (and likely perform) better with BigTable approach of Google than RDBMS though.
看看这些示例:一个,两个,三个。
Take a look at these SO examples: one, two, three.