Re: A Question on Integrety

"Marshall Spight" <mspight_at_dnai.com> wrote in message news:j7TDb.133063$_M.686950_at_attbi_s54...
> "Dawn M. Wolthuis" <dwolt_at_tincat-group.com> wrote in message
news:brouhm$dt3$1_at_news.netins.net...
> > This is a good example for use of a more agile approach to data
persistence
> > such as using a non-RDBMS solution (even if the product calls itself an
> > RDBMS) where data is persisted as strings, without strong typing in the
> > database persistence layer.
>
> How do you know the data that you end up with is really strings,
> if you don't do typechecking? Couldn't you accidently end up with
> some floats, or whatever? What do you do then?

All data stored by a computer can be seen either as strings of ansi or unicode characters (or whatever flavor you like), including 7&6, 4.52E24 or -38288.92 ; or, if necessary, as binary strings (in which case I prefer to store the video, picture, etc in a file system accessible via a URL and store the URL as a text string for query and reporting purposes in the database -- if I ever need to actually query a video itself in digital format, that would be a different story).

So, yes, when you work with a number, you want to perceive it as a number, but when you store it, why do you feel a need to tell the database what it is and request that it do further verification if you don't want it to? With "draft" databases where you are placing data to be refined and validated over time, you don't want your database to do more checking than your file system does when you store a draft of a Word document.

If you take RELATIONS one step further so they are FUNCTIONS (maps) that map a unique key to a string of data (such as in a key/value data store), you can store these functions (as files/"tables" within a database). Your database or you can then have additional functions that map the "value" to all values for the record (row in relational terminology), matched to its metadata, which includes the way each string should be handled for input/output or computation purposes.

This type of approach might make relational theorists anxious because it does fly in the face of the CONTROL that is in an RDBMS while the developer then builds in whatever controls are appropriate. It is a solution that is not simply a file system (like DOS or UNIX) but does store structured data for information systems. But it is not an RDBMS (or even a DBMS) either by most definitions because it does not require you to declare type information that is true globally and for all times for each attribute stored.

To respond to a few other responses regarding terminology: database, agile, persist ...
YES, it is a database, but as I indicated, it is NOT an RDBMS (according to the most common definitions). Yes, it is stepping backwards to the past in not having the database force any more rules on the data than the developer places on them, but it is also forward into the future (such as XML-based data repositories). To some extent, while the relational theories have advanced our profession in many respects, they have also set us back a bit with languages such as SQL and disciplines such as full-time DBAs separated from and often at odds with application developers.

As for the words "agile" and "persistence" -- yes, buzzwords of the day and I'm old enough to instead say that the solution I'm recommending is highly "maintainable" from the start of coding through to implementation and from implementation for the next 20+ years (as evidenced by the number of systems written this way in the 80's that are still in production use today). And in place of "persist" as a verb, I'm happy to say "store" -- just trying to stay current with the language of the industry in case some of the readers are not in the over-40 crowd.

And for those who like to use the word "stupid" (just what is it you are compensating for?! don't you realize that it is preferable to dialog with friendly people? are you trying to discourage folks like me from participating?) -- my real question -- do you have any experience storing data in non-DBMS repositories that are not OS file systems? What, in your experience, leads you to believe that this does not provide the features that would help Mr. Harris with his original issue? My experience suggests that this will handle the situation very nicely indeed.

Cheers! --dawn

>
>
> Marshall
>
>
Received on Wed Dec 17 2003 - 21:46:40 CET