hingo's blog

hingo's picture

Froscon: How big corporations play the open source game

Here are the slides of the talk I just gave at Froscon. (Video should be available soon.)

hingo's picture

State of the MySQL forks - conclusions

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.

Oracle has not stopped updating bzr trees

hingo's picture

But what about Drizzle?

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.

hingo's picture

State of the MySQL forks

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.

hingo's picture

Comparing open source GIS implementations

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.)

hingo's picture

The OpenGIS standard

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:

hingo's picture

Spatial data structures

I work for a company that is the leading supplier of automotive maps, and wants to be the leading supplier of online maps. So it was only a matter of time that I needed to learn more about how spatial extensions work in different open source databases. Let's start from the beginning, understanding various spatial data structures that are used in implementations...

Links are provided to Wikipedia articles - which are both comprehensive, yet easy to understand - for those who want to get a deeper understanding of each structure. All Wikipedia articles on spatial indexes are listed here: http://en.wikipedia.org/wiki/Spatial_index#Spatial_index


hingo's picture

Date objects in JSON

Flavio of MongoDB fame complained in a tweet about wanting a date format in JSON. Currently you can only express strings and numbers as the primitive data types in JSON, as well the composite forms of a list: [] and an object: {}. The latter is essentially just a subhierarchy in the object/array that is your full JSON document.

i wonder why there's no "STANDARD" way to (de)serialize times / date times into / from json! They might not be "primitive" but COME ON!!

Syndicate content