在大型数据库中，Memo字段应该转到自己的表吗？ [英] In large db's, should Memo fields go to their own table?

问题描述

这主要是一个速度问题。


在这个例子中：我有一个QuotesHdr表，它有一些备注字段。如果

这些备注字段被一些用户广泛使用，如果它们是QuotesHdr中的大量记录，我应该打破备忘录字段

进入一个单独的表？这里的想法是，对于报价选择

下拉列表显示QuotesHdr中的所有条目供选择，我认为

整个记录通过网络下降，以及那些使用

备忘录字段的人会注意到速度问题。


将备忘录字段分成一个是相当多的工作

分开，我想对此有一些看法。我认为打破

它们会影响数据不会通过网络传输

除非选择报价。


非常感谢，


Andy

This is mainly a speed question.

In this example: I have a QuotesHdr table that has a few memo fields. If
these memo fields are used extensively by some users, and if their are a
large number of records in QuotesHdr, should I break out the memo fields
into a separate table? The thinking here is that, for Quotes selection
dropdowns that display all entries in QuotesHdr for selection, I would think
that the entire record comes down over the network, and those who use the
memo fields would be the ones to notice speed issues.

It will be a fair amount of work to break out the memo fields into one
separate, and I''d like to have some opinions on this. I would think breaking
them out would have the affect of the data not coming down over the network
unless a quote is selected.

Many Thanks,

Andy

推荐答案

备注字段与表格分开存储你看到他们 -

这就是为什么有时他们更有问题的原因。比其他类型的

字段。


你究竟是什么意思通过网络下来？

如果你有一个前后分割，正确索引，并选择

索引字段（根据定义，它们不是Memo类型），那么只有
通过网络检索
索引以选择所需的记录，因此只有

与当前感兴趣的记录相关联的备注字段将降低

降低网络。


如果您在

连续视图表单中为用户显示整个表格或查询的数据要在前后端环境中进行选择，您需要重新检查应用程序的设计。


将备忘录字段分隔到另一个表中很可能不会像你想象的那样提供帮助。


Larry Linson

Microsoft Access MVP


ARC < an ** @ andyc.comwrote in message

news：eS **************** @ nlpi068.nbdc.sbc.com ...

Memo fields are stored separately from the table in which you "see" them --
that is why, at times, they have been more "problematic" than other types of
field.

What, exactly, do you mean by "come down over the network"?

If you have a split front and back end, properly indexed, and select by
indexed fields (which, by definition, are not Memo type), then only the
index is retrieved over the network to select the desired record, so only
the Memo fields associated with the current record of interest will "come
down over the network".

If you are displaying an entire table''s or query''s worth of data in a
continuous view form for the user to select in a front-back end environment,
you need to reexamine your application''s design.

Separating the memo fields into another table is likely not going to help as
much as you might think.

Larry Linson
Microsoft Access MVP

"ARC" <an**@andyc.comwrote in message
news:eS****************@nlpi068.nbdc.sbc.com...

这主要是一个速度问题。


在这个例子中：我有一个QuotesHdr表，里面有几个备注字段。如果

这些备注字段被一些用户广泛使用，如果它们是QuotesHdr中的大量记录，我应该打破备忘录字段

进入一个单独的表？这里的想法是，对于报价选择

下拉列表显示QuotesHdr中的所有条目以供选择，我会认为
认为整个记录通过网络传输，以及那些使用备忘录字段的人将会注意速度问题。


将备忘录字段划分为一个是相当多的工作

分开，我想对此有一些看法。除非选择报价，否则我认为

打破它们会对数据的影响不会超过

网络。


非常感谢，


Andy

This is mainly a speed question.

In this example: I have a QuotesHdr table that has a few memo fields. If
these memo fields are used extensively by some users, and if their are a
large number of records in QuotesHdr, should I break out the memo fields
into a separate table? The thinking here is that, for Quotes selection
dropdowns that display all entries in QuotesHdr for selection, I would
think that the entire record comes down over the network, and those who
use the memo fields would be the ones to notice speed issues.

