中的元数据结构？数据库
我想以可查询的格式存储数据，而不提前知道给定的数据包将包含哪些字段。
简单/愚蠢的方法似乎类似于一个大的键值对表，其中的键返回到数据描述的“父”对象表。
数据将具有以下属性：
- 许多“元数据”将与单个父对象关联
- 数据将始终采用键值对形式 数据
- 不会是分层的（仅一级键值对）
- 将有很多。从来没有净化过。如果需要，移动到重复的存档存储
例如
解析日志文件，并根据以下规则将其消息提取为某种定义的格式：
- 日志/系统名称
- 位置
- 日期
- 时间
- 级别
- 留言
可能会为许多不同的系统解析许多日志。每个系统可能有不同的字段。
日期/时间/级别/消息字段仅在创建解析文件的规则时才知道，而不是在构建数据存储时才知道。
你会怎么做呢？您会使用什么样的数据库/设计？
I would like to store data in a queryable format without knowing ahead of time what fields a given packet of data will contain.
The simple/dumb approach seems to be something like a big key-value pair table with a key back to a table of 'parent' objects which the data describes.
The data will have the following properties:
- Many pieces of 'metadata' will be associated to a single parent object
- The data will always be in key-value pair form
- The data will not be heirachical (one level of key value pairs only)
- There will be lots of it. Never purged. Moved to duplicate archive stores if required
For example
A log file is parsed and it's messages pulled into some defined format based on some rules as follows:
- Log/System Name
- Location
- Date
- Time
- Level
- Message
There may be many logs parsed for many different systems. Each system may have different fields.
The Date/Time/Level/Message fields are only known when the rules for parsing the file are created, not when the data store is being built.
How would you go about this? What kind of database/design would you use?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
选项 1：使用 NoSQL 数据库之一，例如 MongoDB - 我对这些数据库并不熟悉，因为我生活在一个主要使用 SQL Server 的世界中。这些允许您拥有文档形式的记录，而不是像关系数据库的
选项 2 那样的静态列数：关系数据库
表：日志 {Id (PK)、日期、时间、级别、消息}
表：ExtraFields {Id (PK), FieldName}
表：AdditionalFields {FieldId (PK), LogId (PK), Value}
这里每条记录都会得到一条日志记录，然后是AdditionalFields 中的一些附加字段，这些字段链接回LogId。然后您可以将它们加载到 Log 对象中。 ExtraFields 表将包含所有类型的字段。如果加载一条记录时该记录不存在，则添加另一条记录。因此，如果它是网络日志，则可能包含 URL、IP、用户代理等。
或者，您可以避免使用 ExtraFields 表，而只需将字段名称直接放入 ExtraFields 表中。
Option 1: Use one of the NoSQL databases like MongoDB - I'm not familiar with these as I live in a mostly SQL Server world. These allow you to have records that are documents, not static number of columns like relational DB's
Option 2: Relational DB
Table: Log {Id (PK), Date, Time, Level, Message}
Table: ExtraFields {Id (PK), FieldName}
Table: AdditionalFields {FieldId (PK), LogId (PK), Value}
Here each record would get a Log record, and then a number of additional fields in AdditionalFields, that link back to the LogId. You could then Load these into a Log object. The ExtraFields table would have all the types of fields. If it doesn't exist when you load a record, then you add another one. So this might have URL, IP, User-Agent etc if it was web logs.
Alternatively, you could avoid the ExtraFields table and just put the field name directly in the AdditionalFields table.