外键引用表的结构
我有以下数据库设计问题：
我有一条记录包含以下信息：
主键由 3 列组成
一般信息详细信息（由 7 栏组成）
记录参数（每个参数有 2 列，但可以有 0 到 1500 个参数）
该记录的当前数据库设计是：
表A：
主键
一般信息详情
表 B：
主键（表A中的主记录）
序列号（主键和序列号共同构成表B的主键）
记录参数32列（这32或多或少是一个随机数）
我想知道的是这个设计是否真的有意义。实际上，当主记录有多个（可变数量）参数记录时，这个问题对于所有情况都是有意义的。
一方面，我们可以在表 B 中每行存储一个参数（这将涉及每个存储参数的平均存储空间 - 主键必须存储 n 次），另一方面，我们可以每行存储 x 个参数（更少每个存储参数的平均存储空间，但可能有一个随机数，小于 x 的空存储）。
希望我对我的问题足够清楚。知道什么是最好的解决方案吗？
I have the following database design question:
I have a record that contains the following information:
Primary key consisting of 3 columns
General information details (formed of 7 columns)
Record parameters (each parameter has 2 columns but there can be between 0 and 1500 parameters)
The current database design for this record is right now:
Table A:
Primary key
General information details
Table B:
Primary key (of main record in table A)
Sequence number (both Primary key and Sequence number make up the Primary Key of Table B)
Record paramters 32 columns (this 32 is more or less a random number)
The thing I am wondering about is if this design actualy makes sense at all. Actualy the question makes sense for all cases when we have several (variable number) parameter records for a main record.
On the one hand we could have in table B one parameter per line (this would involve more average storage space per stored parameter - primary key would have to be stored n times), on the other hand we could store x paramters per line (less average storage space per stored parameter but might have a random number, less than x of empty storage).
Hope I was clear enough about my problem. Any idea what would be the best solution for this?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
当你查询这些数据时，是否需要通过任何记录参数来过滤它？换句话说，任何记录参数是否会出现在 WHERE 子句中？
如果没有，那么您可以将它们存储在单个 Blob 列中，例如作为 XML 或任何最适合您的序列化。
When you query this data, do you need to filter it by any record parameters? In other words, would any of the record parameters appear in your WHERE clause?
If not, then you could just store them in a single Blob column, e.g. as XML or whatever serialization works best for you.