[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [xml-dev] Caught napping!
We allow customers to add fields, controls (eg boxes) on those
fields, and set some properties of the control objects. That
isn't technically difficult. There are some caveats. They can
search in these and get them into ad hoc reports. What they
can't do is add logic. If they want that, we point them
to a third party report generator such as MS Access or
Crystal Reports. How:
1. We have system tables to keep up with customer
extensions so we don't stomp these in the next release.
2. We provide a report about what they have added and
compare that to new development in case we add features
that overlap their extensions.
You are right about the notes field. Most handy and an
easy out when a customer asks for a requirement we don't
support. Also, we use tags in the fields that let us
dump out the memo type (what a notes field is - a varchar),
and use these for different tasks. One of the most successful
features we've added is to embed the browser object and
use it in combination with the treeview to create dynamic
drill down functionality for involvements (sort of a quasi
So far, I don't find the kind of arguments FB makes
very compelling in the sense that with the tools we
have, it isn't that hard to come up with a solution
using RDB for somethings, XML for somethings, and so
on. It is really nice to have them all.
From: Sean McGrath [mailto:email@example.com]
>- Your CFO doesn't care about the mathematical foundations of your database
>design, only whether it gets the job done.
Right. And your CTO (if s/he has been around long enough and understands
human nature) knows that the database contains things like:
Name: Sean McGrath
Notes: Last contacted 1/1/2001. Joe from Sales I think - ask
N.B. Contact before 2002 for upgrade. See foo.doc
Over time, much good stuff migrates into free format areas such
as notes fields in RDBs. Why? Because RDBs just don't cater for
semi-structured evolution. Ever ask a DBA to add a field to a
table?. If not, bring a helmet and ear-plugs when you do.
RDBs don't evolve well. The mathematical elegance of RDB is lost
in a crazy world of economic cycles and messy, experimental
business models that rewards adaptability over mathematical
Evolution is the natural state of all systems. XML is easier to
evolve. Less "optimal", less beautiful but easier to evolve. I
know which one Darwin would put money on.
I have worked in many organizations with "bright shiny
RDBs. Invariably, although
the database plays an important role, the *real* knowledge is not predicate
assertions in Oracle but hunches and bitter experience and initiative and
half-remembered, half-imagined facts. In short the real knowledge
in any organisation is in peoples heads. If you are lucky, your people
will write down stuff in faxes, word docs and notes scribbled into the
of your beautifully elegant but woefully unsuitable for your business,
relational database record structure.
Does XML solve this problem? No. But it might be a better source
of fundamental compounds from which to craft a solution to
All we know for sure is that RDB does not solve
the problem. All the word docs and faxes and scribbled
marginalia in all the filing cabinets in all the world
attest to that fact.