一桌还是三桌？ [英] One table or three?
问题描述
上下文：（vb6 / ado / .mdb / jet4.0 /不使用访问权限）
假设问题
说我需要跟踪属性盒子。
有三种，纸板，木头和钣金。
每个盒子有一些共同的属性，宽度，深度，高度
所以一个表有意义存储.... tblBoxes
但是...每个盒子类型也有只适用于那个的属性类型...
纸板...纤维含量，IsRecycledBool等
木材......种类等
金属.... gageSize，IsGalvanizedBool等
所以，如果我有一个表，每个条目将有很多空值用于
属性申请，
和调用代码将有一些分支代码来决定要查询的是什么
属性???
或者我应该有3个表tblCardboardBox，tblWoodBox，tblMetalBox
那么调用代码仍然需要分支代码t o决定查询什么表
查询但是没有一堆空值...
是否有任何参数*反对*大量的空值不适用
字段？
是否更容易使分支代码访问不同的字段？
不同的表格？
有什么建议吗？
谢谢
马克
每个MP：< blockquote class =post_quotes>有三种，纸板，木材和钣金。
每个盒子都有一些共同的属性，宽度，深度，高度
所以一个表有意义存储.... tblBoxes
但...每个盒子类型也有适用于那种类型的属性...
纸板...纤维内容，IsRecycledBool等等......木材......种类等等金属.... gageSize，IsGalvanizedBool等
所以如果我有一个表，每个条目都会有很多空值不适用的
属性，
和callin g代码将有某种分支代码来决定查询什么属性
或者我应该有3个表tblCardboardBox，tblWoodBox，tblMetalBox
或者甚至可能是4个表：
tblBox，其中包含常见信息和三个RecordID字段 - 只有一个
填充 - 并指向：tblCardboardBox，tblWoodBox，或
tblMetalBox。
这样，您可以使用tblBox中的三个连接进行查询并选择任何
相关，获得没有子rec的表的Null值。
-
PeteCresswell
< br>
（PeteCresswell）写道：每个MP：
有三种，纸板，木材和钣金。
每个盒子都有一些共同的属性，宽度，深度，高度
所以一个表有意义存储.... tblBoxes
但是...每个盒子类型也有pr只适用于那种类型的笨蛋...
纸板......纤维含量，IsRecycledBool等等......木材......种类等金属.... gageSize， IsGalvanizedBool等
所以，如果我有一个表，每个条目将有很多空值用于不适用的
属性，
并且调用代码将有一些一种分支代码来决定查询什么属性
或者我应该有3个表tblCardboardBox，tblWoodBox，tblMetalBox
或者也许甚至4个表：
tblBox，它包含常见信息和三个RecordID字段 - 只有一个填充的
- 并指向：tblCardboardBox，tblWoodBox或
tblMetalBox。 br />
这样，您可以使用tblBox中的三个连接进行查询，并获取相关的任何内容，获取没有子rec的表的Null值。
我会建议记录ID，类型（纸板，木头或金属）和
普通fi在一个表格中的字段，记录ID和其他三个表格中的专有字段。
Stevel
Per Stevel：我建议记录ID，类型（Cardboard，Wood或Metal）和一个表中的
公共字段，记录ID和专有权其他三个表中的字段。
但他如何同时加入其他三个表？好像
会在加入之前引入一些逻辑。
-
PeteCresswell
context: (vb6 / ado / .mdb / jet4.0 / not using access)
hypothetical problem
say I need to track the properties of boxes.
There are three kinds, cardboard, wood, and sheet metal.
Each box has some common properties, width, depth, height
So one table makes sense to store that....tblBoxes
but...each box type also has properties that only apply to that type...
cardboard...fiber content, IsRecycledBool, etc
wood...species, etc
metal....gageSize, IsGalvanizedBool, etc
so if I have one table, each entry will have lots of nulls for the
properties that don''t apply,
and the calling code will have some kind of branching code to decide what
properties to query???
or should I have 3 tables tblCardboardBox, tblWoodBox, tblMetalBox
then the calling code still needs branching code to decide what table to
query but there aren''t a bunch of nulls...
is there any argument *against* lots of null values for "not applicable"
fields?
is it easier to make branching code to access different fields versus
different tables?
any suggestions?
Thanks
Mark
Per MP:There are three kinds, cardboard, wood, and sheet metal.
Each box has some common properties, width, depth, height
So one table makes sense to store that....tblBoxes
but...each box type also has properties that only apply to that type...
cardboard...fiber content, IsRecycledBool, etc
wood...species, etc
metal....gageSize, IsGalvanizedBool, etc
so if I have one table, each entry will have lots of nulls for the
properties that don''t apply,
and the calling code will have some kind of branching code to decide what
properties to query???
or should I have 3 tables tblCardboardBox, tblWoodBox, tblMetalBox
Or maybe even 4 tables:
tblBox, which contains common info plus three RecordID fields - only one of
which is populated - and points to: tblCardboardBox, tblWoodBox, or
tblMetalBox.
That way, you can query with three joins from tblBox and pick up whatever is
relevant, getting Null values for the tables in which there is no child rec.
--
PeteCresswell
(PeteCresswell) wrote:Per MP:There are three kinds, cardboard, wood, and sheet metal.
Each box has some common properties, width, depth, height
So one table makes sense to store that....tblBoxes
but...each box type also has properties that only apply to that type...
cardboard...fiber content, IsRecycledBool, etc
wood...species, etc
metal....gageSize, IsGalvanizedBool, etc
so if I have one table, each entry will have lots of nulls for the
properties that don''t apply,
and the calling code will have some kind of branching code to decide what
properties to query???
or should I have 3 tables tblCardboardBox, tblWoodBox, tblMetalBox
Or maybe even 4 tables:
tblBox, which contains common info plus three RecordID fields - only one of
which is populated - and points to: tblCardboardBox, tblWoodBox, or
tblMetalBox.
That way, you can query with three joins from tblBox and pick up whatever is
relevant, getting Null values for the tables in which there is no child rec.
I''d suggest a record ID, the type (Cardboard, Wood or Metal) and the
common fields in one table, the record ID and the proprietary fields in
three other tables.
Stevel
Per Stevel:I''d suggest a record ID, the type (Cardboard, Wood or Metal) and the
common fields in one table, the record ID and the proprietary fields in
three other tables.
But how would he join to the other three tables simultaneously? Seems like
that would introduce the need for some logic before doing the join.
--
PeteCresswell
这篇关于一桌还是三桌？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
