postgresql iconcatalyst iconperl iconmysql icontypo iconphp icon

Database Abstraction - code vs infrastructure

Posted in , , , , , , 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.

del.icio.us:Database Abstraction - code vs infrastructure digg:Database Abstraction - code vs infrastructure reddit:Database Abstraction - code vs infrastructure spurl:Database Abstraction - code vs infrastructure wists:Database Abstraction - code vs infrastructure simpy:Database Abstraction - code vs infrastructure newsvine:Database Abstraction - code vs infrastructure blinklist:Database Abstraction - code vs infrastructure furl:Database Abstraction - code vs infrastructure fark:Database Abstraction - code vs infrastructure blogmarks:Database Abstraction - code vs infrastructure Y!:Database Abstraction - code vs infrastructure smarking:Database Abstraction - code vs infrastructure magnolia:Database Abstraction - code vs infrastructure segnalo:Database Abstraction - code vs infrastructure

6 comments

mysql icon

MySQL Deployment Presentations

Posted in , 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:

MySQL Web2.0

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...
del.icio.us:MySQL Deployment Presentations digg:MySQL Deployment Presentations reddit:MySQL Deployment Presentations spurl:MySQL Deployment Presentations wists:MySQL Deployment Presentations simpy:MySQL Deployment Presentations newsvine:MySQL Deployment Presentations blinklist:MySQL Deployment Presentations furl:MySQL Deployment Presentations fark:MySQL Deployment Presentations blogmarks:MySQL Deployment Presentations Y!:MySQL Deployment Presentations smarking:MySQL Deployment Presentations magnolia:MySQL Deployment Presentations segnalo:MySQL Deployment Presentations

2 comments

perl iconmysql iconunicode icon

Perl, MySQL and UTF-8

Posted in , , , 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...
del.icio.us:Perl, MySQL and UTF-8 digg:Perl, MySQL and UTF-8 reddit:Perl, MySQL and UTF-8 spurl:Perl, MySQL and UTF-8 wists:Perl, MySQL and UTF-8 simpy:Perl, MySQL and UTF-8 newsvine:Perl, MySQL and UTF-8 blinklist:Perl, MySQL and UTF-8 furl:Perl, MySQL and UTF-8 fark:Perl, MySQL and UTF-8 blogmarks:Perl, MySQL and UTF-8 Y!:Perl, MySQL and UTF-8 smarking:Perl, MySQL and UTF-8 magnolia:Perl, MySQL and UTF-8 segnalo:Perl, MySQL and UTF-8

8 comments

perl iconmysql iconxapian icon

Encoding Hashed UIDs: Base64 vs. Hex vs. Base32

Posted in , , 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...
del.icio.us:Encoding Hashed UIDs: Base64 vs. Hex vs. Base32 digg:Encoding Hashed UIDs: Base64 vs. Hex vs. Base32 reddit:Encoding Hashed UIDs: Base64 vs. Hex vs. Base32 spurl:Encoding Hashed UIDs: Base64 vs. Hex vs. Base32 wists:Encoding Hashed UIDs: Base64 vs. Hex vs. Base32 simpy:Encoding Hashed UIDs: Base64 vs. Hex vs. Base32 newsvine:Encoding Hashed UIDs: Base64 vs. Hex vs. Base32 blinklist:Encoding Hashed UIDs: Base64 vs. Hex vs. Base32 furl:Encoding Hashed UIDs: Base64 vs. Hex vs. Base32 fark:Encoding Hashed UIDs: Base64 vs. Hex vs. Base32 blogmarks:Encoding Hashed UIDs: Base64 vs. Hex vs. Base32 Y!:Encoding Hashed UIDs: Base64 vs. Hex vs. Base32 smarking:Encoding Hashed UIDs: Base64 vs. Hex vs. Base32 magnolia:Encoding Hashed UIDs: Base64 vs. Hex vs. Base32 segnalo:Encoding Hashed UIDs: Base64 vs. Hex vs. Base32

no comments

mysql icon

Lessons from MySQL

Posted in , 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?

del.icio.us:Lessons from MySQL digg:Lessons from MySQL reddit:Lessons from MySQL spurl:Lessons from MySQL wists:Lessons from MySQL simpy:Lessons from MySQL newsvine:Lessons from MySQL blinklist:Lessons from MySQL furl:Lessons from MySQL fark:Lessons from MySQL blogmarks:Lessons from MySQL Y!:Lessons from MySQL smarking:Lessons from MySQL magnolia:Lessons from MySQL segnalo:Lessons from MySQL

no comments

mysql icontypo iconapache iconlighttpd icon

Birth of a Typo Blog

Posted in , , , 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.

del.icio.us:Birth of a Typo Blog digg:Birth of a Typo Blog reddit:Birth of a Typo Blog spurl:Birth of a Typo Blog wists:Birth of a Typo Blog simpy:Birth of a Typo Blog newsvine:Birth of a Typo Blog blinklist:Birth of a Typo Blog furl:Birth of a Typo Blog fark:Birth of a Typo Blog blogmarks:Birth of a Typo Blog Y!:Birth of a Typo Blog smarking:Birth of a Typo Blog magnolia:Birth of a Typo Blog segnalo:Birth of a Typo Blog

no comments