Re: OOD Refactoring RDMS Newbie!

From: Topmind (topmind_at_technologist.com)
Date: 10/17/03 

Date: 16 Oct 2003 23:46:13 -0700

>
> >> >> > For the jillionth time, databases are MORE than just persistence.
> >> >> > If you are ONLY using them for persistence, then you are wasting
> >> >> > them. It is like saying that "cars are for storing fuel".
> >> >> >
> >> >> >
> >> >> Pah! If I put something in a database, it's because I want to be
> >> >> able to get it back later. And if there's no reason to get it back
> >> >> later, I'm not putting it there. That's persistence.
> >> >>
> >> >> What else do you use a database for?
> >> >
> >> > Query languages or query ability
> >>
> >> Using a query language or ability to retrieve data that's been
> >> persisted is fine. It's still *persisted data*, and this isn't counter
> >> to my point.
> >
> > Many highly interactive RDBMS buffer most of the stuff in RAM. What
> > exactly is your definition of "persistence" anyhow? RDBMS often blur the
> > distinction. If OO has a hard time blurring it, then maybe you should
> > consider switching paradigms.
> >
> >
> Where's the RAM?

Make it so you don't need to care.

> Do we need an RDBMS on every machine?

Lite versions of RDBMS (or DBMS with R influence at least)
ran on CPM with 64K RAM and the very first PC's
in the early 80's. Big-ass Oracle systems is
not the only way to RDBMS.

> Do we have a
> universal networked RDBMS that can cache on local RAM of every machine
> that needs access?

I am not sure what you are asking for. How about about a specific
example.

>
> Defining "persistence" is not difficult. It's an English word, meaning
> "continuing to exist". In the context of programming, I use persistence
> when I want something to continue outside the context of the immediate
> application. I think of "persistent" more or less as an antonym to
> "temporary", though of course I recognize that even persistent data need
> not persist forever.

Do you mean sharing or temporal "lasting"?

>
> I use multiple paradigms.
>
> I expect to
> continue doing so unless I discover a single paradigm that I believe
> covers everything I need to accomplish. And I prefer to keep the paradigm
> boundaries clear, rather than scattering sql, xml, html, javascript and
> GUI code (not that I write much GUI code) throughout the internals of my
> OO code, or intermixing them with each other.

SQL, XML, and HTML are protocols. You want to wrap protocols around
protocols to avoid protocols? That is layer-happy IMO.

>
>
> >> > Noun Modeling
> >>
> >> This is just your usual nonsense, misinterpreting the object paradigm
> >> as being all about modeling nouns by inheritance taxonomies. I'll
> >> ignore it.
> >
> > I did NOT say inheritance here. You are putting words in my mouth.
> >
> >
> Ok. I should have just ignored it instead of noting why I was ignoring
> it. If you'd like to elucidate the true meaning, I'll decide after this
> clarification whether to continue ignoring it.

To describe the "important attributes" of nouns (for an organization),
and how nouns relate to each other.

>
>
> >> > State management
> >>
> >> If state management is long-term, this may be appropriate. It's still
> >> persistence.
> >>
> >> State that does not need to be persisted can certainly be handled
> >> without use of a database.
> >>
> >> > Multi-user contention management (locks, transactions, rollbacks,
> >> > etc.)
> >>
> >> All important issues when you're sharing data.
> >>
> >> If the data is being persisted, a persistence subsystem that handles
> >> these issues is likely the right place to deal with them, and
> >> delegating them to the database is common practice.
> >>
> >> If the data is not being persisted, but must be shared, these issues
> >> can be dealt with in other ways.
> >
> > So you have approach A for "persisted" stuff, and approach B for
> > non-persisted stuff? How much rewriting do you have to do if you need to
> > change something from one to the other? A Meyerian Discontinuity sin.
> >
> >
> Yes, I treat temporary stuff differently than permanent stuff. Usually by
> making sure I don't have sharing issues - i.e., I don't share it. If I
> find I have to share it, I'll make a decision on the cleanest and/or
> easiest may to make that happen. Sometime it means a decision to persist
> the data.
>

In other words, you do have to make some significant changes to your
code at times. I would hate to write an ACID-capable transaction
processor from scratch, for example.

>
> >> > Backup and replication of data
> >>
> >> Still persistence. If I'm not persisting data, I don't care about
> >> these.
> >>
> >> > Access security
> >>
> >> If you're persisting data, it's a good idea to secure access to it. If
> >> you're using database security to control access to your application,
> >> that can be done better in other ways.
> >
> > Same switcheroo cost issue as above.
> >
> >
> There are reasons other than cost to use different mechanisms and rules
> for database access than for application access.
>

You are welcome to give specific examples.

>
> >> > Data rule enforcement or validation
> >>
> >> Data integrity constraints are an appropriate part of a persistence
> >> subsystem. It's still persistence. Validation of user input data is
> >> usually better done elsewhere.
> >
> > They are interlinked for good or bad.
> >
> >
> Validation of user input data should be done before it becomes persistent.

What is wrong with "pending" transactions or change requests
that are not lost if somebody trips over the plug?

>
>
> >> > Automatic access optimization
> >>
> >> Optimization of access to *persisted data*! A fine thing, and a good
> >> reason for using a relational database instead of flat files - but
> >> still part of persistence.
> >
> > I would use a RDBMS even if it only ran in RAM.
> >
> >
> And use a different one depending on whether you wanted it to be
> persistent?

I generally don't make the strong distinction between "persistent"
stuff and non-persistent stuff that you do. I use databases
for multiple reasons, persistence (saving to disk)
being only one of them.

>
> In my experience, it's quite common that the database is on a different
> machine than the one on which my application is running, or in fact that
> there are multiple databases involved, running on multiple different
> machines. If there happens to be a database on the local machine, I might
> use it, and if it runs in RAM, that might be a fine place for short term
> storage of data. If I thought the gain were large enough, I might even
> advocate installing an RDBMS for this purpose. But I can't think of a
> situation where I would have bothered.
>

So if databases were easier to "install" and/or languages had
better or "instant" support for at least "lite" versions,
you would use them more?

>
> >> > Multi-language or multi-app access
> >> >
> >> >
> >> Multi-language or multi-app access to *persisted data*.
> >
> > RDBMS != Disk
> >
> >
> RDBMS != Silver Bullet

It is as close as anything real comes in IT.
At least they float my boat.

-T-

Relevant Pages

  • Re: Ecological software (was: Delta)
    ... requiring you to keep reinventing your own. ... An RDBMS is also some 3000x slower in this case. ... Good RDBMS cache stuff in RAM. ... In some cases I need to access the data of 100 000 class instances with ...
    (comp.object)
  • Ecological software (was: Delta)
    ... An RDBMS is also some 3000x slower in this case. ... un/marshalling of data, instantiation of classes and memory handeling ... Good RDBMS cache stuff in RAM. ... For each class instance represented in the RDBMS I retreive ...
    (comp.object)
  • Re: Application logic and Business logic
    ... Another way of reducing IO is to tune the caching in your RDBMS. ... have enough RAM your IO could be 0. ... > prioritization, security, or auditing than data-change transactions. ...
    (comp.object)
  • Re: Good Books on MultiValue Databases
    ... new info there, right?), the database structure when converting from ... an MV environment to an RDBMS actually does require re-architecting. ... Codd wrote his rules specifically ... management system, rather asking the management system to manage ...
    (comp.databases.pick)
  • Re: Good Books on MultiValue Databases
    ... new info there, right?), the database structure when converting from ... an MV environment to an RDBMS actually does require re-architecting. ... Codd wrote his rules specifically ... management system, rather asking the management system to manage ...
    (comp.databases.pick)