键数值数据类型 [英] Key Numeric Datatype

问题描述

大家好，


人们在定时查询性能方面的经验是什么？我已经徒劳无功地尝试了
，但是得到了许多不可预知的结果，执行后执行

后台和定时精度问题。


我试图使用BYTE而不是LONG类型使用FK

来评估我的应用程序性能差异。而不是在

数据库级别强制执行完整性。 （即表格级别）。只有当字段在排序，过滤，计算中被高度使用时，这才会变得非常重要。


Access自动分配Long Integer。对于自动编号字段。

这对于预计只有少量

记录的表来说非常低效。 （即，OrderTypeID可能只有6条记录）。


有人想告诉他们在数据类型速度问题上的经验吗？


问候，

Elias Farah

Hi All,

What are people''s experience in timing Query Performance? I have
tried in vain, but get many unpredictable results, with execution
proceeding in the background and problems of timing precision.

I am trying to assess my applications performance difference using FK
using BYTE instead of LONG type. and not enforcing integrity at the
database level. (ie, Form level). This only becomes SIGNIFICANT when
the field is used highly in Sorting, Filtering, Calculating.

Access automatically assigns "Long Integer" for Autonumber Fields.
This is very inefficient in tables where there is only a small number
of records expected. (Ie, OrderTypeID may only have 6 records).

Anyone like to tell their experience in Datatype Speed issues?

Regards,
Elias Farah

推荐答案

lo ****** @ hotmail.com （Elias Farah）在新闻中写道：c6cfe5a6.0308310315.143833d3

@ posting.google.com：

lo******@hotmail.com (Elias Farah) wrote in news:c6cfe5a6.0308310315.143833d3
@posting.google.com:

Access自动分配Long Integer对于自动编号字段。
这对于预期只有少量记录的表来说非常低效。 （即，OrderTypeID可能只有6条记录）。

Access automatically assigns "Long Integer" for Autonumber Fields.
This is very inefficient in tables where there is only a small number
of records expected. (Ie, OrderTypeID may only have 6 records).

为什么？


-

Lyle

Why?

--
Lyle

2003年8月31日04:15:34 -0700， lo ****** @ hotmail.com （Elias Farah）写道：

On 31 Aug 2003 04:15:34 -0700, lo******@hotmail.com (Elias Farah) wrote:

大家好，

什么是人在定时查询性能方面的经验？我已经徒劳无功，但得到了许多不可预知的结果，执行后台处理和时间精度问题。

我试图评估我的应用程序性能差异使用FK
使用BYTE而不是LONG类型。而不是在数据库级别强制执行完整性。 （即表格级别）。当字段在排序，过滤，计算中被高度使用时，这只会变得非常重要。

访问自动分配长整数。对于自动编号字段。
这对于预期只有少量记录的表来说非常低效。 （即，OrderTypeID可能只有6条记录）。

Hi All,

What are people''s experience in timing Query Performance? I have
tried in vain, but get many unpredictable results, with execution
proceeding in the background and problems of timing precision.

I am trying to assess my applications performance difference using FK
using BYTE instead of LONG type. and not enforcing integrity at the
database level. (ie, Form level). This only becomes SIGNIFICANT when
the field is used highly in Sorting, Filtering, Calculating.

Access automatically assigns "Long Integer" for Autonumber Fields.
This is very inefficient in tables where there is only a small number
of records expected. (Ie, OrderTypeID may only have 6 records).

根据文献记载，就性能而言，指数可能是b
从来没有在只有6条记录的桌子上使用过。首先，

整个表格可能会以微不足道的数量缓存到内存中。

的时间，其次，使用索引需要更多的处理能力

定位记录而不是简单地查看表行。

优化器应该计算出来并忽略你可能拥有的任何索引

，无论它是字节，长字还是其他什么。

- Steve Jorgensen


----

我会给你写一个较短的程序，

但是我没有时间。

According to the literature, as far as performance goes, an index will
probably never even get used on a table with only 6 records. First of all,
the whole table will probably get cached into memory in a negligible amount
of time, and second, it would take more processing power to use the index
to locate a record than to simply look through the table rows. The
optimizer should figure this out and ignore any index you may have
regardless of whether it''s a byte, long, or whatever.

- Steve Jorgensen

----
I would have written you a shorter program,
but I didn''t have the time.

查询性能通常由适当的索引和&主要键入

的底层标签。无论你使用BYTE，INTEGER还是LONG都会产生不可察觉的影响 - 除非你的

代码出现严重错误！


为了提高性能，在表单级别（而不是在数据库级别）强制执行完整性，这并不是很有意义。 *有人*必须做支票
！为什么你的代码比Access''更有效？


很抱歉直言不讳，但你真的走错了路。如果您的

查询效果不佳，可能是因为（a）基础

表未正确键入主键，或者（b）查询正在执行

somehing，就其本质而言，不能有效地完成;例如，

计算百万记录表中记录的数量，其中字母为

" i"是姓氏中的第3，第5或第8个字母...


HTH，

TC


Elias Farah <螺****** @ hotmail.com>在消息中写道

news：c6 ************************** @ posting.google.c om ...

Query performance is usually determined by proper indexing & primary-keying
of the underlying tabes. Whether you use BYTEs, INTEGERs or LONGs will have
an imperceptible impact - unless there is something wildly wrong with your
code!

Enforcing integrity at the form level (instead of at the db level) for the
sake of improving performance, just doesn''t maske sense. *Someone* has to do
the checks! Why would your code, be more efficient than Access''es?

Sorry to be blunt, but you really are on the wrong track here. If your
queries are not performing well, it is probably because (a) the underlying
tables are not primary-keyed correctly, or (b) the queries are doing
somehing which, by its very nature, can not be done efficiently; eg.
counting the number of records in a million-record table where the letter
"i" is the 3rd, 5th or 8th letter in the person surname ...

HTH,
TC

"Elias Farah" <lo******@hotmail.com> wrote in message
news:c6**************************@posting.google.c om...

大家好，

人们在定时查询性能方面的经验是什么？我已经徒劳无功，但得到了许多不可预知的结果，执行后台处理和时间精度问题。

我试图评估我的应用程序性能差异使用FK
使用BYTE而不是LONG类型。而不是在数据库级别强制执行完整性。 （即表格级别）。当字段在排序，过滤，计算中被高度使用时，这只会变得非常重要。

访问自动分配长整数。对于自动编号字段。
这对于预期只有少量记录的表来说非常低效。 （即，OrderTypeID可能只有6条记录）。

任何人都喜欢讲述他们在数据类型速度问题上的经验吗？

问候，

Elias Farah

Hi All,

What are people''s experience in timing Query Performance? I have
tried in vain, but get many unpredictable results, with execution
proceeding in the background and problems of timing precision.

I am trying to assess my applications performance difference using FK
using BYTE instead of LONG type. and not enforcing integrity at the
database level. (ie, Form level). This only becomes SIGNIFICANT when
the field is used highly in Sorting, Filtering, Calculating.

Access automatically assigns "Long Integer" for Autonumber Fields.
This is very inefficient in tables where there is only a small number
of records expected. (Ie, OrderTypeID may only have 6 records).

Anyone like to tell their experience in Datatype Speed issues?

Regards,
Elias Farah

这篇关于键数值数据类型的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！