Glenn,
Well, the gremlins ate my first response but I felt a lot of your
points
were worthy of a little further discussion.
> Agreed. Hope I didn't come across as suggesting that any of those
> criticisms applied to you personally. I was just attempting to survey
> the pros and cons.
No, no, I don't get agitated over database discussions. Too much early
exposure to zealotry.
> I would certainly agree about the object part.
Well, this is one of the great failures of modern IT. We have powerful
databases and powerful programming environments, and the two don't really
see eye-to-eye. And somehow LINQ doesn't strike me as the answer.
> Look, I don't maintain that blobs have no place whatsoever in a
> database, just that it seldom makes sense to use blobs instead of the
> file system when the file system actually does a better job of that in
> the first place. For example, network connections to a file server
> usually
> involve sophisticated features which allow the client to cache
> the file (or parts of it). This feature greatly enhances data access to a
> file that isn't changing frequently, like an mp3 file. I have not heard
> anything about client caching of blob data that would reduce network
> traffic and increase performance in the way the file system would.
Well, this is another great failure. Permanent storage is, eseentially, a
database. As a matter of fact, it's a database of blobs.<s> But users want
to be able to search the contents which, theoretically, should be easy
enough given that the OS knows which applications read those files.
> The way we do this, when there is a requirement to synchronize something
> in the file contents with other data, is store the file name, size, and
> timestamp in the database. The application can then determine
> immediately if the file is out of date with respect to the other data
> and run a process to synchronize before the file is accessed. However, I
> will agree that you have a point if it is critical that the data
> _always_ be in perfect sync, not just when the file is accessed.
I've created databases entirely around filesystems, by contrast. And I've
tried tricks where I put the record into a file but NTFS is only
marginally better than FAT for that. (ReiserFS is supposed to be good but
I haven't checked it out.) Logically, however, it makes sense: Why should
I have to concern myself with what is, essentially, file management?
> Tell them about what they can do with an open system and you won't
> have trouble selling them something new.
Problem is, everyone says their system is "open". But they mean everything
from "You have the source code" to "You can import the select few things
we say you can into Excel".
> I have seen commercial systems which attempt to recreate that kind
> of closedness on commerical databases like SQL Server by withholding
> the owner rights to all the tables used by their system. Some of the
> commercial RDBMS providers also sell embedded versions of their
> database which is modified to make it very easy to completely close
> access to the system. Quite a number of our customers have switched
> to our Enterprise product a relatively short time after spending six
> figures for a closed system. Their frustration at being limited as to
> what they could do with their own data with such systems was sufficient
> to
> cause them to walk away from a very large investment. But bad news
> travels fast, and more and more customers know what questions to
> ask their prospective software vendors; like simply, "can I use Excel
> to pull data from your system?".
The answer will be something close to that that makes it sound like "Yes"
but is really heavily qualified.
>> Which is sort of amusing when you consider the point of all these
>> generic access methods (e.g. ODBC) is to make data accessible from a
>> number of
>> different avenues.
>
> I agree completely.
But then, what do the DBMS vendors compete on, if everything is the same
through ODBC?<s>
>>> This is the opposite of an open system.
>>
>> And an open system is the opposite of a secure system.
>
> I disagree.
>
> Security experts, like cryptologists, nearly all agree that "security
> through obscurity" does not work.
Tell it to the Marines. Or rather, the Navajos.<s> But the real bone of
contention is actually the word "open". You're thinking "open" as in "open
source". I'm thinking "open" as in "can be completely modified by the end
user".
>> What's wrong with RDBMSes that their performance is degraded by the
>> presence of BLObs, when they can't even index or otherwise exploit it?
>
> Fundamental network hardware limitations limit access to the RDBMS
> server. Everything needs to go both in and out of (usually a single)
> network card. Client-Server databases were designed to have very
> short "conversations" with clients, and they are tuned to this. If the
> files you are storing in blobs are small, no problem. However, if the
> files are large, returning a blob column is going to slow down access
> to the server for everyone else.
Somebody, somewhere is dropping the ball, really. Why aren't things set up
to share the load, whether network, hard-drive or whatever? OS function or
DBMS function?
> The other issue is how the database performs locking. Many do page
> level locking (even when they claim row level locking). So, in an
> attempt to maintain data consistency, which is part of their mission,
> databases will lock access to pages or rows under certain circumstances.
> Updating a large blob column in some databases pretty much stops
> the show for everyone until the blob has been updated and the locks
> removed.
Well, RDBMSes cheating in one form or another is pretty historical.<s>
===Blake===
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/advanced_delphi/
<*> Your email settings:
Individual Email | Traditional
<*> To change settings online go to:
http://groups.yahoo.com/group/advanced_delphi/join
(Yahoo! ID required)
<*> To change settings via email:
mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
<*> To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