It will be a fair amount of work to break out the memo fields into one
separate, and I''d like to have some opinions on this. I would think
breaking them out would have the affect of the data not coming down over
the network unless a quote is selected.

Many Thanks,

Andy

通过网络下来，我意味着发送整个数据记录，包括备忘录字段，通过网络连接到用户的电脑。因此，如果

我的查找组合框确实包含所有引号，并在索引的

字段，报价编号上排序，并包含报价说明，日期和客户
名称，然后听起来好像没有检索备忘录字段，除非实际选择了

报价。


非常感谢，


" Larry Linson" < bo ***** @ localhost.notwrote in message

news：ho％yi.15497

By coming down over the network, I meant sending the entire record of data,
including the memo fields, accross the network wire to the user''s pc. So if
my lookup combo box does contain all quotes, and is sorted on the indexed
field, quote number, and contains quote description, date, and customer
name, then it sounds like the memo field would not be retrieved unless the
quote is actually selected.

Many thanks,

"Larry Linson" <bo*****@localhost.notwrote in message
news:ho%yi.15497

4K6.10684@trnddc02 ...

4K6.10684@trnddc02...

备注字段与您在其中看到

的表格分开存储 - 这就是为什么有时它们已经存在更多有问题比

其他类型的领域。


你究竟是什么意思通过网络下来？

如果你有一个前后分割，正确索引，并选择

索引字段（根据定义，它们不是Memo类型），那么只有
通过网络检索
索引以选择所需的记录，因此只有

与当前感兴趣的记录相关联的备注字段将降低

降低网络。


如果您在

连续视图表单中为用户显示整个表格或查询的数据要在前后端选择

环境，你需要重新检查你的应用程序的设计。


将备忘录字段分成另一个表可能不会像你想象的那样帮助

。


Larry Linson

Microsoft Access MVP


ARC < an ** @ andyc.comwrote in message

news：eS **************** @ nlpi068.nbdc.sbc.com ...

Memo fields are stored separately from the table in which you "see"
them -- that is why, at times, they have been more "problematic" than
other types of field.

What, exactly, do you mean by "come down over the network"?

If you have a split front and back end, properly indexed, and select by
indexed fields (which, by definition, are not Memo type), then only the
index is retrieved over the network to select the desired record, so only
the Memo fields associated with the current record of interest will "come
down over the network".

If you are displaying an entire table''s or query''s worth of data in a
continuous view form for the user to select in a front-back end
environment, you need to reexamine your application''s design.

Separating the memo fields into another table is likely not going to help
as much as you might think.

Larry Linson
Microsoft Access MVP

"ARC" <an**@andyc.comwrote in message
news:eS****************@nlpi068.nbdc.sbc.com...

>这主要是一个速度问题。

在这个例子中：我有一个QuotesHdr表，它有一些备注字段。如果这些备忘录字段被一些用户广泛使用，并且如果它们是QuotesHdr中的大量记录，我应该将备忘录字段分成单独的表格吗？这里的想法是，对于Quotes选择
下拉列表，显示QuotesHdr中的所有条目供选择，我会认为整个记录通过网络传下来，以及那些使用备忘录的人领域将是那些注意速度问题的领域。

将备忘录字段分成一个单独的，将会有相当多的工作，我希望有一些意见就此而言。除非选择报价，否则我认为将它们分解会对网络上的数据产生影响。

非常感谢，

Andy

>This is mainly a speed question.

In this example: I have a QuotesHdr table that has a few memo fields. If
these memo fields are used extensively by some users, and if their are a
large number of records in QuotesHdr, should I break out the memo fields
into a separate table? The thinking here is that, for Quotes selection
dropdowns that display all entries in QuotesHdr for selection, I would
think that the entire record comes down over the network, and those who
use the memo fields would be the ones to notice speed issues.

It will be a fair amount of work to break out the memo fields into one
separate, and I''d like to have some opinions on this. I would think
breaking them out would have the affect of the data not coming down over
the network unless a quote is selected.

Many Thanks,

Andy

这篇关于在大型数据库中，Memo字段应该转到自己的表吗？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！