[Resolved] DB schema: why is `price` not UNSIGNED?

[MyNameWasTaken]

Hi there,

I was cruising around the db schema recently and noticed that `price`, in all its variations (e.g. inventory, order, coupon, sale, etc.), is defined as DECIMAL(16,2) NOT NULL DEFAULT '0.00' and was curious as to the reasoning behind this.

Are negative prices expected? Perhaps for `option_price`, which may reduce a product's price, but then isn't that the purpose of the `option_negative` column? If not / for the rest, wouldn't changing the column definition to UNSIGNED be more semantically meaningful?

Anyway, no big deal, just curious if there was a specific design choice that was made or if it's just how the cookie crumbled.

[bsmither]

Not being privy to specific design (programming) decisions, I can only speculate.

But having deeply examined CubeCart code including CC3, CC5, and CC6, I can conclude that no decision was made to give any extensive analysis to the performance or 'tightness' of the code.

If it works, that's good enough. No sense in spending 20 man-hours to squeeze out an additional 0.20 seconds of processing time.

I can say that negative prices are not expected, but I can also say that negative prices are not disallowed - either by design or by accident. Tighten something too tight, you don't have any wiggle-room.

[MyNameWasTaken]

Very true. It's always a tough balancing act between not-enough and too-much wiggle room.

I don't see any downsides to allowing negative pricing (I mean, if the store owner really wants to pay people to take their products...), though I have no idea how a payment gateway would handle that - might have to try it out someday

Anyway, I was just curious. Thanks for the response.