I've been thinking about this for awhile. After working on an Auction Management System for one of the many ebay consignment companies, working on my own home page and other smaller utility scripts, I came up with this idea of a data access abstraction layer.

This doesn't have to apply to just for php. When I am writing my web application, I think about (and maybe like to) the raw SQL to access and modify my data storage. It takes awhile to really grasp that, just like you don't want HTML in your code, do your really want your SQL in your application? Maybe. Probably not.

What Smarty does for PHP and HTML, I want something to do this for PHP and SQL/XML.

Not sure about most of you, but I love hashes (associative arrays). This, by far, is why I love php/perl and use it. [ Second reason is the foreach statements, if you care. ] I'll often use perl (or php) instead of shell, just for these reasons.

So, when I'm writing my web application (or sys admin script), I'll want a couple common things. Some sort of argument processing, a configuration file, and then access to the data. Quite honestly, when writing the script or application, I don't want to think about the XML structure of the config file, or the table structure and SQL syntax of the database. I just want to say "get" data, and set/update data, and I want this done in like two or three lines, and I want the results in hashes. Something along the lines of ...

$verbose = $arg["verbose"] ;

or

if ( $user[$userid]["password"] == $arg["password"] ) { ... }

... and at these points, I don't really care if its in MySQL, Postgres, XML, BDB, or INI files. At this point in the code, I don't want to be thinking about "SELECT ..." .

All the database abstraction layers I've seen and found want to wrap the drivers, but still seem to let the SQL get push up to the top. Why ? Well, I guess that is not the goal of database abstraction. I guess that is what I want too, but I want another layer, data access abstraction. I want an object that can get, set, update, insert, and search. If I want to prototype with XML files, locally, then move to a database later, I shouldn't have to change the application code, just the configuration for the data access layer.

I was kind of hoping someone (with better OO design skills) had made a simple, lightweight version of this. I am planning on writing this myself, but the exact design (and time) is escaping me. This idea, if not clear yet, is :

Application
---> data access abstraction
---> storage implementers (mysq, pgres, xml, ini)
---> storage


What is important, is that the application layer contain nothing specific to tie that code to the specific storage. The DAA layer should read the configuration file, select the storage implementation (plugin?, module ?), and setup the data to object mappings.

There will be limitations, of course, with this idea. Some of then advances uses of databases may get blocked. Not sure what they all are, as I probably don't use them. Because, DAA needs to be kind of blind to specific storage features, and the application cannot know about them either. So, if they can't be implemented in the plugin/module, and selected via a configuration file, then they can't be used. I'll accept this limitation.

My data storage requires are: MySQL, XML Files, and LDAP. I'd prefer configuration files in XML, but if you can convince me INI is better ...

K.I.S.S cell phones prompted this thought. How much I like sprintpcs but their hardware line up sucks. Yes, I am a mac user. I also bought the much hyped, and Sprint killed Sony Ericsson T608 CDMA Bluetooth phone. Its freaking slow (interface), battery sucked (replaced it with a hong kong mail order). Over all has held up nicely, and each new phone I got performs better on the network then the previous. I'd really use SMS if I had it.

Best phone EVER, for its time too, was the Nokia 6185. They got it right. The Apple of Cell phone interfaces.

Finally some stupid higher up figured out that that damn stupid short mail browser for SMS doesn't cut it, and now sprint has SMS-enabled phones. Granted my t608 is suppose to support SMS, but Sprint crippled it. There is a hack to enable SMS, but reports say using it then crashed the phone. There is another REALLY COOL looking phone. PM-325, bluetooth, sms. However, Sprint Crippled bluetooth on it. No data. So I can't sync my address book ? What's the point of having bluetooth in this damn phone ! Bluetooth headset ? How dumb.

Ok, in the past, you used to only be able to buy your analog phone from the the phone company. Now ... you can buy any telephone, anywhere (in the US I assume) and plug it in. It would only be right for the wireless providers to allow ANY complaint phone to log onto their network. Now they can still do the phone deals ... but if I want an SMS, CDMA, Nokia WITH NO DAMN Camera .. why not ? If I want to pay full price for a phone, $300-400 ... I should be able to. And I should also be allowed a lower monthly plan, since I don't have to make up the cost of the phone to the service provider.

Who else has an issue with Camera's in their phones ? In the bar, ok, fine. Meet a cute girl. She snap some phone photos. As an IT/tech person, there is s fear that at some point soon, you'll have to check your phone at the door, because of NDAs and taking photos into secure installations. I'd like the option not having it physically in my phone. Web, email, SMS, PIM, even viewing pictures - ok for my phone. The Camera in it seems like a strange evolution. Music is also another odd feature for a phone.

There has been a lot of flap on slashdot about the device integration, a la Microsoft's new embedded OS. There is only so much I want a single device to do. And the article on the whole simplified cell phones prompted this. This is a case where less is more.

If there is a Sprint/Sony person out there, with a rev of the T608 firmware, that enables SMS, and puts the correct file system on the phone to improve performance ... I'd be interested in a software patch. As it looks like another couple years before Sprint gets a clue.

I work for SBC, and Cingular has some better phones, sms, etc. So I'm thinking about switching. Have you ever heard that if you worked in the kitchen - you wouldn't eat the food.