My three previous blog posts I already wrote from Froscon. In this post I still want to go back and mention some people I met and discussions I had.
The MySQL side
There were of course many MySQL people, with both SkySQL and Oracle sponsoring. It was great to meet Carsten from Oracle, who has joined the MySQL Sales Engineer team in Europe (he moved from an OpenOffice position). That's my former team, so it was great to see a new face!
Going there the person I was most looking forward to meet was Hana Hütter, formerly a MySQL account manager for Central Europe, and now doing the same at SkySQL. My first ever MySQL sales gig was with Hana, and Ralf Gebhart who is also now with SkySQL but was not at Froscon. While Ralf was there only that first time to teach me how to be a Sales Engineer, with Hana we then continued to sell MySQL into telecom companies in many European cities. I had not met Hana since I left Sun. It was really great to see again. We had lunch, I told about my experiments with Galera and she told about her customers being interested in it too. It was great to get in touch with the "frontlines" again!
She also told me a great story about MySQL adoption in Europe...
People often assume the reason I talk at conferences is because I like to teach them about Galera, MySQL and other cool, open source things. That's of course true to some extent. But for me personally, another reason is even more important: It happens almost always that the audience teaches me something. Thus the process of public speaking has increasingly become my way to learn new insights. Low level details that aren't easy to learn by just RTFM.
Here are the slides of the talk I just gave at Froscon. (Video should be available soon.)
I promised to still post some general comments about the MySQL ecosystem, to conclude my outlook of State of the MySQL forks and Drizzle. I will do this now in the form of answering questions I got in the comments, twitter and some that I make up just myself.
I got several comments and questions on my previous blog "The State of the MySQL forks". One question was "Why didn't you mention Drizzle?" So I will say something about Drizzle here before concluding with other remarks.
So why didn't you mention Drizzle?
Mainly because the post was already long and also I had to wrap up and call into a meeting.
It's been some time since I last wrote an overview of the state of the MySQL forks, but the last few weeks have been eventful enough that it is a good time to again see how the competing variants are positioned against each other.
I have written on this topic 1-2 times a year. Here are links to the previous overviews:
Map of MySQL forks and branches (2010)
The state of MySQL forks: co-operating without co-operating (2010)
Observations on Drizzle and PostgreSQL
Percona.tv: State of the MySQL ecosystem (2011)
State of the MySQL forks: via a particular example of authentication plugins
As is the case with this post, many of those previous ones coincide with some events or discussion at the time they were written, and the posts contain links to other bloggers commenting on whatever was current then.
In my quest to understand spatial GIS functionality, I have come to the ultimate goal: evaluation the actual database products themselves.
PostgreSQL / PostGIS
PostGIS is a variant of PostgreSQL with spatial extensions. The main reason for maintaining the GIS feature set outside of PostgreSQL proper seems to be licensing: the spatial extensions are
LGPL GPL licensed.
PostGIS is widely recognized as the most mature and feature-rich GIS implementation for SQL databases (and perhaps any database), matched only by the costly Spatial extension for the Oracle Enterprise database. (See comparisons in the links below.)
While the underlying index should be opaque to the user of a DBMS with spatial features, the API used to define spatial types and operate on them is of course more visible. The relevant standard in this space is often referred to as "OpenGIS", however the Open Geospatial Consortium in fact defines a long list of standards. The standard relevant to SQL databases is known more precisely as "OpenGIS Implementation Specification for Geographic information - Simple feature access - Part 2: SQL option" aka "Simple feature access".
It is not meaningful to recite the standard at length in my blog, my focus is instead on actual implementations that I will blog about later. The following points are however worth noting: