decimal or float

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)

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 23456

That 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?

-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 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 developers

If 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