[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Caught napping!
----- Original Message ----- From: "Sean McGrath" <sean.mcgrath@p...> > 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. After 1 minute of thinking ( please don't consider it to be a 'design', just a 'view', because designing a convinient and scalable system like this implies understading of the problem domain, to generalize properly e t.c. BTW - anyway you have to do that step, is it SQL or XML. In the case of XML you have to think about 'what are the tags', right? ) So it could be Name: Sean McGrath Id: 12345 Notes: Note1: What : Last Contacted: 1/1/2001 Comment: Joe from Sales I think - ask Shiela. Note2: What: Contact Before: 2002 Comment: for upgrade Note3: What: Link : foo.doc Comment: history This is just a quick possible solution how to support semi-structured data ... And it could be implemented not adding a single column to the database. I can not belive somebody may think that adding new property implies adding new column to some table. Like any typical web-developer, I've implemented several systems when the number, names and types of properties are not known in advance. Systems like Documentum and CMS do that for ages and .. they're doing fine ... Big clients, lotsa money. Usually you just provide a heap of properties, linking them to the parent with a simple join. As to (early mentioned) cases of 500 tables joins - I'd like to think that 500 tables joins is not the case in the real life, but after some SQL schemas that I've seen in the US, I'm not so sure on this one ... Still, I think joins of 500 tables is not what we see every day ;-) > 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. This is *almost* irrelevant, because adding new properties to the object *does not* imply adding a new column to the table. Blame stupid coders. Well not really. See below. > 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. Nope. RDBs don't envolve well usually because most of SQL schemas are a *plain* [expletive deleted], when people are denormalizing data to optimize on joins ( and usually bottlenecks are *not* on that part, but somewhere else ). Well, not really. See below. > Evolution is the natural state of all systems. XML is easier to > evolve. Proof? Proof??? I have a hard time with linking. SQL gives linking for free ( just join by 'id' - and you can link anything with anything ). With XML it may look easier to add one more property ( that's why it looks 'easeir to envolve' ), but when you want to link something - bang. Earlier in this discussion, there was a good point about how to keep PO 'in sync'. What is 'easier to envolve' ? What is ' to envolve' ? > Less "optimal", less beautiful but easier to evolve. I > know which one Darwin would put money on. Nope. 1. XML has no reasonable model behind it. ( where it is? where is the math, 'mapped' into some real stuff ( like it is with SQL and/or regexprs), the stuff that I can run on my computer? ) 2. XML is *not* easeir to envolve ( linking. And not only.) Well. Not really. See below. > 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. So? I don't get it. Most of developers produce crappy SQL schemas, even they're using ( relatively ) elegant and simple SQL mechanizms. You think the same people will do better with XML ? I know they will not. You know they will not ;-) > Does XML solve this problem? No. OK! So we agree here. People writing bad SQL code - will write bad XML code as well. Let's see the next step ... > 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. This is really strange logic. And this is the 'see below' part also. ;-) Yes, we know that RDB does not solve the problem. Honest. But I'd put it slightly different. "Almost all current SQL servers - kinda [expletive deleted]". I can elaborate why, but that's not my point. ( Also I should say that I use SQL servers all the time and I think that SQL servers are the most valuable asset in current IT, together with regular expressions and Yacc. ;-) My point is that the statement above does *not* equal to "RDB does not solve the problem". Why do we 'feel bad' with current SQL servers ? There are many reasons, I think. Maybe, just relational model [expletive deleted]. Unfortunately, I doubt that there is many people on the planet, who *really* understand how relational model could be *possibly* applied to DBMS. What we know now as SQL, is not the 'true' relational model, but there is something taken by big guys, who have cooked commercial products, several 'standards' e t.c. I'm not saying that SQL as we know it is 'bad' implementation of 'good mathematics'. I'm just sure that it is just *one* of possible implementations / mappings, so we can not judge the model by the implementations that we have. It would be like judging markup languages by SGML, saying 'markup languages are too heavy'. We now have XML, right? ( And XML is not the end for sure ). However, with all the differences between SGML and XML, they are just different reflection of the same 'model'. Right? I think the same is with relational model and SQL servers. I'd really love to hear what Fabian Pascal has to say, when he's saying that "the real invetion has happened, but nobody noticed", when he talks about the relational model. Unfortunately, when somebody can not tell the truth in one page ( I tried to understand what Fabian syas, but I've failed) that may mean that there is *no* truth. But that also could be that there *is* a truth, which is just *hard to express*. It takes ages to get a 'simple' things clean. It took *years* for UNIX guys to 'invent' the '|' symbol ! Just a stupid '|' symbol! > All the word docs and faxes and scribbled > marginalia in all the filing cabinets in all the world > attest to that fact. It all does not matter. Really. People always do things in stupid ways and the fact that "SQL servers don't do the trick" is *irrelevant* to evaluation of XML servers. At least SQL *has* some model and it turned out that some aspects of that model are handy for processing and /or 'writing code'. 'join' ( link anything with anyhthing ) is the shining argument. Somebody claims that XML has a model, which is handy for processing and / or 'writing code' ? Well, it could be that XPath is such a shining argument. In fact I think that it is the *only* possible argument, but XPath is not benefiting from XML model, it struggles with it, working many things around. So, what I wanted to tell was: 1. Yes, I think I also feel that 'there is something not really good with the current SQL servers' 2. It has *nothing* to do with the (possible) ... questionable ... sucess of XML servers. 3. I have a strong feeling that 'poor man' "XML server" ( I'm talking XML subsets!!!) can perfectly live on top of SQL server. Would that mean that such a server is a clear proof that "SQL can express XML", but "XML can *not* express SQL", and that will finally show that SQL model has won? ;-) Just kidding. Rgds.Paul.
|
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
|