Linked by Mo Mckinlay on Fri 31st Oct 2003 17:35 UTC
There's been much discussion over the past few months about the marriage of databases and filesystems - with Microsoft's Longhorn reportedly sporting the
Yukon integrated SQL Server, and GNOME Storage in heaty debate, if not development, there's been lots to talk about.
Permalink for comment
To read all comments associated with this story, please click here.
What's interesting here, not knowing much of anything about the OS/400 platform, is how little of it has drifted into the OSS space.
I'm sure that this system works well on IBM systems because of how tightly integrated it is.
Perhaps the have a thin POSIX layer on top of this system that converts their DB based files into POSIX like streams, because that is probably the key difference between UNIX systems and others. I know the VAX had several structured files that were more than just blobs-o-bytes.
I wonder what the Java API for dealing with their local data is. Write once, run anywhere (on any AS/400, that is..). Never heard if Sun sued IBM over that or not...
The issue of whether to use something like a SQL database for storage has been more an issue with availability than anything else. If there was an integrated DB in the system, with a single instance, then connecting to it would be no more "heavyweight" than "open", you'd just have a more sophisticated parameter list.
Of course, it would be best if the DB were integrated into the kernel for performance.
One nice assumption that can be made is that a local DB can punt on using SQL, and use something more efficient. SQL is wonderful, but wordy. Dealing with a "pre-parsed", binary structure would be more efficient for native applications, particularly for simply bulk inserts and bulk reads.
And that's what a modern rich filesystem will do anyway. They may have a SQL layer for it, but the API will be more akin to something like Berkeley DB (well, hopefully something a little bit richer, a little higher level).
But truly, after all of these years, I keep hearing about Neat Stuff in the AS/400 systems and their architecture, yet have never seen a set of utilities or systems "inspired" by the AS/400 in the wild, at least none that give credit.
What's interesting here, not knowing much of anything about the OS/400 platform, is how little of it has drifted into the OSS space.
I'm sure that this system works well on IBM systems because of how tightly integrated it is.
Perhaps the have a thin POSIX layer on top of this system that converts their DB based files into POSIX like streams, because that is probably the key difference between UNIX systems and others. I know the VAX had several structured files that were more than just blobs-o-bytes.
I wonder what the Java API for dealing with their local data is. Write once, run anywhere (on any AS/400, that is..). Never heard if Sun sued IBM over that or not...
The issue of whether to use something like a SQL database for storage has been more an issue with availability than anything else. If there was an integrated DB in the system, with a single instance, then connecting to it would be no more "heavyweight" than "open", you'd just have a more sophisticated parameter list.
Of course, it would be best if the DB were integrated into the kernel for performance.
One nice assumption that can be made is that a local DB can punt on using SQL, and use something more efficient. SQL is wonderful, but wordy. Dealing with a "pre-parsed", binary structure would be more efficient for native applications, particularly for simply bulk inserts and bulk reads.
And that's what a modern rich filesystem will do anyway. They may have a SQL layer for it, but the API will be more akin to something like Berkeley DB (well, hopefully something a little bit richer, a little higher level).
But truly, after all of these years, I keep hearing about Neat Stuff in the AS/400 systems and their architecture, yet have never seen a set of utilities or systems "inspired" by the AS/400 in the wild, at least none that give credit.