- Spatial databases. These are datatypes such as point, polygon and geometry etc.
- Spatinal functions. These are functions like distance, size and also functions that check for relations between spatial objects, such as contains and overlaps.
- Spatial indexing. This is typically R-Tree indexes (R for Rectangle) that can be applied when using the Spatial functions above.
And as if this wasn't enough, only MyISAM supports R-Tree indexing, and not all Storage Engines supports the Spatial (GIS) datatypes.
Thirdly, MySQL can only work with a flat or euclidic coordinate system. This is a disadvantage and will introduce an error, in particular when used with larger geometries, as the world really isn't flat. At least that wasn't the case last time I looked.
And the drawbacks I mention above are just the most basic ones, there are a few more minor omissions and issues.
So are we doomed now when it comes to GIS functions with MySQL? Nope, there has been some work done to fix this. On MySQL Forge you can find a GIS Functions document, about a fix to these issues. This has also been implemented in a variation of MySQL 5.1.23 that is available for download. In addition, the is a talk at the MySQL User Conference on this subject.
So there is hope, and I have a plea for you: Support me in having the 5.1.23 implementation I mention above become part of standard MySQL. There is no reason not to do this, in my mind, but for some reason, it's not happening. Also, download this code, I'd be really happy if someone would want to use this code and develop it further. So yes, there is hope!
And I'll do some more blogging on this subject, if nothing else, I will discuss ways around the current limitations of Spatial Support in MySQL.