> First, hi Steve M! Ironic, running into you out here.
Ha ... the whole Python list is here today! :)
> > EXACTLY! I think once database application developers realize
> > that the best way to use an RDBMS is as a "smart index/query
> > engine" for "Web objects" (i.e., _only_ put into the DBMS the
> > attributes you want to use to search for the objects, plus the
> > URL/URN/URC), "database applications" will become much more
> > efficient and flexible, and there will never be a need for an
> > OODBMS!
>
> I disagree with this. ...
I knew somebody would! (I was going to say "95% of the time",
but why deprive someone of the joy of disagreeing? ;)
> ... We developed an object system behind a Web server
> for an online service. It used a persistent object model (built out of
> Python for the prototype), allowing the invoking of methods,
> creation/deletion of objects, etc. I had previously done a project like
> that using the miniSQL relational database, and I'd never want to do that
> again.
The project sounds neat, but miniSQL is not a _real_ RDBMS;
it's a toy :) But that's probably not relevant to your point,
which is ...
> The problem becomes arbitrary changes in attributes, as defined by HTML
> forms. Whenever you want to add another data element, you'd have to drop
> the table and recreate it. With the Python persistent object model, just
> changing the HTML form definition changed what was put in the object
> store. Plus, we had some of the objects that implemented methods
> differently, for customizing the behavior. Don't know how you'd do that
> kind of overloading with stored procedures.
Sounds to me like you're talking about a prototyping situation, if
your objects are changing that frequently. In that case, you need
flexibility but you don't care about selecting objects using
sophisticated semantic/relational queries, so that capability is
irrelevant. For apps in which the end-user wants to search
for objects by their attributes, the attributes that are being used
in the search had better not be in a state of continuous flux, or
you'll have some mighty confused end-users! For such applications,
the objects (or at least their searchable attributes) may of course
change, but shouldn't change very frequently.
On the other hand, if the attributes that you are changing are
not ones that you actually want to _search_ for the objects by,
it's a non-problem -- they won't be stored or indexed, so
who cares? That would be the case with the objects' methods,
for example (whose internal information should be hidden, and
whose interfaces should not be changing, unless you are
prototyping!).
The situation you describe will present a problem for _any_ type
of search engine that enables good semantic or relational searches,
because it will mean constantly tearing down and rebuilding indexes
and relationships, which is not easy in _any_ type of indexing
system (RDBMS included, of course).
The _queriable_ attributes of objects in applications that are
ready for prime-time will probably be about as constant as IAFA
standard templates. In fact, for the sake of comprehensibility
of the system, they should be as standard, or at least as
well-understood, as possible.
Incidentally, Paul, please don't take this as a flame. Just an
animated discussion with another Python enthusiast!
:)
--Steve.
oo _\o
\/\ \
/
____________________________________________ oo _________________
"Sometimes you're the windshield; sometimes you're the bug."
- Knopfler
Stephen C. Waterbury Assurance Technologies Division
Code 310, NASA/GSFC Staff Specialist
Greenbelt, MD 20771 Computer-Aided Engineering
Phone/FAX: 301-286-7557/1695
email: waterbug@epims1.gsfc.nasa.gov
World Wide Web: http://epims1.gsfc.nasa.gov/people/me.html
_________________________________________________________________