Posted in postgresql, catalyst, activerecord, perl, mysql, typo, php
Wed, 05 Sep 2007 04:38:00 GMT
I've worked on a number of database-driven projects and no matter how much people want database abstraction, it was always difficult to code and maintain. I was recently reminded of this when I read this Drupal article on dropping PostgreSQL support. Not only can it be difficult to maintain support for multiple databases, but it may be difficult to find developers.
One solution of modern programming is to move database abstraction from the code to the infrastructure using a ORM (Object-Relational Mapper) or Data Mapper. A ORM and Data Mapper abstracts the database for you so you no longer have to do tie db abstraction to each app. Not only does it let you code once for multiple databases it lets your users migrate their data from one database to another. This blog runs Typo which is based on Ruby on Rails and ActiveRecord. I've been contemplating migrating Typo from MySQL to PostgreSQL and I've been told that it would be as simple as exporting the data with YAML, updating the database.yml file and importing the data. I haven't gotten around to doing it yet but it is a powerful idea. ActiveRecord is a data mapper and isn't as flexible as a full blown ORM but it gets the job done for the most part. For a full-blown ORM, I think of Perl's DBIx::Class which provides a full OO interface to the RDBMS allowing you to code just once for multiple DBs without limiting you when you want to use some esoteric database-specific SQL. DBIx::Class is often used with the Catalyst Framework but is also used by itself.
There are PHP frameworks out there like Symfony and Cake but do any of them have stand-alone ORMs? If so, could Drupal move to something like that and solve their maintainership problems once and for all? Drupal is part of the Go PHP5 effort so there should be no issue using PHP 5 OO. Something to think about for the Drupal folks if a PHP ORM is available.
6 comments
Posted in scalability, mysql
Fri, 06 Oct 2006 03:07:00 GMT
I just ran across the MySQL Web 2.0 page which lists a number of their users including the following:
The most interesting thing from that page, however, is links to various presentations given by those sites on how they architected their sites to scale with MySQL, some of them scaling up to hundreds of MySQL servers.
Read more...
2 comments
Posted in perl, mysql, unicode, orm
Mon, 02 Oct 2006 15:35:00 GMT
One of the mysteries of Perl to me is that why, as of yet, is there no UTF-8 support in DBD::mysql although this issue has been discussed on the msql-mysql-modules list since at least 2003 (using the MARC archives). This is also given that MySQL does have UTF-8 support itself.
Read more...
8 comments
Posted in perl, mysql, xapian
Mon, 02 Oct 2006 08:08:00 GMT
I recently looked at using various encodings for hashed UIDs, e.g. UIDs generated by a crytographic hash algorithm such as SHA-1 or MD5. These are often useful when the UID does not need to have human meaning but should exhibit some uniformity, such as character set and length. I considered Base64 and hexadecimal first because they are commonly used by crypto libraries and then decided on Base64 and Base32 where appropriate. Base36 is actually the most compact case insensitive encoding (using Arabic numbers and Roman letters) but is not an option for me at the moment because there's no Perl module for it that will take arbitrary text and binary input at the moment. Math::Base36 exists but only handles numbers.
Read more...
no comments
Posted in hiring, mysql
Mon, 26 Jun 2006 21:36:00 GMT
I picked up a copy for Fortune Magazine's Secrets of Greatness: Teamwork! issue for the flight to YAPC::NA. There was an insightful article on MySQL. MySQL has 350 workers in 25 countries and 70% of them telecommute. This structure has led to some hiring practices contrary to the norm in other organizations.
- Employee characteristics: Given the decentralized nature of its organization, MySQL for skills, not the ability to play nice with a team.
- Finding talent: MySQL finds some of its talent (50+ employees) through open source cntributions to its code base. Others also look for developers among those that actively check in good code.
- Work schedule: CEO Marten Mickos says:
The brightest engineers like the calmness and coolness of the night
and likes hearing the following from prospective employees:question: How do you plan your day?
answer: I always sleep until 11 A.M., and then I start working
While working late at night seemed common when I was in college, when I got to the workplace many developers seemed to work a regular schedule leaving around 5-6pm, albeit in a regular office environment as opposed to MySQL's telecommuting environment. Do you like to work at night and is it common to come in "late" and work late at places other than MySQL? Also, in a non-telecommunting situation, is this mostly for developers without kids? If you do have a start late / work late schedule, why do you like it and what time to you tend to start work?
no comments
Posted in mysql, typo, apache, lighttpd
Wed, 21 Jun 2006 22:04:00 GMT
I'm giving Typo a shot after hearing some good things about it and having performance problems at a hosted blog service. It's been pretty good so far. Let's see how it runs in action.
I'm currently using the Lucid theme. So far I've played with Azure (the default), Lucid and Phokus. The default font size seems smaller than normal on other sites. Let me know if it's too small or there are other issues.
Up until now, my wiki has been the only app at this domain. I'm leaning towards putting commentary, questions, short summaries and the like in the blog while the wiki would still contain reference type information. To that end, I put up some detailed Typo install instructions covering MySQL, Apache, lighttpd and FastCGI on the wiki. Right now it just covers installation as I'm just getting into customizing the template. Let me know what you think.
no comments