VFP9
I don't see why folks would use Numeric(X,0) where X > 4 instead of an Integer field. Can you tell me why? I'm guessing it's leftover legacy design?
tia, --Mike
Not counting legacy reasons for already available systems, I think that this is because many did not learn about the available data types and just stay with what they know, others because did think that are the same, and others because they don't care.
I know some of those guys, btw.
2018-04-04 21:43 GMT+02:00 mbsoftwaresolutions@mbsoftwaresolutions.com:
VFP9
I don't see why folks would use Numeric(X,0) where X > 4 instead of an Integer field. Can you tell me why? I'm guessing it's leftover legacy design?
tia, --Mike
[excessive quoting removed by server]
On 2018-04-04 16:53, Fernando D. Bozzo wrote:
Not counting legacy reasons for already available systems, I think that this is because many did not learn about the available data types and just stay with what they know, others because did think that are the same, and others because they don't care.
I know some of those guys, btw.
ALBEIT PROBABLY MINISCULE, won't the Integer type be a better, more efficient, faster processing choice? I noticed in this app I inherited, the main table where it's the PK, it's an INTEGER type, but in a another table where it's the foreign key, it's a N(10,0) type. I'll have to break out SYS(3054) I guess to see if it optimizes, given the difference!
Yes, in this case INT is much better because it only need 4 bytes on disk and have direct hex interpretation, while the number occupies 10 bytes and need digit by digit calculation.
Being both data types related, I thing that it's a secure assumption that the number field can be replaced by the INT data type.
El jue., 5 de abril de 2018 5:05, < mbsoftwaresolutions@mbsoftwaresolutions.com> escribió:
On 2018-04-04 16:53, Fernando D. Bozzo wrote:
Not counting legacy reasons for already available systems, I think that this is because many did not learn about the available data types and just stay with what they know, others because did think that are the same, and others because they don't care.
I know some of those guys, btw.
ALBEIT PROBABLY MINISCULE, won't the Integer type be a better, more efficient, faster processing choice? I noticed in this app I inherited, the main table where it's the PK, it's an INTEGER type, but in a another table where it's the foreign key, it's a N(10,0) type. I'll have to break out SYS(3054) I guess to see if it optimizes, given the difference!
[excessive quoting removed by server]
On 2018-04-05 01:20, Fernando D. Bozzo wrote:
Yes, in this case INT is much better because it only need 4 bytes on disk and have direct hex interpretation, while the number occupies 10 bytes and need digit by digit calculation.
Being both data types related, I thing that it's a secure assumption that the number field can be replaced by the INT data type.
I agree -- I'd feel completely fine converting anything N(5+,0) to Int.
Speaking of SYS(3054) & SYS(3092), I have to be honest and admit I have not been using these amazing tools until recently trusting my instinct that my queries were optimized based on the speeds I was achieving just by creating various indexes. A recent thread on this group convinced me to spend some time and learn how to use these features and I tried them out on an almost completed project and frankly, I really wasn't expecting much of an improvement over what I already had in place.
OMG! I got a 75% improvement in performance applying the feedback I got from the test results. Unbelievable. I'm now trying to apply this to every active project and I have a couple of old projects I'm going to retro-fit. Holy crap! I just thought FoxPro was fast before.
I just had to share and tell this group THANK YOU!
Paul
-----Original Message----- From: ProfoxTech [mailto:profoxtech-bounces@leafe.com] On Behalf Of mbsoftwaresolutions@mbsoftwaresolutions.com Sent: Wednesday, April 04, 2018 10:06 PM To: profoxtech@leafe.com Subject: Re: Numeric(x,0) vs Integer field type in VFP tables
On 2018-04-04 16:53, Fernando D. Bozzo wrote:
Not counting legacy reasons for already available systems, I think that this is because many did not learn about the available data types and just stay with what they know, others because did think that are the same, and others because they don't care.
I know some of those guys, btw.
ALBEIT PROBABLY MINISCULE, won't the Integer type be a better, more efficient, faster processing choice? I noticed in this app I inherited, the main table where it's the PK, it's an INTEGER type, but in a another table where it's the foreign key, it's a N(10,0) type. I'll have to break out SYS(3054) I guess to see if it optimizes, given the difference!
[excessive quoting removed by server]