存储文本值而不是用于清除用户的ID [英] Storing Text Values Instead of ID's for the Sake of Users

问题描述

大家好。我正在创建一个将由大约6个用户使用的FE / BE数据库。通常情况下，我有几个字段，例如OrganizationTypeID和OrganizationTypeID。这将从单独的查找表中获得

值（通过表单中的组合框）。我知道

''正确''的方法，使用长整数作为字段类型。然而，在这个

的情况下，我正在考虑通过实际存储

我的字段中的文本而不是ID，仍然使用查找表来错误地执行此操作，但

加入文本并使用级联更新。我正在考虑这个

，因为用户想要创建他们自己的查询和报告，

如果他们不这样做可能会让他们感到困惑必须一直加入

查询表。在我看来，主要的缺点是额外的存储要求（每个字符1个字节，每个长度4个字节）和数据传输速度。我想我可以处理完整性问题，但我之前没有尝试过这个问题。


我要求看看如果任何有经验的开发人员做了同样的事情

并且结果不错，或者如果有人有反对它的想法那我就没想过

of。

（我是一位非常有经验的Access开发者）


谢谢

-John

Hi all. I''m creating a FE/BE database that will be used by about 6 users. As
usual, I have several fields, such as "OrganizationTypeID" that will get
values (via combo boxes in forms) from separate lookup tables. I know the
''correct'' way to do this, using a long integer as the field type. In this
case, however, I am considering doing it "incorrectly", by actually storing
the text in my field rather than an ID, still using a lookup table, but
joining on the text and using cascading updates. I''m considering this
because the users are going to want to create their own queries and reports,
and it might be less confusing for them if they don''t have to join to the
lookup tables all the time. It seems to me that the main disadvantages will
be the extra storage requirements (1 byte per character vs. 4 bytes per long
int) and the speed of data transfer. I think I can deal with integrity
issues with the cascading updates, but I haven''t tried this before.

I''m asking to see if any experienced developers have done this same thing
with ok results, or if anyone has ideas against it that I haven''t thought
of.
(I''m a pretty experienced Access developer)

thanks
-John

推荐答案

我的经验是，查找字段仅对在数据表视图中显示

数据的最终用户有用。在任何其他情况下，他们比新手/休闲最终用户更有价值。对于IMNSHO，你会更好地用一个包含

外键的字段替换查找字段，并为用户提供一些关于查询和连接的免费培训。如果你捐出正常支付的咨询时间，它甚至可以支付给你b / b
，当你不经常接到混淆的电话时用户。


也就是说，可以重新定义查找字段，以便它们显示

来执行您描述的操作。但要注意用户开始创建的那一天

桌面上的查询 - 这将是折叠帐篷的好时机

并被偷走到深夜。< ; GRIN>


Larry Linson

Microsoft Access MVP


" John Welch" <约翰（删除）韦尔奇@ CAL（删除）central.com>在消息中写道

news：dv ******** @ enews2.newsguy.com ...

My experience is that lookup fields are ONLY useful for end-users displaying
data in datasheet view. In any other circumstance, they are more trouble
than they ever were worth to that novice/casual end user. IMNSHO, you will
be far better off to replace the Lookup Fields with a field containing the
Foreign Key and give the users some free training on Queries and Joins. Even
if you donate normally-paid consulting time, it''ll pay you back in the long
run, when you aren''t regularly getting phone calls from confused users.

That said, it is possible to redefine the Lookup Fields so that they appear
to do what you describe. But beware the day that users start to create
Queries on the Table -- that will be a good time to have folded your tent
and stolen away into the night.<GRIN>

Larry Linson
Microsoft Access MVP

"John Welch" <john(remove)welch@cal(remove)central.com> wrote in message
news:dv********@enews2.newsguy.com...

大家好。我正在创建一个将被大约6个用户使用的FE / BE数据库。
像往常一样，我有几个字段，例如OrganizationTypeID和OrganizationTypeID。这将从单独的查找表中获取值（通过表单中的组合框）。我知道使用长整数作为字段类型的''正确''方法。然而，在这种情况下，我正在考虑错误地执行它，实际上将文本存储在我的字段中而不是ID，仍然使用查找表，但加入文本和使用级联更新。我在考虑这个因为用户想要创建他们自己的查询和报告，如果他们不必加入它们可能会让他们感到困惑一直到查找表。在我看来，主要的缺点是额外的存储要求（每个字符1个字节，每个长字4个字节）和数据传输速度。我认为我可以通过级联更新处理完整性问题，但我之前没有尝试过。

我要问看看是否有经验丰富的开发人员做了同样的事情
好结果，或者如果有人有反对它的想法，我没想到
。
（我是一位非常有经验的Access开发人员）
谢谢
-John

Hi all. I''m creating a FE/BE database that will be used by about 6 users.
As usual, I have several fields, such as "OrganizationTypeID" that will
get values (via combo boxes in forms) from separate lookup tables. I know
the ''correct'' way to do this, using a long integer as the field type. In
this case, however, I am considering doing it "incorrectly", by actually
storing the text in my field rather than an ID, still using a lookup
table, but joining on the text and using cascading updates. I''m
considering this because the users are going to want to create their own
queries and reports, and it might be less confusing for them if they don''t
have to join to the lookup tables all the time. It seems to me that the
main disadvantages will be the extra storage requirements (1 byte per
character vs. 4 bytes per long int) and the speed of data transfer. I
think I can deal with integrity issues with the cascading updates, but I
haven''t tried this before.

