如何构造（规范化）数据库的物理参数？ [英] How to structure (normalize?) a database of physical parameters?

问题描述

我有一个与不同项目相关联的物理参数的集合。例如：

 项目，p1，p2，p3 
a，1，2，3 
b，4 ，5，6 
 [...] 
  

其中 px 代表参数 x 。

我可以继续存储数据库呈现;该模式将是

  CREATE TABLE t1（item TEXT PRIMARY KEY，p1 FLOAT，p2 FLOAT，p3 FLOAT）; 
  

我可以为所有人检索参数 p1 带有声明的项目：

  SELECT p1 FROM t1; 
  

另一种替代方法是具有如下所示的模式：

  CREATE TABLE t1（id INT PRIMARY KEY，item TEXT，par TEXT，val FLOAT）
  

如果你有很多参数（像我一样），这看起来要简单得多。但是，参数检索似乎非常尴尬：

  SELECT val FROM t1 WHERE par =='p1'
  

你有什么建议？应该去枢轴（第一个）版本或 id，par，val （第二个）版本？

非常感谢

编辑

为了参考，我发现以下持久性模式在<一个href =http://www.sqlalchemy.org/trac/browser/examples/vertical/dictlike.py =nofollow noreferrer> SQLAlchemy示例站点（垂直映射）：

 将垂直表映射为字典
 
此示例说明访问和修改vertical（或
属性或者枢轴的表，这些表是
，用于将free-form对象属性存储为行而不是列。对于
示例，而不是： ：
 
＃一个常规（水平）表中有'species'和'size'的列
表（'animal'，元数据，
列（'id'整数，primary_key = True），
列（'species'，Unicode），
列（'size'，Unicode））
 
一个垂直表将它建模为两个表：一个表为基数或父
实体，另一个相关表保存键/值对:: 
 
表（'animal'，元数据，
列（'id'整数，primary_key = True））
 
＃属性表将为物种值有一行，而
＃为size值的另一行。 
表（'属性'，元数据
列（'animal_id'，整数，ForeignKey（'animal.id'），
 primary_key = True），
列（' ，UnicodeText），
列（'value'，UnicodeText））
 
因为垂直方案中的键/值对不提前固定，所以
像Python一样访问它们dict可以很方便。下面的例子
可以与许多常见的垂直模式一起使用，或者进行微调。 
 

  

解决方案

除了第二种方法的灵活性之外，另一个优点是参数可以是参数表中的行，将关于该参数的数据存储为数据库的一部分，而不是作为模式的列，也自然地导致RDF三重表示数据。

BTW您不需要添加的键字段，使项目和参数联合主键

  CREATE TABLE t1（item TEXT，par TEXT，val FLOAT，PRIMARY KEY（item，par））
  

第二种方法的一个限制是所有参数的值的数据类型必须相同 - 如果所有的浮点数都是一般的，那么这可能必须是带有服务器的字符串查询速度将受到影响，但是您可以获得一个包含如

等查询的术语的所有参数。

  SELECT par，value FROM t1 WHERE item ='qitem'
  

更容易转换为替代方案的演示格式。

I have a collection of physical parameters associated with different items. For example:

Item, p1, p2, p3
a,     1,  2,  3
b,     4,  5,  6
[...]

where px stands for parameter x.

I could go ahead and store the database exactly as presented; the schema would be

CREATE TABLE t1 (item TEXT PRIMARY KEY, p1 FLOAT, p2 FLOAT, p3 FLOAT);

I could retrieve the parameter p1 for all the items with the statement:

SELECT p1 FROM t1;

A second alternative is to have an schema like:

CREATE TABLE t1 (id INT PRIMARY KEY, item TEXT, par TEXT, val FLOAT)

This seems much simpler if you have many parameters (as I do). However, the parameter retrieval seems very awkward:

SELECT val FROM t1 WHERE par == 'p1'

What do you advice? Should go for the "pivoted" (first) version or the id, par, val (second) version?

Many thanks.

EDIT

For reference, I found the following persistence pattern in the SQLAlchemy examples site (the vertical mapping):

"""Mapping a vertical table as a dictionary.

This example illustrates accessing and modifying a "vertical" (or
"properties", or pivoted) table via a dict-like interface.  These are tables
that store free-form object properties as rows instead of columns.  For
example, instead of::

  # A regular ("horizontal") table has columns for 'species' and 'size'
  Table('animal', metadata,
        Column('id', Integer, primary_key=True),
        Column('species', Unicode),
        Column('size', Unicode))

A vertical table models this as two tables: one table for the base or parent
entity, and another related table holding key/value pairs::

  Table('animal', metadata,
        Column('id', Integer, primary_key=True))

  # The properties table will have one row for a 'species' value, and
  # another row for the 'size' value.
  Table('properties', metadata
        Column('animal_id', Integer, ForeignKey('animal.id'),
               primary_key=True),
        Column('key', UnicodeText),
        Column('value', UnicodeText))

Because the key/value pairs in a vertical scheme are not fixed in advance,
accessing them like a Python dict can be very convenient.  The example below
can be used with many common vertical schemas as-is or with minor adaptations.

"""

解决方案

In addition to the flexibility of the second approach, a further advantage is that parameters can then be rows in a parameter table, storing data about that parameter as part of the database, rather than as columns of the schema. It also leads naturally to an RDF triple representation of the data.

BTW you don't need the added key field, make item and par a joint primary key

CREATE TABLE t1 ( item TEXT, par TEXT, val FLOAT, PRIMARY KEY (item, par))

One limitation of the second approach is that the datatype of value must be the same for all parameters - OK if all floats but for generality this might have to be string with attendant loss of validation and the need for programatic data conversion.

Query speed will be affected, but you can get all the parameters for a term with a query like

SELECT par,value FROM t1 WHERE item='qitem'

which is easier to transform to a presentation format than the alternative.

这篇关于如何构造（规范化）数据库的物理参数？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！