如何重构数据表以允许通过动态可添加/可删除因素进行查找?
今天早上我脑子一片空白,希望能从社区中得到一些想法。我的数据库中有一个需要重新建模的查找表 - 其基本示例是:
- Factor1
- Factor2
- Factor3
- Value
到目前为止这一切都很好,但业务现在决定用于查找值的因素应该是可变的由用户。
例如,他们可以添加一个具有可能值列表(即另一个表)的因子,并且可以将其合并到查找中,使用这种样式的表将需要添加一列,即因子4。
我的第一个想法是,我们不能授予用户在数据库中创建表、列、关系和索引的权限,这会带来太大的完整性风险,尽管这可能是最简单的情况。让设置新因子列的代码自动创建值表、生成关系、设置索引、修改查找存储过程等。但这一切似乎根本不是好的做法。
第二个想法是重新建模,以便将因子指定为表中的值,但今天早上,我对需要采取的方法一片空白,以便完成查找。首先,当我必须查找哪些因素决定哪个值时,如何完成查找...似乎我必须动态创建一个查询,但这似乎也不是喜欢走正确的路。
有什么想法吗?
假设我的(原始)表中有以下内容:
FactorValues
============
Factor1 | Factor2 | Factor3 | Value
-----------------------------------
1 1 1 0.5
1 1 2 1.0
1 1 3 1.5
1 2 1 2.0
1 2 2 2.5
1 2 3 3.0
我需要获得值 3.0(基于已知因素),这是小菜一碟
Select Value
From FactorValues
Where Factor1 = 1
And Factor2 = 2
And Factor3 = 3
现在,假设我已经重新建模到最终用户可以添加一个因素对于查找,我仍然需要能够根据以下语义提取值:
Select Value
From FactorValues
Where FirstUserDefinedFactor = FirstSelectedValue
And SecondUserDefinedFactor = SecondSelectedValue
And NthUserDefinedFactor = NthSelectedValue
因此,我的想法是我的值表将成为键/值查找,但我不确定如何对其进行建模那我可以基于多行而不是多列执行 where...
I'm having a brain freeze this morning and am hoping to bounce some ideas off the community. I have a lookup table in my database which I need to remodel - basic example of which is:
- Factor1
- Factor2
- Factor3
- Value
This has worked fine to this point but the business has now decided that the factors that go into looking up the value should be changeable by the user.
For instance, they may add a factor that has a list of possible values (i.e. another table), and that may be incorporated into the lookup, which with this style of table would require the addition of a column, i.e. Factor4.
My first thoughts are that we can't give users access to be able to create tables, columns, relationships and indexes in the database, that's just too much of an integrity risk, though this would probably be the most straightforward scenario. Have the code that sets up the new factor column automatically create the table of values, generate the relationships, set up the index, modify the lookup stored proc etc. But that all seems like it's just not good practice at all.
Second thought is remodel so that the factors are specified just as values in a table, but this morning, I'm drawing a blank as to the approach I need to take so the lookup can be completed. For a start, how do I complete a lookup when I have to look up which factors make up the decision on which value... it seems like I'm going to have to dynamically create a query, but that also doesn't seem like the right way to go.
Any ideas?
Let's say I have the following in my (original) table:
FactorValues
============
Factor1 | Factor2 | Factor3 | Value
-----------------------------------
1 1 1 0.5
1 1 2 1.0
1 1 3 1.5
1 2 1 2.0
1 2 2 2.5
1 2 3 3.0
I need to get value 3.0 (based on known factors), which is a cinch
Select Value
From FactorValues
Where Factor1 = 1
And Factor2 = 2
And Factor3 = 3
So now, let's say I've remodelled to the point that the end user could add a factor to the lookup, I still somehow need to be able to extract the values based on the semantics of:
Select Value
From FactorValues
Where FirstUserDefinedFactor = FirstSelectedValue
And SecondUserDefinedFactor = SecondSelectedValue
And NthUserDefinedFactor = NthSelectedValue
So the idea would be that my Value table would just become a key/value lookup, but I'm not sure how to model it so that I can do a where based on multiple rows instead of multiple columns...
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
我认为您想要的一些内容将取决于您为用户构建的界面,但我认为界面直观地会受到设计的限制,所以这里是:
列出的数据类型当然是假设的,可以适当更改根据您的场景
创建一个表格,其中包含您希望用户可用的所有因素,或者您希望他们能够自行输入的因素:
创建另一组表格来建立因素组,以便您的用户可以输入多个作为单个条目:
现在,假设您的值是预设的并且您不希望它们更改,您还需要一个表格来存储它们:
否则,我认为您可以只粘贴
ValueFactorGroup
表中的 code> 字段。最后,一个将因子组与值相匹配的表:
我认为您需要的查询可能类似于:
Some of what I think you want will be dependent on the interface you build for your users, but I think the interface will intuitively be constrained by the design, so here goes:
data types listed are hypothetical of course, change as appropriate to your scenario
Create one table of all the factors you want available to your users, or that you want them to be able to enter themselves:
Create another set of tables that will establish groups of factors, so your users can enter more than one as a single entry:
Now, assuming your values are preset and you don't want them to change, you need a table for them as well:
Otherwise, I would think you could just stick the
Value
field in theFactorGroup
table.Lastly, a table to match factor groups with the values:
The query I think you'd need would probably be something like:
如果我正确理解了问题的要点,那么您需要设计一些可以捕获以下概念的东西:
其中
f
是某种函数,X
是某种 n - 因素元组,y 是结果值。 ([i]
表示下标 i。)假设
f
不会改变,那么至少两个表的方法可能会起作用。Expression-Id
表示一种特定的关系,即下标i。结果值
是y
。Factor-Index
仅指示哪个因子(1=Factor1、2=Factor2、3=Factor3 等)具有给定的Factor-Value
。Expression-Id
上的Inner Join
可以将两个表连接在一起。希望这有帮助!
或者采用单表方法,保留表 A 但删除表 B。使用
Factor-Index
=0 来表示 y。If I'm getting the gist of the problem right, you want to devise something that can capture the notion of:
Where
f
is some sort of function,X
is some n-tuple of factors, and y is the resultant value. (The[i]
means subscript i.)Assuming that
f
isn't going to change, then perhaps at minimum a two table approach may work.Expression-Id
indicates a particular relationship, i.e. the subscript i.Result-Value
is they
.Factor-Index
simply indicates which factor (1=Factor1, 2=Factor2, 3=Factor3, etc.) has the givenFactor-Value
.An
Inner Join
onExpression-Id
can knit the two tables together.Hope this helps!
Or a one table approach, keeping Table A but dropping Table B. Use
Factor-Index
=0 to mean the y instead.