I''m asking to see if any experienced developers have done this same thing
with ok results, or if anyone has ideas against it that I haven''t thought
of.
(I''m a pretty experienced Access developer)

thanks
-John

谢谢Larry。我不知道我们是否在谈论同样的事情。

我想不到使用查找字段。在使用Access''

的意义上混淆内置的东西，其中字段存储数字但显示文本。

我正在考虑让字段实际存储文本并且文本是

查找表的外键，其中包含文本作为主键。


例如：

tblOrganizations：

OrgID：autonum

OrgName：text

OrgType（fk）：text（foundation，household，corporation，etc 。）


tblOrgTypes：

OrgType（pk）：文字（基础，家庭，公司等）


加入级联更新

-John

" Larry Linson" <博***** @ localhost.not>在消息中写道

news：j4JSf.2986

Thanks Larry. I can''t tell if we''re talking about the same thing, though.
I''m _not_ thinking of using "lookup fields" in the sense of using Access''
confusing built in thing where the field stores a number but displays text.
I''m thinking of having the field actually store text and having the text be
the foreign key to the lookup table which has text as it''s primary key.

For example:
tblOrganizations:
OrgID: autonum
OrgName: text
OrgType (fk): text (foundation, household, corporation, etc.)

tblOrgTypes:
OrgType (pk): text (foundation, household, corporation, etc.)

join with cascading updates
-John
"Larry Linson" <bo*****@localhost.not> wrote in message
news:j4JSf.2986

TK2.1012@trnddc07 ...

TK2.1012@trnddc07...

我的经验是查找字段是仅对最终用户有用
在数据表视图中显示数据。在任何其他情况下，他们比新手/休闲最终用户更有价值。
IMNSHO，你将更好地用
字段替换查找字段包含外键并为用户提供有关查询和联接的免费培训。即使您捐赠了正常支付的咨询时间，但从长远来看，当您不经常收到来自困惑用户的电话打电话时，它会给您回报。
< Larry Linson
Microsoft Access MVP

John Welch <约翰（删除）韦尔奇@ CAL（删除）central.com>在消息中写道
新闻：dv ******** @ enews2.newsguy.com ...

My experience is that lookup fields are ONLY useful for end-users
displaying data in datasheet view. In any other circumstance, they are
more trouble than they ever were worth to that novice/casual end user.
IMNSHO, you will be far better off to replace the Lookup Fields with a
field containing the Foreign Key and give the users some free training on
Queries and Joins. Even if you donate normally-paid consulting time, it''ll
pay you back in the long run, when you aren''t regularly getting phone
calls from confused users.

That said, it is possible to redefine the Lookup Fields so that they
appear to do what you describe. But beware the day that users start to
create Queries on the Table -- that will be a good time to have folded
your tent and stolen away into the night.<GRIN>

Larry Linson
Microsoft Access MVP

"John Welch" <john(remove)welch@cal(remove)central.com> wrote in message
news:dv********@enews2.newsguy.com...

大家好。我正在创建一个将被大约6个用户使用的FE / BE数据库。
像往常一样，我有几个字段，例如OrganizationTypeID和OrganizationTypeID。这将从单独的查找表中获取值（通过表单中的组合框）。我知道使用长整数作为字段类型的''正确''方法。然而，在这种情况下，我正在考虑错误地执行它，实际上将文本存储在我的字段中而不是ID，仍然使用查找表，但加入文本和使用级联更新。我在考虑这个因为用户想要创建他们自己的查询和报告，如果他们不需要加入它们可能会让他们感到困惑一直到查找表。在我看来，主要的缺点是额外的存储要求（每个字符1个字节，每个长整数4个字节）和数据传输速度。我认为我可以通过级联更新处理完整性问题，但我之前没有尝试过。

我要问看看是否有经验丰富的开发人员做了同样的事情
好结果，或者如果有人有反对它的想法，我没想到
。
（我是一位非常有经验的Access开发人员）
感谢
-John

Hi all. I''m creating a FE/BE database that will be used by about 6 users.
As usual, I have several fields, such as "OrganizationTypeID" that will
get values (via combo boxes in forms) from separate lookup tables. I know
the ''correct'' way to do this, using a long integer as the field type. In
this case, however, I am considering doing it "incorrectly", by actually
storing the text in my field rather than an ID, still using a lookup
table, but joining on the text and using cascading updates. I''m
considering this because the users are going to want to create their own
queries and reports, and it might be less confusing for them if they
don''t have to join to the lookup tables all the time. It seems to me that
the main disadvantages will be the extra storage requirements (1 byte per
character vs. 4 bytes per long int) and the speed of data transfer. I
think I can deal with integrity issues with the cascading updates, but I
haven''t tried this before.

I''m asking to see if any experienced developers have done this same thing
with ok results, or if anyone has ideas against it that I haven''t thought
of.
(I''m a pretty experienced Access developer)

thanks
-John

这篇关于存储文本值而不是用于清除用户的ID的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！