Sebastian Bergmann has posted about a new contest to his blog today centering around the phpOpenTracker software.

After two years in which I did not have the time to work on it, the development of phpOpenTracker is slowly commencing again. The first step to restart the development has been the migration from BerliOS to a Trac setup that is generously provided by Tobias Schlitt.

While setting up Trac it occured to me that I do not have a logo for phpOpenTracker. To get to such a logo I try something new: I ask you to participate in the phpOpenTracker Logo Contest.

He sets up some rules for the competition including that the design should convey flexibility and that the winner's work will go under the Creative Commons Attribution-NonCommercial-NoDerivs 2.5 license. Check out the post, though, for the full details on rules and submission guidelines.

Sebastian Bergmann has posted about a new contest to his blog today centering around the phpOpenTracker software.

After two years in which I did not have the time to work on it, the development of phpOpenTracker is slowly commencing again. The first step to restart the development has been the migration from BerliOS to a Trac setup that is generously provided by Tobias Schlitt.

While setting up Trac it occured to me that I do not have a logo for phpOpenTracker. To get to such a logo I try something new: I ask you to participate in the phpOpenTracker Logo Contest.

He sets up some rules for the competition including that the design should convey flexibility and that the winner's work will go under the Creative Commons Attribution-NonCommercial-NoDerivs 2.5 license. Check out the post, though, for the full details on rules and submission guidelines.

In a new blog entry from Sebastian Bergmann, he looks at some of the issues and bugs that have been submitted to him about the phpOpenTracker project. He takes on one in particular - the database schema.

The biggest problem with phpOpenTracker 1.x is that its database schema is normalized. Even simple phpOpenTracker API calls result in (possibly multiple) SQL queries that involve multiple tables. [...] While the denormalization should eliminate the JOIN-related performance problems, temporal partitioning of the data can further increase the performance.

He talks about what kind of support MySQL currently has for it (5.1) and how, unfortunately, it might not work for his situation (the maximum number of partitions).

In a new blog entry from Sebastian Bergmann, he looks at some of the issues and bugs that have been submitted to him about the phpOpenTracker project. He takes on one in particular - the database schema.

The biggest problem with phpOpenTracker 1.x is that its database schema is normalized. Even simple phpOpenTracker API calls result in (possibly multiple) SQL queries that involve multiple tables. [...] While the denormalization should eliminate the JOIN-related performance problems, temporal partitioning of the data can further increase the performance.

He talks about what kind of support MySQL currently has for it (5.1) and how, unfortunately, it might not work for his situation (the maximum number of partitions).