Wasting bytes
-
Am I the only one who is annoyed by systematic wasting of database bytes? It seems as if everyone uses the "int" type because they are too lazy to use smallint or tinyint. We even have standards that force us to use the "int" type for values that are never going to go higher than 10 or 20. Tables such as: PaymentType 0 = Cash 1 = Check 2 = Credit card 3 = Money order You know we're never going to invent more than 255 ways of paying for stuff, and we're certainly never inventing more than 32 thousand ways of paying for stuff, so why do we have to make the ID column an int? Maybe if we're bombed into the stone age and forced to barter using cows, sheep, and cartloads of asparagus, we'll have 32 thousand different ways of paying, but I imagine if that happens, the financial software we're writing will be absolutely useless, anyway.
-
Am I the only one who is annoyed by systematic wasting of database bytes? It seems as if everyone uses the "int" type because they are too lazy to use smallint or tinyint. We even have standards that force us to use the "int" type for values that are never going to go higher than 10 or 20. Tables such as: PaymentType 0 = Cash 1 = Check 2 = Credit card 3 = Money order You know we're never going to invent more than 255 ways of paying for stuff, and we're certainly never inventing more than 32 thousand ways of paying for stuff, so why do we have to make the ID column an int? Maybe if we're bombed into the stone age and forced to barter using cows, sheep, and cartloads of asparagus, we'll have 32 thousand different ways of paying, but I imagine if that happens, the financial software we're writing will be absolutely useless, anyway.
Well I, for one, try to use an appropriate type but I do see it all the time. My biggest niggle is using a char field as a psudo boolean (you know, yes/no). Aggh??? Why???
"If you think it's expensive to hire a professional to do the job, wait until you hire an amateur." Red Adair. nils illegitimus carborundum me, me, me
-
Well I, for one, try to use an appropriate type but I do see it all the time. My biggest niggle is using a char field as a psudo boolean (you know, yes/no). Aggh??? Why???
"If you think it's expensive to hire a professional to do the job, wait until you hire an amateur." Red Adair. nils illegitimus carborundum me, me, me
mark merrens wrote:
My biggest niggle is using a char field as a pseudo boolean (you know, yes/no).
I've seen too many of those. The best is that they usually aren't written to be case insensitive or user entry validated. :doh:
I wasn't, now I am, then I won't be anymore.
-
Am I the only one who is annoyed by systematic wasting of database bytes? It seems as if everyone uses the "int" type because they are too lazy to use smallint or tinyint. We even have standards that force us to use the "int" type for values that are never going to go higher than 10 or 20. Tables such as: PaymentType 0 = Cash 1 = Check 2 = Credit card 3 = Money order You know we're never going to invent more than 255 ways of paying for stuff, and we're certainly never inventing more than 32 thousand ways of paying for stuff, so why do we have to make the ID column an int? Maybe if we're bombed into the stone age and forced to barter using cows, sheep, and cartloads of asparagus, we'll have 32 thousand different ways of paying, but I imagine if that happens, the financial software we're writing will be absolutely useless, anyway.
I've had to make several database changes this year based on somebodies assumption that there would never be over 32K of entries in a series of tables. Million dollar order entry software crashing because somebody had to save a few bytes and use smallint or tinyint. Hard drives are cheap, programming hours are not. Use INT, use it everywhere, even if you think you'll never need that many numbers.
Kill some time, play my game Hop Cheops[^]
-
Am I the only one who is annoyed by systematic wasting of database bytes? It seems as if everyone uses the "int" type because they are too lazy to use smallint or tinyint. We even have standards that force us to use the "int" type for values that are never going to go higher than 10 or 20. Tables such as: PaymentType 0 = Cash 1 = Check 2 = Credit card 3 = Money order You know we're never going to invent more than 255 ways of paying for stuff, and we're certainly never inventing more than 32 thousand ways of paying for stuff, so why do we have to make the ID column an int? Maybe if we're bombed into the stone age and forced to barter using cows, sheep, and cartloads of asparagus, we'll have 32 thousand different ways of paying, but I imagine if that happens, the financial software we're writing will be absolutely useless, anyway.
I have a better things to do than trying to outsmart the future with predictions what numeric type every field should be. Besides In a big system (hundreds or thousands of tables) it will be a recipe for disaster. All this integer types will have to use according variable types in the store procedures, functions and in the client (if you have a multiple middle tiers the fun will be endless) just to avoid data truncation.
There is only one Vera Farmiga and Salma Hayek is her prophet! Advertise here – minimum three posts per day are guaranteed.
-
I've had to make several database changes this year based on somebodies assumption that there would never be over 32K of entries in a series of tables. Million dollar order entry software crashing because somebody had to save a few bytes and use smallint or tinyint. Hard drives are cheap, programming hours are not. Use INT, use it everywhere, even if you think you'll never need that many numbers.
Kill some time, play my game Hop Cheops[^]
:thumbsup:
There is only one Vera Farmiga and Salma Hayek is her prophet! Advertise here – minimum three posts per day are guaranteed.
-
Am I the only one who is annoyed by systematic wasting of database bytes? It seems as if everyone uses the "int" type because they are too lazy to use smallint or tinyint. We even have standards that force us to use the "int" type for values that are never going to go higher than 10 or 20. Tables such as: PaymentType 0 = Cash 1 = Check 2 = Credit card 3 = Money order You know we're never going to invent more than 255 ways of paying for stuff, and we're certainly never inventing more than 32 thousand ways of paying for stuff, so why do we have to make the ID column an int? Maybe if we're bombed into the stone age and forced to barter using cows, sheep, and cartloads of asparagus, we'll have 32 thousand different ways of paying, but I imagine if that happens, the financial software we're writing will be absolutely useless, anyway.
-
I've had to make several database changes this year based on somebodies assumption that there would never be over 32K of entries in a series of tables. Million dollar order entry software crashing because somebody had to save a few bytes and use smallint or tinyint. Hard drives are cheap, programming hours are not. Use INT, use it everywhere, even if you think you'll never need that many numbers.
Kill some time, play my game Hop Cheops[^]
I agree that whenever you're in doubt, use the bigger value, especially if a user application can add rows to the table. But some of these tables are basically a list of eunms which never get new rows unless a programmer deliberately adds one as a result of a change request. Maybe disk space is so cheap that it will never matter, but it always looks bad.
-
Well I, for one, try to use an appropriate type but I do see it all the time. My biggest niggle is using a char field as a psudo boolean (you know, yes/no). Aggh??? Why???
"If you think it's expensive to hire a professional to do the job, wait until you hire an amateur." Red Adair. nils illegitimus carborundum me, me, me
-
Am I the only one who is annoyed by systematic wasting of database bytes? It seems as if everyone uses the "int" type because they are too lazy to use smallint or tinyint. We even have standards that force us to use the "int" type for values that are never going to go higher than 10 or 20. Tables such as: PaymentType 0 = Cash 1 = Check 2 = Credit card 3 = Money order You know we're never going to invent more than 255 ways of paying for stuff, and we're certainly never inventing more than 32 thousand ways of paying for stuff, so why do we have to make the ID column an int? Maybe if we're bombed into the stone age and forced to barter using cows, sheep, and cartloads of asparagus, we'll have 32 thousand different ways of paying, but I imagine if that happens, the financial software we're writing will be absolutely useless, anyway.
I see where you are coming from with regards to what is known about a particular set of data at the moment. However I have seen on occasion cases where in the example you give you may want a value of 9999 to reference a refund for example. Sometimes you want a value at the extreme end of a range so that your logic can use between comparisons rather than individually listing values as in the refund example above. I did my IT degree at the end of the 80's when memory was expensive and we were taught to calculate the amount of space required - nowadays with memory being cheap this is not such an issue. For what it's worth I would say always build in the possibility of expansion into a system...
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
-
Am I the only one who is annoyed by systematic wasting of database bytes? It seems as if everyone uses the "int" type because they are too lazy to use smallint or tinyint. We even have standards that force us to use the "int" type for values that are never going to go higher than 10 or 20. Tables such as: PaymentType 0 = Cash 1 = Check 2 = Credit card 3 = Money order You know we're never going to invent more than 255 ways of paying for stuff, and we're certainly never inventing more than 32 thousand ways of paying for stuff, so why do we have to make the ID column an int? Maybe if we're bombed into the stone age and forced to barter using cows, sheep, and cartloads of asparagus, we'll have 32 thousand different ways of paying, but I imagine if that happens, the financial software we're writing will be absolutely useless, anyway.
-
Well I, for one, try to use an appropriate type but I do see it all the time. My biggest niggle is using a char field as a psudo boolean (you know, yes/no). Aggh??? Why???
"If you think it's expensive to hire a professional to do the job, wait until you hire an amateur." Red Adair. nils illegitimus carborundum me, me, me
You have to! A
booljust doesn't hold enough information: I wantyes,noandmaybe. :-DIdeological Purity is no substitute for being able to stick your thumb down a pipe to stop the water
-
You have to! A
booljust doesn't hold enough information: I wantyes,noandmaybe. :-DIdeological Purity is no substitute for being able to stick your thumb down a pipe to stop the water
-
In Progress a LOGICAL can be TRUE, FALSE, or ? - which is unknown.
Every man can tell how many goats or sheep he possesses, but not how many friends.
I have seen code that went:
void MyMethod(bool b) { if (b == true) { ... } else if (b == false) { ... } else { ... } }And to think I assumed they were idiots! :doh:
Ideological Purity is no substitute for being able to stick your thumb down a pipe to stop the water
-
You have to! A
booljust doesn't hold enough information: I wantyes,noandmaybe. :-DIdeological Purity is no substitute for being able to stick your thumb down a pipe to stop the water
You need a trinary field, not a boolean then.
"If you think it's expensive to hire a professional to do the job, wait until you hire an amateur." Red Adair. nils illegitimus carborundum me, me, me
-
Bang - that was the door closing behind your fired ass.. oh wait a joke icon :-O
Never underestimate the power of human stupidity RAH
-
Am I the only one who is annoyed by systematic wasting of database bytes? It seems as if everyone uses the "int" type because they are too lazy to use smallint or tinyint. We even have standards that force us to use the "int" type for values that are never going to go higher than 10 or 20. Tables such as: PaymentType 0 = Cash 1 = Check 2 = Credit card 3 = Money order You know we're never going to invent more than 255 ways of paying for stuff, and we're certainly never inventing more than 32 thousand ways of paying for stuff, so why do we have to make the ID column an int? Maybe if we're bombed into the stone age and forced to barter using cows, sheep, and cartloads of asparagus, we'll have 32 thousand different ways of paying, but I imagine if that happens, the financial software we're writing will be absolutely useless, anyway.
IBM in its 360/370/3090 mainframes has something called Packed Decimal which would take half the amount of bytes that a regular decimal (Zoned Decimal in IBM-speak) would need. It gives grief to anyone who wants to read data from a mainframe and process it on a Unix box or PC.
-
Am I the only one who is annoyed by systematic wasting of database bytes? It seems as if everyone uses the "int" type because they are too lazy to use smallint or tinyint. We even have standards that force us to use the "int" type for values that are never going to go higher than 10 or 20. Tables such as: PaymentType 0 = Cash 1 = Check 2 = Credit card 3 = Money order You know we're never going to invent more than 255 ways of paying for stuff, and we're certainly never inventing more than 32 thousand ways of paying for stuff, so why do we have to make the ID column an int? Maybe if we're bombed into the stone age and forced to barter using cows, sheep, and cartloads of asparagus, we'll have 32 thousand different ways of paying, but I imagine if that happens, the financial software we're writing will be absolutely useless, anyway.
I've used small and tiny ints in databases that handled millions to billions of transactions a day. It made sense there. I'm working on a lob app that uses smallints even though the entire database is under a Gig and it means I have to write extra code to handle those objects with non-integer primary keys which is a pain in the ass. It all depends on context.
Curvature of the Mind now with 3D
-
Well I, for one, try to use an appropriate type but I do see it all the time. My biggest niggle is using a char field as a psudo boolean (you know, yes/no). Aggh??? Why???
"If you think it's expensive to hire a professional to do the job, wait until you hire an amateur." Red Adair. nils illegitimus carborundum me, me, me
Funny you should mention that. I'm forced to do just that. Why? Because Microsoft's System Center Configuration Manager software uses the old MIF file format for importing hardware and software inventory into the SCCM database. Well, if you have a field in a custom inventory item, say one that specified a true/false value, the MIF specification doesn't support Boolean types! So, "True/False" it is! (This is was easier for upstream people to understand than it was for them to get that 1 = True, 0 = False.) Trust me, not my choice!
A guide to posting questions on CodeProject[^]
Dave Kreskowiak
