Fatal Abstraction

There is an attraction to abstraction. It makes things seem simpler than they are.

The risk is that hiding complexity doesn't mean it goes away, but it can make it harder to manage.

I admit to being a bit hypocritical here. I understand that ultimately there are bits and bytes on some spinning disk (or, potentially, flash chips). They get abstracted into files in file system (probably with some form of RAID redundancy). Which then turn into tablespaces, and then into tables and indexes full of data. And indexes are automagically manipulated alongside the associated tables.

However, while I don't understand the details, I can see the layers.

I can get enough information out of the database to work out while file and block relates to particular data items. In some cases, I can even work out which volume that might relate to. Anything below that is for system or storage administrators, or a DBA if their duties extend to that level. Equally, if the storage admins come to me reporting unbalanced activity, then I'm able to discuss how segments can be moved to different tablespaces to restore the balance.

Application development, especially that relying on object and inheritance, has the difficulty of surrounding an issue in so many layers of onion skins that it becomes difficult to diagnose and resolve an issue. At the database layer we might be able to observe poorly performing SQL or logic. It is the responsibility of mid-tier developers to be able to take those issues and respond to them in their layer.

This article was written by Gary Myers, and is filed under "Oracle Database Development - A View from Sydney'. It covers application development and abstraction.