[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: 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 xlink record). 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. len -----Original Message----- From: Sean McGrath [mailto:sean.mcgrath@p...] >- 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 Id: 12345 Notes: Last contacted 1/1/2001. Joe from Sales I think - ask Shiela. N.B. Contact before 2002 for upgrade. See foo.doc for history. 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 elegance. 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 logic 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 margins 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 the problem. 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.
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|