Subtle

Post #423,316 by drook 4/12/18 1:11:45 PM 4/12/18 1:11:45 PM Reply	Subtle We had a field in the DB defined as decimal, with 0 decimal places. Ask me how long it took for someone to notice that. No, on second thought don't ask me that. -- Drew
Post #423,320 by mmoffitt 4/12/18 5:02:52 PM 4/12/18 5:02:52 PM Reply	We have AS400 databases with dozen upon dozen of those. Our RPG programmers refused to use Integer. bcnu, Mikem It's mourning in America again.
Post #423,321 by crazy 4/12/18 6:15:27 PM 4/12/18 6:15:27 PM Reply	Might make sense I seem to recall mainframe and s34/36/38 bcd storage and compute optimizations at the os and cpu level. Since as/400 is the next step of the s/3x line, they might have been maintained. Also, bcd math is different from integer math when handling money operations (forget how, just was trained to implement differently), so that may be why.
Post #423,325 by Another Scott 4/12/18 10:00:20 PM 4/12/18 10:00:20 PM Reply	Sounds vaguely familiar... Long ago I worked for a Domino's franchise that had about 20 stores. They had a small AS/400 running the back end stuff. For a few weeks I did data entry stuff for their stores - things like entering how many sacks of flour each store needed the next day. Sacks (or whatever) were entered as reals (10.00 sacks). I didn't understand it at the time, but they must have had a reason for doing it that way. I learned things on that job like the ingredients for a large cheese pizza cost something like $0.2347. Buying in bulk really cuts the cost!! Cheers, Scott.
Post #423,327 by drook 4/12/18 10:35:36 PM 4/12/18 10:35:36 PM Reply	Why to do that for flour You start the day with 4 sacks of flour that weigh 50 lb each. You use 27 pounds of flour. How many sacks do you have left? -- Drew
Post #423,328 by Another Scott 4/12/18 10:56:40 PM 4/12/18 10:56:40 PM Reply	But they ordered integer quantities. I would get a call at 11 PM - "This is store #23 - I need 6 flours (bags), 7 cheeses (bags), 5 peppers (bags), ..." It was all integers. The dB would have a total of XXX.XX bags of flour in the warehouse that some nominal subtraction was done from, but that was integer items as well (though it was also a real in the dB). Maybe they had to have the quantities as reals to do the division to get the average prices to 4-5 decimal places or something. I dunno. Nobody ever explained it to me. It just seemed funky to me and it seemed to invite data entry errors (I had to enter 10.00 for 10). At least that's my fuzzy recollection. It was nearly 30 years ago now. (Sheesh!) Cheers, Scott.
Post #423,333 by mmoffitt 4/13/18 8:10:07 AM 4/13/18 8:10:07 AM Reply	But can you explain this? Decimal(5, 0) for surrogate key values in tables? bcnu, Mikem It's mourning in America again.
Post #423,335 by Another Scott 4/13/18 8:16:04 AM 4/13/18 8:16:04 AM Reply	Nope. I never was a dB coder.
Post #423,338 by mmoffitt 4/13/18 9:31:44 AM 4/13/18 9:31:44 AM Reply	It wouldn't have helped if you had been. ;0) bcnu, Mikem It's mourning in America again.
Post #423,336 by drook 4/13/18 9:11:47 AM 4/13/18 9:11:47 AM Reply	You order integer quantities, but stock on hand is fractional Someone building the UI today would (obviously, I hope) not require entering the ".00" every time, but weren't greenscreen apps much more closely tied to the underlying data? -- Drew
Post #423,341 by Another Scott 4/13/18 11:11:22 AM 4/13/18 11:11:22 AM Reply	My recollection is that it was a funky program. I would often end up with totals that exceeded the listed stock in the warehouse. (Negative warehouse totals resulted.) It didn't seem to matter - I was told to ignore it. I gathered that whoever was in charge of ordering stuff for the warehouse had some different way of keeping track of what was needed and when (but it sorta made what I was doing kinda pointless as far as that goes). ¯\_(ツ)_/¯ Programs are weird sometimes. :-) Cheers, Scott.
Post #423,344 by static 4/13/18 8:37:28 PM 4/13/18 8:37:28 PM Reply	BCD and old mainfraimes. I think you might've hit on it. I seem to recall that so-called "integer" fields in languages like COBOL were really BCD fields. BCD math (especially when the processor does it) has the advantage that you can just add more bytes to support a larger value. This avoids integer overflow problems, or at least makes them intuitive, particularly for non-programmers. Add decimal support and you've also avoided the problem of using floats for currency. (I had a serious discussion many many years ago about the error characteristics of radix-2 floating point numbers and why you didn't want to use them for currency. Turns out there's a radix-10 version of IEEE-754 which is intended for currency. But microcomputers of the time all used radix-2 and therefore programs like Excel did, too.) Wade.
Post #423,349 by scoenye 4/14/18 11:13:13 AM 4/14/18 11:13:13 AM Reply	Saving space? It doesn't matter much anymore these days, but if the data model goes back a while and you have a good grasp on the range of values, then decimal(x, 0) may have resulted in lower storage space use vs. a plain integer type. decimal is a packed format. Depending on the database engine, it can take up as little as 1 byte where an integer takes at least 2. Space savings would increase as the range goes up as the space needed for a decimal goes up 1 byte at a time. Integer would be 2/4/8. Assuming standard SQL.

Welcome to IWETHEY!