Wasting bytes
-
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
