which data type should i use for storing the decimal numbers.
Query 1, which is causing the confusion
Agile Web 3rd edition , page 80 tip says, we should use decimals as
they are scaled to integer in rails as well as databases.
First of all what do they mean by scaling. Basically how doe they
decide the precision if I do not tell them. So if i enter a value
23.456 how do they decide if they should store 234 or 2345 or 23456
Query 2
The test I tried has
t.decimal :price
t.float :rate
t.integer :cost
When i enter the values 34.54 , 43.54 and 123.45
the values that get stored in database are 34, 43.54 and 123.
Why is 34.54 getting converted to 34 only
do I need to specify :precision and :scale necessarily for scaling to
happen in decimals.
Query 3
I know the hazards of using floats. .....they will ditch me on
customer''s machine only.....but I have already written some 20
migrations using float as data type.. Is there any safe way to rescue
if I know I am storing the price and it will always be within 0 and
9999(.00)
~~
vipin
> which data type should i use for storing the decimal numbers.It all depends on how much precision you need. If it''s money, then I''d go with decimal. If you don''t care if a couple thousandths change now and again in doing math go with float...> Query 1, which is causing the confusion > > Agile Web 3rd edition , page 80 tip says, we should use decimals as > they are scaled to integer in rails as well as databases. > First of all what do they mean by scaling. Basically how doe they > decide the precision if I do not tell them. So if i enter a value > 23.456 how do they decide if they should store 234 or 2345 or 23456That doesn''t make much sense to me and I don''t have that book so can''t really say what they are trying to say there.> Query 2 > The test I tried has > > t.decimal :price > t.float :rate > t.integer :cost > > When i enter the values 34.54 , 43.54 and 123.45 > the values that get stored in database are 34, 43.54 and 123. > Why is 34.54 getting converted to 34 only > > do I need to specify :precision and :scale necessarily for scaling to > happen in decimals.Yes.> Query 3 > I know the hazards of using floats. .....they will ditch me on > customer''s machine only.....but I have already written some 20 > migrations using float as data type.. Is there any safe way to rescue > if I know I am storing the price and it will always be within 0 and > 9999(.00)Safe way to rescue? Not sure I follow. Why not write another migration that converts all of those float fields into decimal fields? -philip
> > Query 3 > > I know the hazards of using floats. .....they will ditch me on > > customer''s machine only.....but I have already written some 20 > > migrations using float as data type.. Is there any safe way to rescue > > if I know I am storing the price and it will always be within 0 and > > 9999(.00) > > Safe way to rescue? Not sure I follow. Why not write another > migration that converts all of those float fields into decimal fields? > > -philipI agree with you Phillip. I am switching to decimal. My project is in early stage. Instead of adding one more migration I want to change the migrations itself. I certainly would do it after $rake db:rollback I hope that should not create any issue. the reason i want to avoid adding another migration is it will create another confusion for future developers -vipin
>>> Query 3 >>> I know the hazards of using floats. .....they will ditch me on >>> customer''s machine only.....but I have already written some 20 >>> migrations using float as data type.. Is there any safe way to >>> rescue >>> if I know I am storing the price and it will always be within 0 and >>> 9999(.00) >> >> Safe way to rescue? Not sure I follow. Why not write another >> migration that converts all of those float fields into decimal >> fields? >> >> -philip > > I agree with you Phillip. I am switching to decimal. My project is in > early stage. Instead of adding one more migration I want to change the > migrations itself. > I certainly would do it after > > $rake db:rollback > > I hope that should not create any issue. > the reason i want to avoid adding another migration is it will create > another confusion for future developersIf you''re in the early stages of development and redoing a migration won''t mess up anything, there''s no harm in doing it. I do that all the time. Many times I''ll create a handful of migrations early on, adding fields here and there and then once it''s all gelled and I''m happy will merge them all into an initial migration -- for the exact reasons you mentioned. The only time this isn''t an option is if you''ve deployed to production and would lose changes or if it would seriously mess up other developers. -philip