表效率 [英] Table efficiency

查看:71
本文介绍了表效率的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

表被认为效率低下之前可以有多少个字段?


表'的记录最终将达到数千个(每年约3000个)。

解决方案

我认为你在键盘上滑了!


一个表最多只能包含255个字段。


但是,我猜你实际上是想说明在你减速太多之前你有多少记录可以放入JET mdb文件共享?


嗯,好吧,你的设计很好,而你在开发数据库应用程序方面有多年的b
经验,那么你就是ms-access

运行得非常好,即使表格大小达到100,000条记录。


我的网络上通常有大约5个用户的应用程序很少>
分享,大约60张桌子(许多与其他人密切相关),桌子大小

在30,000到40,000记录范围内,并且运行非常好埃尔。所以,当

你有1到100,000记录范围内的小表时,ms-access执行

确实很好。


一张包含100,000条记录的表对于ms访问并不是那么大。


-

Albert D. Kallal(MVP)

加拿大艾伯塔省埃德蒙顿
否************ @ msn.com
http://www.attcanada .net / ~kallal.msn


na ************** @ hotmail.com (内森布鲁姆菲尔德)写道

新闻:4b ****** ********************@posting.google.c om:

表格之前可以有多少个字段被认为是低效的?

表的记录最终将达到数千(每年约3000
)。




我想有很多关于da的问题这会影响可能合适的

字段的数量。


这里是一个。


假设你有一张桌子。


那些人有地址。


我是其中一个人。


如果地址字段是人员表的一部分,我移动,那么你,我认为,
将改变我的地址。精细。你可以给我发邮件。但是,如果您需要在2002年发送邮件的地址记录,那该怎么办?我的2002

地址消失了。所以你可能没有所需的信息。一个孩子

具有[生效日期]字段的地址表可能会给你的数据库更多

电力。通过另一个表格链接的地址表可能会再次为您提供更多的b
功率。例如,它可以防止双重邮寄到相同的

地址。几年前,我遇到了跟​​踪电子邮件的问题,每天发送数千美元的电子邮件。我最后做的是保持查询和

每个发布的输入参数,并为所有地址添加时间戳。所以,

我可以看到一年前做了什么,只需用我保存的

参数重新运行查询。


大约一年前,我停止在Tables中思考并开始思考

列,列的行具有唯一标识符,

列以各种方式组织有用的观点。我相信这就是DB

设计的目的(或者它已经在这里)。


-

Lyle

(电子邮件参考 http:// ffdba。 com / contacts.htm




" Lyle Fairfield" <弥************ @ Invalid.Com>在消息中写道

news:Xn ******************* @ 130.133.1.4 ...

na ************** @ hotmail.com ( Nathan Bloomfield)在
新闻中写道:4b ************************** @ posting.google.c om:
大约一年前,我停止在Tables中思考并开始在
列中思考,列的列具有唯一标识符,并且
列按各种有用的视图进行组织。
我相信这是DB
设计正在进行中(或者它已经在这里)。




听起来像是和我的关系。


How many fields can a table have before it is considered inefficient?

The table''s records will eventually number in the thousands (about 3000 per year).

解决方案

I think you slipped on the keyboard!

A table can only have a max of 255 fields.

However, I am guessing that you actually meant to say how many records can
you put in a JET mdb file share before it slows down too much?

Hum, well, your designs are good, and you have a number of years of
experience in developing database applications, then you will that ms-access
runs very well, even when the tables size get to be 100,000 records.

I have few applications that generally have about 5 users on a network
share, about 60 tables (many heavily related to others), and tables sizes
are in the 30,000 to 40,000 record range, and it runs very well. So, when
you have small tables in the 1 to 100,000 record range, ms-access performs
VERY WELL indeed.

A table of 100,000 records is not really that large for ms-access.

--
Albert D. Kallal (MVP)
Edmonton, Alberta Canada
No************@msn.com
http://www.attcanada.net/~kallal.msn


na**************@hotmail.com (Nathan Bloomfield) wrote in
news:4b**************************@posting.google.c om:

How many fields can a table have before it is considered inefficient?

The table''s records will eventually number in the thousands (about 3000
per year).



I think there are many questions about data that influence the number of
fields that may be appropruate.

Here''s one.

Suppose you have a table of people.

And those people have addresses.

And I am one of the people.

If the address field(s) are part of the people table, and I move, then you
will, I assume, change my address. Fine. You can send me mail. But what if
you need a record of addresses to which you sent mail in 2002? My 2002
address is gone. So you may not have the information that you need. A child
table of addresses with an [effective date] field may give your db more
power. And a table of addresses linked via another table may give you more
power again. For instance, it could prevent double mailings to the same
address. Some years ago I was given the problem of keeping track of e-mail
sends of thousands each day. What I finally did was to keep the query and
the input parameters for each "posting", and time stamp all addresses. So,
I could see what was done a year ago, just by rerunning the query with the
parameters which I had saved.

About a year ago I stopped thinking in Tables and started thinking in
Columns, with the rows of columns having unique identifiers, and the
columns being organized in various useful Views. I believe this is where DB
design is going (or maybe it''s already here).

--
Lyle
(for e-mail refer to http://ffdba.com/contacts.htm)



"Lyle Fairfield" <Mi************@Invalid.Com> wrote in message
news:Xn*******************@130.133.1.4...

na**************@hotmail.com (Nathan Bloomfield) wrote in
news:4b**************************@posting.google.c om: About a year ago I stopped thinking in Tables and started thinking in
Columns, with the rows of columns having unique identifiers, and the
columns being organized in various useful Views.
I believe this is where DB
design is going (or maybe it''s already here).



Sounds like relations to me.


这篇关于表效率的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