备忘录字段 - 要求麻烦？ [英] memo fields - asking for trouble?
问题描述
我有一个广泛使用备忘录字段的mdb（2002文件格式）。我已经阅读了很多关于备忘录字段存在问题的内容以及避免它们的内容
是一个好主意。但是我坚持使用它们并且想知道是否有任何优化或降低使用它们的风险的最佳实例。这是'/ b> b一张表的样子：
NoteText - 备忘录
NoteDate - 日期/时间（索引，欺骗）好的）
NoteBrief - 文字（长度= 254）
Entity_ID - （长，外键，索引，欺骗确定））
Note_ID - （自动编号，长，主键）
这个表变得非常大 - 将NoteText字段放在它的'b
自己的表中（这样这是表中唯一的帮助，或者确实是这样吗？
Don不要担心它。
虽然腐败的可能性略有增加，但当你需要它时，请使用它们。避免它们与建造带门的汽车一样有用，因为侧面的切割门会削弱车辆的框架。如果你需要它们，那就建立它们吧。
你描述的表不是一个很大的表，除非你有数百万美元
记录在其中。
-
Allen Browne - 微软MVP。西澳大利亚州珀斯。
访问用户提示 - http：// allenbrowne.com/tips.html
回复群组，而不是mvps dot org的allenbrowne。
" deko" <德** @ hotmail.com>在消息中写道
新闻：Ki ******************* @ newssvr29.news.prodigy。 com ...我有一个广泛使用备忘录字段的mdb（2002文件格式）。我已经阅读了很多关于备忘录字段存在问题的内容，并且避免使用它们
是一个好主意。但是我坚持使用它们，并且想知道是否有
优化用于优化或降低使用它们的风险。
这里是一张表的样子：
NoteText - 备忘录
NoteDate - 日期/时间（索引，欺骗确定）
NoteBrief - 文本（长度= 254）
Entity_ID - （Long，Foreign Key，indexed，dupes ok））
Note_ID - （自动编号，长，主键）
这张桌子变得非常大 - 会将NoteText字段放在
中它自己的表（这是表中唯一的东西）帮助，还是它真的有所作为？
>不要担心它。
谢谢 - 希望2002文件格式有一些额外的稳定性
。
如果A2002
格式的稳定性存在很大差异，我会感到惊讶A2000格式。
-
Allen Browne - 微软MVP。西澳大利亚州珀斯。
访问用户提示 - http：// allenbrowne.com/tips.html
回复群组，而不是mvps dot org的allenbrowne。
" deko" <德** @ hotmail.com>在消息中写道
news：zy ****************** @ newssvr25.news.prodigy.c om ...不要担心。
谢谢 - 希望2002文件格式还有一些额外的稳定性。
I have an mdb (2002 file format) that uses memo fields extensively. I''ve
read a lot about how problematic memo fields can be and that avoiding them
is a good idea. But I''m stuck with them and was wondering if there are any
best-parctices for optimizing or mitigating the risk of using them. Here''s
what one table looks like:
NoteText - Memo
NoteDate - Date/Time (indexed, dupes ok)
NoteBrief - Text (length = 254)
Entity_ID - (Long, Foreign Key, indexed, dupes ok))
Note_ID - (Autonumber, Long, Primary Key)
This table is getting awfully big - would putting the NoteText field in it''s
own table (so that''s the only thing in the table) help, or does it really
make a difference?
Don''t worrry about it.
While there is a slightly increased chance of corruption, use them when you
need it. Avoiding them is about as useful as building a car with doors,
since cutting doors in the side weakens the frame of the vehicle. If you
need them, build them in.
The table you describe is not a very big table, unless you have millions of
records in it.
--
Allen Browne - Microsoft MVP. Perth, Western Australia.
Tips for Access users - http://allenbrowne.com/tips.html
Reply to group, rather than allenbrowne at mvps dot org.
"deko" <de**@hotmail.com> wrote in message
news:Ki*******************@newssvr29.news.prodigy. com...I have an mdb (2002 file format) that uses memo fields extensively. I''ve
read a lot about how problematic memo fields can be and that avoiding them
is a good idea. But I''m stuck with them and was wondering if there are any best-parctices for optimizing or mitigating the risk of using them. Here''s what one table looks like:
NoteText - Memo
NoteDate - Date/Time (indexed, dupes ok)
NoteBrief - Text (length = 254)
Entity_ID - (Long, Foreign Key, indexed, dupes ok))
Note_ID - (Autonumber, Long, Primary Key)
This table is getting awfully big - would putting the NoteText field in it''s own table (so that''s the only thing in the table) help, or does it really
make a difference?
> Don''t worrry about it.
Thanks - hopefully there is some added stability with the 2002 file format
as well.
I''d be surprised if there was much difference in the stability of the A2002
format w.r.t. the A2000 format.
--
Allen Browne - Microsoft MVP. Perth, Western Australia.
Tips for Access users - http://allenbrowne.com/tips.html
Reply to group, rather than allenbrowne at mvps dot org.
"deko" <de**@hotmail.com> wrote in message
news:zy******************@newssvr25.news.prodigy.c om...Don''t worrry about it.
Thanks - hopefully there is some added stability with the 2002 file format
as well.
这篇关于备忘录字段 - 要求麻烦？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
