At this time I've two fields for cost. One for dollars and something for cents. This works, but it's a little ugly. Additionally, it does not permit the user to go in the word "free" or "cost-freeInch when they want. But when I have only one area, I may need to make my parser a little wiser. What is your opinion?
Around the server side, I mix money to keep them as decimals during my database. Mainly to ensure that I'm able to gather statistics (cost earnings, etc.) rapidly.
Do you consider it is best to keep the price like a string? Then whenever I really make use of the cost for stats or any other reasons, I'd convert it to some decimal at that time. Or shall we be held on course?
There's a guide in database design that states that "atomic data" shouldn't be split. With this rule a cost, or price is such a good example of atomic data and for that reason it will not be split among multiple posts exactly like you should not split a telephone number among multiple posts (unless of course you actually possess a good reason for this - unusual)
Make use of a DECIMAL data type. Something similar to DECIMAL(8,3) should work and it is based on all ANSI SQL compliant database items!
EDIT - It appears out of your question that you're also worried about how you can accept user's input inside a form that resembles the cost (xxxx.xx) - hence the 2 input boxes, for the entire dollars, and also the pennies.
I suggest utilizing a single input box after which doing input validation using Regular Expressions to fit your format (i.e. something similar to [-9]+(.[-9])? would most likely work but tend to be enhanced). You can then parse the validated string to some Decimal key in a foreign language, or simply pass it as being a string to your database - SQL will understand how to cast it to some DECIMAL type.
Keep your whole cost as decimal. Whether it's free, then keep your cost as . In presentation if price is zero - write "free" rather than .
I generally keep cost because the cheapest unit (pennies) after which convert it to whole dollars later.
So an expense of $4.50 will get saved as 450. Free products could be -1 pennies. You can store samples by mail as pennies too, this provides the versatility to make use of and -1 to mean two slightly various things (free versus no purchase?).
Additionally, it causes it to be simpler to aid nations that do not use cents if you opt to go down that path.
For showing the information entry area, Personally, i can't stand it when I must keep switching fields for small things (like once they split up telephone numbers into 3 fields, or IP addresses into 4). I'd present one area, and allow the customers type the decimal reason for themselves. This way, your customers do not have to tab (or click, if they're not really acquainted with tab) to another area.
Use cents, use 450 for $4.50 this could save you damage that is developing very frequently from the truth that floating point procedures aren't safe. Just try the next expression in irb: .4 - .3 == .1 will return false. All due to floating point representation innacuracies.
During my models I am always using:
attr_accessor :price_with_cents def price_with_cents self.price/100.00 end def price\_with\_cents==(num) self.price = (num.to_f * 100.00).to_i end
And also the title of column is simply cost and integer type.
I do not cash knowledge about decimal posts as well as their representation in ruby (which may be float that's problematic as i have proven in the begining).