If I ever found a third world country, I'll have to keep this in mind. Great way to pad the ol' treasury, eh?;-)
Seriously though, what would happen if you simply refused to pay the charges? i.e. Work with your phone company so that you pay them their side of the line, then simply refuse to cough up the cash to the foreign carrier. Attempts at prosecution would have to be through your home country's legal system, which may have laws regarding fraudulent debts.
Actually, that should be -1 "Complaining about all the trolling".
Anyway, suppose your XML database consist of sales orders. In each order you have header information e.g. customer and n items each with a product code, quantity and so on. I don't see how your precious freakin' index is any different to a table[1] (order header) with a 1:N child table (items), just as it would be in a relational one.
The indexing isn't different. Only the data query and retrieval methods. I don't know why that's so difficult to understand. Indexes != Relational Database. Or were you expecting some revolution in database storage and retrieval?
So does a relational one, thought it might take several SQL commands to get it all. Your point was what, again?
My point was that they are different query and retrieval methods. Nothing more, nothing less. I don't know why you feel you have to attack me on that point. It's just another type of database that has its own performance and query characteristics. It's not about "I can do something you 1uz3rz can't!"
Please. If you'd like to have an intelligent discussion, then let's do so. If you just wish to attack and troll, then please go bother someone else.
"In fact, that's exactly what a good XML database will do. By indexing all the accessible fields"
In other words, it pretends to be a ralational database.
What is it with people lately? Everyone seems to want a piece of the trolling action?
For your information, a set of indexes no more makes a relational database than being in a garage makes you a car. Index data structures are an inherent way to improve the performance of all databases, whether they be ISAM, Hiearchical, Object, or Relational.
What makes a relational database relational is the way that the data is loosely intertwined to develop logical connections. In theory, these connections can complete various thoughts about a piece of data. ISAM files are merely indexed data, while Hierarchical (including XML) databases contain a complete "data packet" covering a particular concept. (e.g. Customer contains name, a set of addresses, and a set of phone numbers.)
I note you have not addressed my point about scalibility.
Theoretically, there's no reason why an XML database shouldn't scale, as long as hierarchical data is what you need. The core theories behind database indexing and queries are the same for XML databases as they are for SQL, ISAM, and Hiearchical. The reality of current XML database solutions is that they're excellent for smaller database solutions (again, if XML is what you need).
As with myself, I needed a very advanced way of storing configuration and security information. XML provided the solution, and Xindice gave me a database solution. While that sort of use is somewhat left-field, there are a few more traditional uses I could see it being useful for. In a few other posts I've mentioned Customer information. The ability to attach all his addresses, phone numbers, and other personal information in one record is a very nice bonus. Similarly, you might store all the relavent information about a product in its XML tree. Need a new type of product? No need to change the schema, just embed a different information set for that type!
BTW, I realize that you consider parsing to be a big problem for XML, but consider the amount of CPU and memory that goes into many SQL JOIN operations. Databases often have to literrally perform thousands (sometimes millions) of comparisons just to provide a small record set. The only way they manage this effectively is by keeping all the necessary indexes (and sometimes data) loaded into memory. XML DBs merely embed the information and have the slight overhead of parsing a kilobyte or two. In the end it tends to even out for a simple dataset, and the scales can tip significantly in XML's favor with a large dataset. As a bonus, the parsing can be offloaded to the application server. Depending on your configuration (especially since application servers are easier to cluster than databases), this can improve database performance significantly.
Believe what you like. I personally have used Xindice and find it very good for some applications. It really is just a different way of storing data, and can actually improve performance in the right situation.
Most people have been indoctrinated to accept SQL as the only was things can be done. But the truth is that there are dozens of effective methods for storing and retrieving data. Some may even be better than SQL in the right sitation.
Of course, even the "Windows Look & Feel" sample in the example you gave (see this page) does not actually look exactly like what people expect a native Windows app to look like. It is certainly very close, but visibly different. (Although I doubt the differences impact usability at all.)
The only two issues I see with the UI is the icons (not very windows like) and the splitpane has the arrow buttons. Both of these are remnants to the fact that it was created for Karsten's Plastic Look and Feel, an more embellished Windows-like L&F. He only converted it to a Windows look after he went into business as a GUI consultant. I pointed to JDiskReport because you can actually run it. You may find screenshots of his Metamorphasis application more appealing.
Ultimately, poorly written Java apps may have the same general distribution of speed and usability issues that typical (also poorly written) VB or C++ apps have (which I do not actually concede), but since Java apps are visibly distinct (more so even than VB) they will continue to get a bad rap simply because they stand out. Every way that they stand out (in a non-native way) is another nail in the coffin.
To be perfectly honest, I'm not too worried about it. Microsoft has already helped us out by convincing people to like different UIs. (2000, XP, Office components, etc.) Linux is also helping in this area. This gives professional Java developers two options:
I'm confused. I heard the words "XML" and "database" in the one sentence. Then I read "good" and realised you don't know what you are talking about.
Trust me, sir. I'm well aware of what I speak. Besides the fact that "good" never appeared in my post (though it was implied, so we'll let it slide), I've spent quite a bit of time with some of the most popular SQL databases (PostGreSQL - good, MySQL - sucks, Oracle - good for BIG stuff, MSSQL - often sucks for anything but "small" dbs, DB2 - just shoot me now, Pervasive sQL - BTrieve sweetness, etc.) and with Apache Xindice. After working with Xindice on a real project, I feel like XPATH is a breath of fresh air. I certainly wouldn't recommend it for everything, but it's certainly nice for some small databases.
I gave a brief explanation of how I used Xindice here. Just keep in mind that there doesn't always have to be "ONE TRUE SOLUTION" to everything and you'll do just fine.:-)
The fact that a SQL resultset might end up consuming MORE memory by far by redundant data in many columns than an XML resultset, that I'll give you.
As I said, sometimes an XML database is the type of thing that really makes sense, sometimes it isn't.:-)
I myself got into Xindice and XPath when I started working on a new kind of "unhackable" OS Shell. This shell would run all the servers and handle all SSH user interaction. Where it got really cool was that I had this XML configuration file for each server. The server could store its own style of configuration data in one section, and the security settings would be stored in another section. (I actually made it impossible for a server to access folders and network connections it wasn't configured for.) Anyway, I needed a secure way to store this XML data, so I looked into Xindice. I fell in love with it immediately and decided to use the database system wide. (Including tracking of users, groups and permissions.) Really a great piece of technology there. *sigh* I should really get back to that project one of these days.:-)
The second table would hold Employed, Unemployed, and Unknown. This way a NULL will never appear in your database, merely a lack of information.
Now that I think of it, I suppose that first normal form wouldn't be violated as long as you ALWAYS separated out the nullable field. Considering the complexity this adds, it's difficult to say whether it is worth it or not.
Doesn't this statement disprove your point? The fact that these types of standouts are notable because they are NOT obviously Java means that there is a more general problem that makes them the exception.
Not really. For every polished app, there are 500 crappy apps that someone has written in their spare time. (Just check shareware sites for examples.) The problem is that in Java's case, the programs are "different" because they're based on Java. Thus people like to blame Java for a signal to noise ratio that is quite common across the industry.
Of course, that crappy metal look and feel doesn't help anything. It was fun when it was first introduced, but too many developers didn't know how to make it look good. Thus "average" apps tend to look like "crappy UIs" in addition to simply being crappy apps. Some of the community (such as the famous Karsten Lentzsch) are trying to change the situation. The results of these "real" GUI designers can be... ahall we say... impressive.
Oooo, baiting! Keep up the show Mr. Troll. Perhaps I'll even let on how much work I've actually done so that you can have some cannonfodder. (NOT) You trolls are so amazingly transparent and pathetic. The funny part is that most of you are smart enough to have real jobs, real lives, real friends, and real spouses. But you screw up your lives so badly that you have to berate others to make yourselves feel better. Pathetic.
Are you really so stupid that you're going to link to a bunch of discredited microbenchmarks that use different algorithms for implementation, as well as superfluous and broken techniques for writing C and C++?
Pardon me, but didn't someone state that C/C++ was inherently *faster* than Java? Can it be? Is it possible that you can write bad code IN ANY LANGUAGE? Does that even mean that you can write good code IN ANY LANGUAGE?! The HORROR!!!
On a more serious note Mr. Troll, welcome to the wild and wooly world of Benchmarks. There is simply no way of giving an "accurate" measurment of language performance since either side can always argue that something was done incorrectly. However, there is one thing we can glean from these benchmarks (in a very general sense): Java and C are evenly matched competitors. Sometimes C will appear a bit faster, sometimes Java. So use what gets the job done right.
Now, most of these benchmarks have been mentioned on Slashdot at one time or another. To date, I have not seen a *single* benchmark that displays results different to those in the above benchmarks. As I troll, I release you'd never want to reveal your secret identity (*snigger*), but perhaps you'd like to be the first to bring forward a viable benchmark showing the MASSIVE (i.e. non-existant) performance difference between Java and C? Or perhaps you'd like to continue this and get yourself pummeled that much harder?
I could ask you the same thing. (Hint: Wikipedia sometimes gets things wrong.) Also from Wikipedia, Unisys MCP was written in ALGOL in 1961, a full decade before UNIX. Symbolics LISP OS was admittedly post Unix-invention, but it hit the general market about the same time as Unix.
You also have simply put out a list of unsubstantiated claims by saying "JAVA IS NOT SLOW".... By not providing any real evidence to substantiate your claim that Java is NOT slow, you're no better (or worse) than I am with my posting that it IS slow.
I shouldn't need to provide this evidence. It is inherent in the forum of discussion we are currently using. Or do you wish to claim that you have been ignoring the various benchmark results that have appeared in this forum?
Thus I say again, you are making unsubstantiated claims. Please back up your claims or back off your claims. Hyperboles involving a meta-argument ("The fact that people have to try to fight this in 2004 would seem to indicate that the popular notion is that Java is slow") may provide amusment, but it does not provide evidence.
Because it's hierarchical data that is of unknown complexity. At the top of the hierarchy you have the root tag, which splits out into its attributes, sub-tags and CDATA. Each sub-tag again has the same split. Thus you have an exponential increase in complexity for every level the XML wraps.
No, you'd just need to use a few joins, a CONNECT BY
CONNECT BY is a new Oracle 10g feature to help support this sort of SQL DB nonsense. While it helps, the database really still has to make all the of hierarchical passes that you previously would have made manually.
and maybe a stored procedure.
If it involves a stored procedure, then you've already suggested that the query is too complex to be handled in a single SQL pass.
Things can get particularly dicey if you need all the data returned. For example, if I have a customer, I may wish to display his addresses and phone numbers on a page. In an XML database, this is one query, one transaction, and (when the data is changed) one update. For an SQL database, it's several queries, multiple result sets, and tons of updates. If you're serializing from XML, it even means that you'll need to delete the entire dataset out before performing the update. That kind of stings.
I think it's important to understand that flat data models have gone the way of the dinosaur. While they were very fast because of their easy record indexing, they have been replaced by more advanced (albeit more memory hungry) data structures. Had mainframe designers been given a choice, I can almost guarantee that they would not have used the fixed record model. Sadly, they had only a few kilobytes of memory to work with and had to stretch it as far as possible.
Ok, so you break down the XML by its structure. Now how do you do a valid query on it? Since you've completely dereferenced its structure and stuck it in a relational model, you've cut yourself off from the prospect of doing XPATH type queries. Instead, you'll need to make multiple (perhaps hundreds?) of passes at the table to reconstruct its data structure. XMLDBs don't have this problem. They deal with the XML in its natural form and are thus able to index, order, and query in that fashion.
As I said before, you can do many of the same things with an SQL database as you can with an XML database. That's not the point. The point is working with the data in a form that is natural to it and will provide the best results.
In what in this thread is referred to as SQL DBMS, the records have fixed length fields to make indexing possible.
This seems like an odd statement. As far as I'm aware, there are absolutely no requirements on the length of indexed fields. If there was, fields like VARCHARs couldn't be indexed. Many databases may optimize indexes based on size, but the real reason for maximum field length comes from the days of ISAM files. (Indexed flat files with fixed length records.)
I guess you could index an XML, but all index addresses would be wrong the minute you change a value in the first record.
XML databases don't actually work that way. It may seem "obvious" to create a database out of a massive XML file, but most implementations such as Apache Xindice actually deal with small XML fragments that hang off a larger table structure. Each "table" holds multiple fragments as records. If a record changes, the database reindexes the record in a similar fashion to SQL databases.
The primary differences between XML DBs and SQL DBs are that tables can be hierarchical, and the data can be hierarchical. A lot of details (such as the lack of NULL) also differ, but those are the main points.
A database would hopefully aleady have track of "red things" and shouldn't have to traverse a tree full of other useless data.
In fact, that's exactly what a good XML database will do. By indexing all the accessible fields, it's able to provide fast access to database wide queries like the one you suggested. Of course, these indexes do come at a cost of disk space and memory, so not everything is quite rosy in Denmark.:-( The upshot is that with processing and storage power at all time highs many (most?) databases have no need to concern themselves with running out of storage resources. More than enough resources for a multi-gigabyte database exist on even the smallest modern PC.
I'm not quite sure what you're getting at but if you've read his work he's never saying that the concept of a missing attribute is "bad" just that the "NULL" method of representing it as such is.
In fact, if I understood him correctly, his problem was that NULL situations represent a lack of information, but they've been implemented as a type of information in of themselves. While the author may despise XML databases, they handle the situation correctly. i.e. The field does not exist.
Part of the problem is that simply not having a field would break First Normal Form. (First Normal Form states that all columns must exist in all records. Period.) Yet there the situation arises where an individual record may not have data for that column. Thus the dilemma. You can't get rid of NULLs and maintain Normal Form. The two are simply at odds with one another.
And the problem happens as soon as you want to know which producs uses a specific screw
What makes you say that? Assuming that the table is built as a "Product" XML block contains its parts, you could simply run an XPATH query against your "Product" table, looking for the part name or number. The results should actually be slightly faster than an SQL database since no JOINs are involved.
Slashdot Mirror
If I ever found a third world country, I'll have to keep this in mind. Great way to pad the ol' treasury, eh? ;-)
Seriously though, what would happen if you simply refused to pay the charges? i.e. Work with your phone company so that you pay them their side of the line, then simply refuse to cough up the cash to the foreign carrier. Attempts at prosecution would have to be through your home country's legal system, which may have laws regarding fraudulent debts.
-1 ad hominem.
Actually, that should be -1 "Complaining about all the trolling".
Anyway, suppose your XML database consist of sales orders. In each order you have header information e.g. customer and n items each with a product code, quantity and so on. I don't see how your precious freakin' index is any different to a table[1] (order header) with a 1:N child table (items), just as it would be in a relational one.
The indexing isn't different. Only the data query and retrieval methods. I don't know why that's so difficult to understand. Indexes != Relational Database. Or were you expecting some revolution in database storage and retrieval?
So does a relational one, thought it might take several SQL commands to get it all. Your point was what, again?
My point was that they are different query and retrieval methods. Nothing more, nothing less. I don't know why you feel you have to attack me on that point. It's just another type of database that has its own performance and query characteristics. It's not about "I can do something you 1uz3rz can't!"
Please. If you'd like to have an intelligent discussion, then let's do so. If you just wish to attack and troll, then please go bother someone else.
"In fact, that's exactly what a good XML database will do. By indexing all the accessible fields"
In other words, it pretends to be a ralational database.
What is it with people lately? Everyone seems to want a piece of the trolling action?
For your information, a set of indexes no more makes a relational database than being in a garage makes you a car. Index data structures are an inherent way to improve the performance of all databases, whether they be ISAM, Hiearchical, Object, or Relational.
What makes a relational database relational is the way that the data is loosely intertwined to develop logical connections. In theory, these connections can complete various thoughts about a piece of data. ISAM files are merely indexed data, while Hierarchical (including XML) databases contain a complete "data packet" covering a particular concept. (e.g. Customer contains name, a set of addresses, and a set of phone numbers.)
Thanks for the comments, this has given me quite a bit to chew over.
:-)
You're welcome. And thank you for the conversation. It was quite stimulating.
See this response.
I note you have not addressed my point about scalibility.
Theoretically, there's no reason why an XML database shouldn't scale, as long as hierarchical data is what you need. The core theories behind database indexing and queries are the same for XML databases as they are for SQL, ISAM, and Hiearchical. The reality of current XML database solutions is that they're excellent for smaller database solutions (again, if XML is what you need).
As with myself, I needed a very advanced way of storing configuration and security information. XML provided the solution, and Xindice gave me a database solution. While that sort of use is somewhat left-field, there are a few more traditional uses I could see it being useful for. In a few other posts I've mentioned Customer information. The ability to attach all his addresses, phone numbers, and other personal information in one record is a very nice bonus. Similarly, you might store all the relavent information about a product in its XML tree. Need a new type of product? No need to change the schema, just embed a different information set for that type!
BTW, I realize that you consider parsing to be a big problem for XML, but consider the amount of CPU and memory that goes into many SQL JOIN operations. Databases often have to literrally perform thousands (sometimes millions) of comparisons just to provide a small record set. The only way they manage this effectively is by keeping all the necessary indexes (and sometimes data) loaded into memory. XML DBs merely embed the information and have the slight overhead of parsing a kilobyte or two. In the end it tends to even out for a simple dataset, and the scales can tip significantly in XML's favor with a large dataset. As a bonus, the parsing can be offloaded to the application server. Depending on your configuration (especially since application servers are easier to cluster than databases), this can improve database performance significantly.
Believe what you like. I personally have used Xindice and find it very good for some applications. It really is just a different way of storing data, and can actually improve performance in the right situation.
Most people have been indoctrinated to accept SQL as the only was things can be done. But the truth is that there are dozens of effective methods for storing and retrieving data. Some may even be better than SQL in the right sitation.
Of course, even the "Windows Look & Feel" sample in the example you gave (see this page) does not actually look exactly like what people expect a native Windows app to look like. It is certainly very close, but visibly different. (Although I doubt the differences impact usability at all.)
The only two issues I see with the UI is the icons (not very windows like) and the splitpane has the arrow buttons. Both of these are remnants to the fact that it was created for Karsten's Plastic Look and Feel, an more embellished Windows-like L&F. He only converted it to a Windows look after he went into business as a GUI consultant. I pointed to JDiskReport because you can actually run it. You may find screenshots of his Metamorphasis application more appealing.
Ultimately, poorly written Java apps may have the same general distribution of speed and usability issues that typical (also poorly written) VB or C++ apps have (which I do not actually concede), but since Java apps are visibly distinct (more so even than VB) they will continue to get a bad rap simply because they stand out. Every way that they stand out (in a non-native way) is another nail in the coffin.
To be perfectly honest, I'm not too worried about it. Microsoft has already helped us out by convincing people to like different UIs. (2000, XP, Office components, etc.) Linux is also helping in this area. This gives professional Java developers two options:
1. Look like platform specific apps.
2. Wow the world with "more" beautiful screenshots.
In the end, I don't think users will really care either way. As long as it looks good and does the job, they'll be happy.
CONNECT BY goes back to at least 7.1.x. Oracle has handled hierarchical data for a long, long time.
:)
;-)
Odd. Oracle claimed otherwise. Sounds like another one of their marketing tricks.
You may find that you can build your app on the defacto standard DBMS and before Oracle or Microsoft buys whoever you're dealing with now.
Thankfully, there's no chance of that.
I'm confused. I heard the words "XML" and "database" in the one sentence. Then I read "good" and realised you don't know what you are talking about.
:-)
Trust me, sir. I'm well aware of what I speak. Besides the fact that "good" never appeared in my post (though it was implied, so we'll let it slide), I've spent quite a bit of time with some of the most popular SQL databases (PostGreSQL - good, MySQL - sucks, Oracle - good for BIG stuff, MSSQL - often sucks for anything but "small" dbs, DB2 - just shoot me now, Pervasive sQL - BTrieve sweetness, etc.) and with Apache Xindice. After working with Xindice on a real project, I feel like XPATH is a breath of fresh air. I certainly wouldn't recommend it for everything, but it's certainly nice for some small databases.
I gave a brief explanation of how I used Xindice here. Just keep in mind that there doesn't always have to be "ONE TRUE SOLUTION" to everything and you'll do just fine.
The fact that a SQL resultset might end up consuming MORE memory by far by redundant data in many columns than an XML resultset, that I'll give you.
As I said, sometimes an XML database is the type of thing that really makes sense, sometimes it isn't.
I myself got into Xindice and XPath when I started working on a new kind of "unhackable" OS Shell. This shell would run all the servers and handle all SSH user interaction. Where it got really cool was that I had this XML configuration file for each server. The server could store its own style of configuration data in one section, and the security settings would be stored in another section. (I actually made it impossible for a server to access folders and network connections it wasn't configured for.) Anyway, I needed a secure way to store this XML data, so I looked into Xindice. I fell in love with it immediately and decided to use the database system wide. (Including tracking of users, groups and permissions.) Really a great piece of technology there. *sigh* I should really get back to that project one of these days.
Now that I think of it, I suppose that first normal form wouldn't be violated as long as you ALWAYS separated out the nullable field. Considering the complexity this adds, it's difficult to say whether it is worth it or not.
Thanks for the discussion.
Doesn't this statement disprove your point? The fact that these types of standouts are notable because they are NOT obviously Java means that there is a more general problem that makes them the exception.
Not really. For every polished app, there are 500 crappy apps that someone has written in their spare time. (Just check shareware sites for examples.) The problem is that in Java's case, the programs are "different" because they're based on Java. Thus people like to blame Java for a signal to noise ratio that is quite common across the industry.
Of course, that crappy metal look and feel doesn't help anything. It was fun when it was first introduced, but too many developers didn't know how to make it look good. Thus "average" apps tend to look like "crappy UIs" in addition to simply being crappy apps. Some of the community (such as the famous Karsten Lentzsch) are trying to change the situation. The results of these "real" GUI designers can be... ahall we say... impressive.
Oooo, baiting! Keep up the show Mr. Troll. Perhaps I'll even let on how much work I've actually done so that you can have some cannonfodder. (NOT) You trolls are so amazingly transparent and pathetic. The funny part is that most of you are smart enough to have real jobs, real lives, real friends, and real spouses. But you screw up your lives so badly that you have to berate others to make yourselves feel better. Pathetic.
Are you really so stupid that you're going to link to a bunch of discredited microbenchmarks that use different algorithms for implementation, as well as superfluous and broken techniques for writing C and C++?
Pardon me, but didn't someone state that C/C++ was inherently *faster* than Java? Can it be? Is it possible that you can write bad code IN ANY LANGUAGE? Does that even mean that you can write good code IN ANY LANGUAGE?! The HORROR!!!
On a more serious note Mr. Troll, welcome to the wild and wooly world of Benchmarks. There is simply no way of giving an "accurate" measurment of language performance since either side can always argue that something was done incorrectly. However, there is one thing we can glean from these benchmarks (in a very general sense): Java and C are evenly matched competitors. Sometimes C will appear a bit faster, sometimes Java. So use what gets the job done right.
Some more benchmarks for you:
OS News
Older Benchmark on Ace's Hardware
Now, most of these benchmarks have been mentioned on Slashdot at one time or another. To date, I have not seen a *single* benchmark that displays results different to those in the above benchmarks. As I troll, I release you'd never want to reveal your secret identity (*snigger*), but perhaps you'd like to be the first to bring forward a viable benchmark showing the MASSIVE (i.e. non-existant) performance difference between Java and C? Or perhaps you'd like to continue this and get yourself pummeled that much harder?
Yep. Definitely a troll. At least that answers my question about his video card...
What the fuck are you talking about?
I could ask you the same thing. (Hint: Wikipedia sometimes gets things wrong.) Also from Wikipedia, Unisys MCP was written in ALGOL in 1961, a full decade before UNIX. Symbolics LISP OS was admittedly post Unix-invention, but it hit the general market about the same time as Unix.
You also have simply put out a list of unsubstantiated claims by saying "JAVA IS NOT SLOW". ... By not providing any real evidence to substantiate your claim that Java is NOT slow, you're no better (or worse) than I am with my posting that it IS slow.
I shouldn't need to provide this evidence. It is inherent in the forum of discussion we are currently using. Or do you wish to claim that you have been ignoring the various benchmark results that have appeared in this forum?
Thus I say again, you are making unsubstantiated claims. Please back up your claims or back off your claims. Hyperboles involving a meta-argument ("The fact that people have to try to fight this in 2004 would seem to indicate that the popular notion is that Java is slow") may provide amusment, but it does not provide evidence.
Why would you take hundreds of passes?
Because it's hierarchical data that is of unknown complexity. At the top of the hierarchy you have the root tag, which splits out into its attributes, sub-tags and CDATA. Each sub-tag again has the same split. Thus you have an exponential increase in complexity for every level the XML wraps.
No, you'd just need to use a few joins, a CONNECT BY
CONNECT BY is a new Oracle 10g feature to help support this sort of SQL DB nonsense. While it helps, the database really still has to make all the of hierarchical passes that you previously would have made manually.
and maybe a stored procedure.
If it involves a stored procedure, then you've already suggested that the query is too complex to be handled in a single SQL pass.
Things can get particularly dicey if you need all the data returned. For example, if I have a customer, I may wish to display his addresses and phone numbers on a page. In an XML database, this is one query, one transaction, and (when the data is changed) one update. For an SQL database, it's several queries, multiple result sets, and tons of updates. If you're serializing from XML, it even means that you'll need to delete the entire dataset out before performing the update. That kind of stings.
I think it's important to understand that flat data models have gone the way of the dinosaur. While they were very fast because of their easy record indexing, they have been replaced by more advanced (albeit more memory hungry) data structures. Had mainframe designers been given a choice, I can almost guarantee that they would not have used the fixed record model. Sadly, they had only a few kilobytes of memory to work with and had to stretch it as far as possible.
Ok, so you break down the XML by its structure. Now how do you do a valid query on it? Since you've completely dereferenced its structure and stuck it in a relational model, you've cut yourself off from the prospect of doing XPATH type queries. Instead, you'll need to make multiple (perhaps hundreds?) of passes at the table to reconstruct its data structure. XMLDBs don't have this problem. They deal with the XML in its natural form and are thus able to index, order, and query in that fashion.
As I said before, you can do many of the same things with an SQL database as you can with an XML database. That's not the point. The point is working with the data in a form that is natural to it and will provide the best results.
In what in this thread is referred to as SQL DBMS, the records have fixed length fields to make indexing possible.
This seems like an odd statement. As far as I'm aware, there are absolutely no requirements on the length of indexed fields. If there was, fields like VARCHARs couldn't be indexed. Many databases may optimize indexes based on size, but the real reason for maximum field length comes from the days of ISAM files. (Indexed flat files with fixed length records.)
I guess you could index an XML, but all index addresses would be wrong the minute you change a value in the first record.
XML databases don't actually work that way. It may seem "obvious" to create a database out of a massive XML file, but most implementations such as Apache Xindice actually deal with small XML fragments that hang off a larger table structure. Each "table" holds multiple fragments as records. If a record changes, the database reindexes the record in a similar fashion to SQL databases.
The primary differences between XML DBs and SQL DBs are that tables can be hierarchical, and the data can be hierarchical. A lot of details (such as the lack of NULL) also differ, but those are the main points.
A database would hopefully aleady have track of "red things" and shouldn't have to traverse a tree full of other useless data.
:-( The upshot is that with processing and storage power at all time highs many (most?) databases have no need to concern themselves with running out of storage resources. More than enough resources for a multi-gigabyte database exist on even the smallest modern PC.
In fact, that's exactly what a good XML database will do. By indexing all the accessible fields, it's able to provide fast access to database wide queries like the one you suggested. Of course, these indexes do come at a cost of disk space and memory, so not everything is quite rosy in Denmark.
I'm not quite sure what you're getting at but if you've read his work he's never saying that the concept of a missing attribute is "bad" just that the "NULL" method of representing it as such is.
In fact, if I understood him correctly, his problem was that NULL situations represent a lack of information, but they've been implemented as a type of information in of themselves. While the author may despise XML databases, they handle the situation correctly. i.e. The field does not exist.
Part of the problem is that simply not having a field would break First Normal Form. (First Normal Form states that all columns must exist in all records. Period.) Yet there the situation arises where an individual record may not have data for that column. Thus the dilemma. You can't get rid of NULLs and maintain Normal Form. The two are simply at odds with one another.
And the problem happens as soon as you want to know which producs uses a specific screw
What makes you say that? Assuming that the table is built as a "Product" XML block contains its parts, you could simply run an XPATH query against your "Product" table, looking for the part name or number. The results should actually be slightly faster than an SQL database since no JOINs are involved.