Return to Answer

This question was also asked on StackOverlow.

The top answer suggests the MySQL Spatial Extensions. There are a load of links on working with these extensions here.

If you don't want to use spatial types and you are getting values from a GPS unit, or geocoding service then you can match your decimal precision to the data source. A general rule of thumb is to store data to an accuracy of two places greater than you will be displaying it in an application.

In a code example from Google displaying points on a map, they state:

When you create the MySQL table, you want to pay particular attention to the lat and lng attributes. With the current zoom capabilities of Google Maps, you should only need 6 digits of precision after the decimal.

To keep the storage space required for our table at a minimum, you can specify that the lat and lng attributes are floats of size (10,6). That will let the fields store 6 digits after the decimal, plus up to 4 digits before the decimal, e.g. -123.456789 degrees

I wouldn't worry about performance differences between numeric types. Decent indices will have a far greater effect.

This question was also asked on StackOverlow.

The top answer suggests the MySQL Spatial Extensions. There are a load of links on working with these extensions here.

If you don't want to use spatial types and you are getting values from a GPS unit, or geocoding service then you can match your decimal precision to the data source. A general rule of thumb is to store data to an accuracy of two places greater than you will be displaying it in an application.

In a code example from Google displaying points on a map, they state:

When you create the MySQL table, you want to pay particular attention to the lat and lng attributes. With the current zoom capabilities of Google Maps, you should only need 6 digits of precision after the decimal.

To keep the storage space required for our table at a minimum, you can specify that the lat and lng attributes are floats of size (10,6). That will let the fields store 6 digits after the decimal, plus up to 4 digits before the decimal, e.g. -123.456789 degrees

I wouldn't worry about performance differences between numeric types. Decent indices will have a far greater effect.

This question was also asked on StackOverlow.

The top answer suggests the MySQL Spatial Extensions. There are a load of links on working with these extensions here.

Also if you are getting values from a GPS unit, or geocoding service then you can match your decimal precision to the data source. A general rule of thumb is to store data to an accuracy of two places greater than you will be displaying it in an application.

In a code example from Google displaying points on a map, they state:

When you create the MySQL table, you want to pay particular attention to the lat and lng attributes. With the current zoom capabilities of Google Maps, you should only need 6 digits of precision after the decimal.

To keep the storage space required for our table at a minimum, you can specify that the lat and lng attributes are floats of size (10,6). That will let the fields store 6 digits after the decimal, plus up to 4 digits before the decimal, e.g. -123.456789 degrees

I wouldn't worry about performance differences between numeric types. Decent indices will have a far greater effect.

This question was also asked on StackOverlow.

The top answer suggests the MySQL Spatial Extensions. There are a load of links on working with these extensions here.

If you don't want to use spatial types and you are getting values from a GPS unit, or geocoding service then you can match your decimal precision to the data source. A general rule of thumb is to store data to an accuracy of two places greater than you will be displaying it in an application.

In a code example from Google displaying points on a map, they state:

When you create the MySQL table, you want to pay particular attention to the lat and lng attributes. With the current zoom capabilities of Google Maps, you should only need 6 digits of precision after the decimal.

To keep the storage space required for our table at a minimum, you can specify that the lat and lng attributes are floats of size (10,6). That will let the fields store 6 digits after the decimal, plus up to 4 digits before the decimal, e.g. -123.456789 degrees

I wouldn't worry about performance differences between numeric types. Decent indices will have a far greater effect.

This question was also asked on StackOverlow: http://stackoverflow.com/questions/159255/what-is-the-ideal-data-type-to-use-when-storing-latitude-longitudes-in-a-mysql

The top answer suggests the MySQL Spatial Extensions.

Also if you are getting values from a GPS unit, or geocoding service then you can match your decimal precision to the data source.

In a code example from Google displaying points on a map, they state:

When you create the MySQL table, you want to pay particular attention to the lat and lng attributes. With the current zoom capabilities of Google Maps, you should only need 6 digits of precision after the decimal.

To keep the storage space required for our table at a minimum, you can specify that the lat and lng attributes are floats of size (10,6). That will let the fields store 6 digits after the decimal, plus up to 4 digits before the decimal, e.g. -123.456789 degrees

I wouldn't worry about performance differences between numeric types. Decent indices will have a far greater effect.

This question was also asked on StackOverlow.

The top answer suggests the MySQL Spatial Extensions. There are a load of links on working with these extensions here.

Also if you are getting values from a GPS unit, or geocoding service then you can match your decimal precision to the data source. A general rule of thumb is to store data to an accuracy of two places greater than you will be displaying it in an application.

In a code example from Google displaying points on a map, they state:

When you create the MySQL table, you want to pay particular attention to the lat and lng attributes. With the current zoom capabilities of Google Maps, you should only need 6 digits of precision after the decimal.

To keep the storage space required for our table at a minimum, you can specify that the lat and lng attributes are floats of size (10,6). That will let the fields store 6 digits after the decimal, plus up to 4 digits before the decimal, e.g. -123.456789 degrees

I wouldn't worry about performance differences between numeric types. Decent indices will have a far greater effect.