Good questions.... I too have kept an eye out for MySQL, but thus far this is my opinion.
The Spatial component is being developed as a "science experiment" / prototyping space. It is not a production environment (for spatial support) in my opinion. I am not trying to condemn it, it is just in early development and this should be taken into consideration. >From what I have read about the spatial component it intends to support OGC specifications, but does not currently do so. While I believe it will the questions are when and how will it be supported? There is far it has less "functionality" than with SpatialWare on SQL Server or Oracle Spatial in terms of geometry types supported, spatial indexing (The R-tree indexing is relatively new), compare the operators between any of the products and you will see the differences. In general there are limitations with MySQL, for example stored procedures are new for MySQL, and have limitations. I don't know if spatial can be used in stored procedures at all. I believe there is potentially an underlying problem within MySQL that may have a number of ramifications. It is exhibited by the fact that that the OGC length() function can not be implemented using the "length" operator. At first glance you may say "so what, call it Glength for geometry length. My fear is that it exhibits an underlying architectural problem with MySQL, is there no support or problems when overloading function names? (I don't know the answer to this yet, but it has peaked my interest. MyISAM storage is essentially enhancements to the original ISAM storage architecture. ISAM / MyISAM is a "library" of functions that provide database functionality on operating system files. MapInfo TAB files are based on ISAM libraries. MyISAM do not have Transaction support. This is provided by the Berkley DB (BDB) storage extensions. SO, currently, Spatial is not supported in a transaction environment with MySQL. My last comment for now... I still think MySQL will become (future tense) a viable database to use for supporting spatial data. The final thing needed is support on the client side. At the moment you should be able to make an ODBC connection, but the spatial data will need to be extracted in OGC WKT or WKB format then transformed into a MapInfo geometry. A better solution will be for MapInfo, or more likely OpenSource to construct an OBDC driver and casting functions to support MySQL binary to MapInfo Object. The last hurdle would be replication / support for the Mapinfomapcatalog to provide the metadata support for coordinate system, symbology, column names, etc. -----Original Message----- From: Evan MacDougall [mailto:[EMAIL PROTECTED] Sent: Thursday, April 08, 2004 01:28 PM To: MapInfo-L (E-mail) Subject: MI-L MySQL 4.1 Does anybody have any experience with using MySQL 4.1 which uses the OpenGIS geometry model to store spatial data as opposed to using Oracle, etc? "MySQL 4.1 introduces spatial extensions to allow the generation, storage, and analysis of geographic features. Currently, these features are available for MyISAM tables only." I'm pretty lost so far, but if anyone can answer my questions, i present them to you here. 1. How does MySQL compare to Oracle when used as a spatial database for storage, analysis, fetching, editing? Can I do with it what I am already doing with Oracle? 2. How does using MySQL compare to using Oracle in terms of speed and robustness? 3. Can you use MapInfo and MySQL as you would use MapInfo with an Oracle database? 3b. Is using MapInfo and MySQL as or more effective than using MapInfo with Oracle? Are there problems/issues? That's good for starters. If anyone can respond to these I would really appreciate it. I will probably have more questions after this. Thanks in advance! -Evan MacDougall GIS Supervisor - DPSI [EMAIL PROTECTED] (800)736-3109/(310)342-3600 - ext. 3681 --------------------------------------------------------------------- List hosting provided by Directions Magazine | www.directionsmag.com | To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Message number: 11347
