So, XML can impose more constraints than relational databases, as relational stores have no idea about order, and work only in terms of sets. First of all, it's misleading to say that RDMBSs work in terms of "sets". They work in terms of relations, and a relation can be as restricted as a single attribute and tuple pairing, or as complex as the entire set of data. Secondly, RDBMSs have no sense of "order" becuase they don't need it. There is no order that can not be arbitrarily applied on the fly via queries, or reused again and again via views. In fact, the only order that can not be inherently applied to data is "random", which can be enforced by keying the data against an autonumber or identity field (a practice which drives me crazy).
Third, XML imposes no constraints. Relational algebra is an actual, tangible thing which, with a limited number of inputs, can be used to restrict data to ensure consistency and atomicity. XML is just whatever data you want to toss into a text file. You can build a DTD or Schema, sure, but how is that any different, really, from just building a complicated application specific to that data to manage the data for you and then tossing it into a text file without the XML?
I don't think I have to worry about feeling foolish since, at the time of your post, I had already said everything about the technologies involved that you have, minus the critical terminology errors and made up accusations, but with significantly less chest-thumping and superiority complex.
...it is addressing the issues of data formats going out of date.
But data formats aren't storage, they're representation.
There are few inherent enforcements in relational systems - things constraints and foreign keys are optional There are many inherent enforcement in relational systems. There also happen to be many psuedo-relational system masquerading as something they're not.
Also, you can't impose in a relational system the range of constraints you can impose with XML, such as ordering of data.
That's not true, you can order your datasets in any way you want* when you retrieve them as long as you put them in in a meaningful way to begin with (or, if your order is totally meaningless, keyed it to an autonumber/identity attribute), they're just not stored on the physical medium in an "ordered" fashion of your choosing, which is hardly relevant because a saved XML file probably isn't either.
* need to order chronologically? Store and inspect a creation date. Need to order alphabetically? Trivial. Need to order by byte size? No problem. There's no way that a reasonably built RDBMS can't order data, except randomly, which you can always accomplish with the presence of an identity attribute.
This can be an area where XML is very important, as it has been specifically designed as a format that is resistant to becoming unreadable over time, perhaps due to the software that writes a format becoming unsupported.
?
Yes, but it's not actually a storage system, so it still has to be stored in one, so it's still going to be subject to the problems you mention.
If you want to avoid such problems, you can prevent them.
But you have to define that on a case-by-case basis, it's not an inherent enforcement like one finds in relational systems.
Would you please explain where the data in your example is "stored" if not in the XML file that you just plainly stated is being searched by the web application. It does not matter one wit what is better, RDBs or XML. RDBs "store" there data in files on a file system.
I have explicitly stated that I am not denying that people create storage systems based on XML, I have explicitly given the common name to those types of storage systems twice. Please be sure to read the entire thread through before responding in the future.
XML is data storage XML is data description, and people (wrongly) use that to build storage systems. The difference between XML and, for example, a dedicated filesystem, is that the XML was not built to organize and store data for the purpose of retreival, and the filesystem was.
Most companies receive far too many checks in a day to process them by hand. Generally speaking, most checks are simply processed via machine and stored. This is a risk the bank is taking, not you. If somebody were to try and defraud them, and it turned out they tried to cash an unsigned stolen check from your checkbook, they'd be out the money unless they could recover it from the crook.
I wouldn't worry too much about it. There are much more obvious and cruel ways in which banks screw over honest people on a daily basis. For some of the most corrupt practices, I recommend a stint with Bank of America. By far, they're the worst of the bunch I've ever dealt with.
When talking about "storage", we're talking about certain properties and functions that relate to actually manipulating, storing, and retrieving the data. For example, a filesystem is involved in "storage" because it provides functionality for all of those things, whether moving the data into a more logical structure (manipulation), or saving (storing) or fetching (retrieving) it.
XML doesn't intrinsically do any of these things. When people speak about "storage" in XML, they're talking about applications that use XML's descriptive ability to organize data so that it can be saved and recovered. For example, you may have an application that performs a website search by looking through XML files for a list of names. It will open the file, find the tags, and then test the stored data against the criteria, contining until it finds what it needs. This is a waste, as the task could be performed much better by a RDBMS.
You would use this XML file in other situations, however. For example, if you are a banker and you are sending data about a new client to DHS to review, you might encapsulate the data in your XML tags so that when it is recieved by DHS, a filter can move it from the file you sent into its own systems even though the data came out of your systems in a totally incomprehensible (to DHS) format.
Also, XML is not error prone - it is designed to be easily retrievable and validatable.
Heirarchical, non-related systems are extremely error prone, as they provide no way to prevent duplicating data sets, removing related data sets when a key piece of the data is removed, or safely retrieving all related data sets upon request. "Tree" databases have a very, very nasty habit of becoming quickly corrupted by invalid or duplicate data.
No, XML should not be used in relation to storing data. You can build a system which uses XML to store data, I'm not contesting that, and I already mentioned what that technology is: it's called a heirarchicial DBMS, and they've long been known to be inferior tools.
XML's purpose is not data storage, it's data description. People try to use those descriptive properties to generate applications which use XML stored on disk to store data within the stored file, but that's a waste. It's like trying to turn a car into a boat when you could just easily go obtain a boat. Sure, you can do it, but it's inefficient, error prone, and doesn't actually have any pros associated with it in 99.999999999% of all cases.
Despite the fact that the OP had numerous factual, logical, and emotional errors in his post, the best you could do was make up a bunch of pretend properties for him/her ("liberal", "rich kid", "Canadian") and go off on a vulgar tangent that may well have absolutely nothing to do with the actual poster in reality.
Gee, I just can't understand why conservatives (being that you implied you are a conservative) got stuck with that image of being a bunch of ignorant, under-educated boobs... nope, not with such terribly intelligent discourse as you've given us here today.
A dynamic, templating system should be used where the updates to the site are so frequent that it would be unreasonable to expect that the site's maintainers would be able to keep up if they had to edit the pages every time the state of the system changed. Slashdot would be a prime example.
However, if you are not changing data frequently, or the state of your site is not necessarily subject to the input of its users, you don't really need a database system at all, unless you're merely tapping it because it already exists for some other purpose. A site like CNN.com would be an example. It's not unreasonable to believe that the site could not be maintained by hand since they have near complete control over the changes, and the changes are not constant.
If XML is not for storing data, then why is the OpenDocument format XML?
That defines data, it does not store it. As I noted in another response to the original poster, XML is not handling any of the storage in any way, the filesystem is handling all of those functions the same way it would if it was retrieving any other type of file. When OOo opens that file, it doesn't use the XML in any way to retrieve the data, it uses the XML as an interface between text-only representation on the disck and formatted screen representation of that file. In other words, it's a transfer medium to translate the plain-text data to an actual office document, nothing more.
Somewhat more that (sic) column separation, perhaps?
And a Dodge Viper is more than a Model T, but both objects still exist for the same intrinsic purpose. The fact that one is more advanced and better suited to certain purposes doesn't make them different things.
XML has nothing to do with storing data. An XML file is not a "storage tool", and when people try to make it one, all they do is build a heirarchical DBMS, which is a system of data storage and retreival that failed at all but the most specialized applications back in the 60s when it was first attempted.
You're not storing the data "in XML", you're storing it on the filesystem in files that describe the data via XML. The performance benefit of the static data over the RDBMS data store is provided by the filesystem, not as a function of XML. To the contrary, your retrieval of the data is actually hindered by the XML because it increases the size of the files that must be retreived and transferred.
XML is not for "storing data". I can't believe people still find that confusing in this day and age. XML is for describing data. It's little more than a loosely built, glorified file format. It serves no more purpose to data than tabs seperating "columns" in a text file do.
XML is good for transferring data between systems. It is not good for storing data, which is what databases are for, or presenting data, which is what applications are for.
See, the problem with you is that you think that what you say is the way things are. Unfortunately for you, everyone can always go back and read my original post, and note - via the basic reading comprehension that you so grandly display no pretense of having - that what you're bitching about in it apparently only exists in your tiny, demented brain.
But I'm tired of the vehemently anti-Christian, anti-any-religion mindset on Slashdot...
Then maybe you should stop posting and making normal Christians look like screaming retards, because making things up to be offended by sure does make you look like a lunatic fringe member...
Ignoring your typical, condescending, vehemently anti-religious comment about a large cross-section of normal folks with a certain set of faith beliefs you happen to disagree with in an attempt to feel enlightened...
The fringe I speak of is comprised of "a large cross-section of normal folks"? Who have a "certain set of faith beliefs [sic]"?
Congratulations, you just called the typical Christian church-goer a fringe lunatic because you were offended by my comment regarding an actual fringe of lunatics that, by definition, had nothing to do with the typical Christian church-goer.
Maybe you should spend a little less time being a reactionary, overly-critical zealot so that you have some extra open time to think before you post stupid comments like that.
I don't think it teaches anything about how life was created. It's about evolution, and evolution has no solid say on that particular question at the moment.
It teaches about how life, once it existed in its simplest form, got to be so complex. That's not the same thing. Not that Pat Robertson is capable of making such an important distinction, since the odds that he's even slightly acquainted with reality anymore are pretty much null, but I still felt the need to make that point.
How long until the lunatic right fringe elements start screaming over the subject matter, or until Jack Thompson files a (doomed to fail) lawsuit on the grounds that it dehumanizes human life and makes kids into killers who think their victims are nothing more than petri-dish bug projects?
Slashdot Mirror
Because the database you're using doesn't support it. Investigate other vendors.
So, XML can impose more constraints than relational databases, as relational stores have no idea about order, and work only in terms of sets.
First of all, it's misleading to say that RDMBSs work in terms of "sets". They work in terms of relations, and a relation can be as restricted as a single attribute and tuple pairing, or as complex as the entire set of data. Secondly, RDBMSs have no sense of "order" becuase they don't need it. There is no order that can not be arbitrarily applied on the fly via queries, or reused again and again via views. In fact, the only order that can not be inherently applied to data is "random", which can be enforced by keying the data against an autonumber or identity field (a practice which drives me crazy).
Third, XML imposes no constraints. Relational algebra is an actual, tangible thing which, with a limited number of inputs, can be used to restrict data to ensure consistency and atomicity. XML is just whatever data you want to toss into a text file. You can build a DTD or Schema, sure, but how is that any different, really, from just building a complicated application specific to that data to manage the data for you and then tossing it into a text file without the XML?
I don't think I have to worry about feeling foolish since, at the time of your post, I had already said everything about the technologies involved that you have, minus the critical terminology errors and made up accusations, but with significantly less chest-thumping and superiority complex.
...it is addressing the issues of data formats going out of date.
But data formats aren't storage, they're representation.
There are few inherent enforcements in relational systems - things constraints and foreign keys are optional
There are many inherent enforcement in relational systems. There also happen to be many psuedo-relational system masquerading as something they're not.
Also, you can't impose in a relational system the range of constraints you can impose with XML, such as ordering of data.
That's not true, you can order your datasets in any way you want* when you retrieve them as long as you put them in in a meaningful way to begin with (or, if your order is totally meaningless, keyed it to an autonumber/identity attribute), they're just not stored on the physical medium in an "ordered" fashion of your choosing, which is hardly relevant because a saved XML file probably isn't either.
* need to order chronologically? Store and inspect a creation date. Need to order alphabetically? Trivial. Need to order by byte size? No problem. There's no way that a reasonably built RDBMS can't order data, except randomly, which you can always accomplish with the presence of an identity attribute.
This can be an area where XML is very important, as it has been specifically designed as a format that is resistant to becoming unreadable over time, perhaps due to the software that writes a format becoming unsupported.
?
Yes, but it's not actually a storage system, so it still has to be stored in one, so it's still going to be subject to the problems you mention.
If you want to avoid such problems, you can prevent them.
But you have to define that on a case-by-case basis, it's not an inherent enforcement like one finds in relational systems.
Would you please explain where the data in your example is "stored" if not in the XML file that you just plainly stated is being searched by the web application. It does not matter one wit what is better, RDBs or XML. RDBs "store" there data in files on a file system.
I have explicitly stated that I am not denying that people create storage systems based on XML, I have explicitly given the common name to those types of storage systems twice. Please be sure to read the entire thread through before responding in the future.
XML is data storage
XML is data description, and people (wrongly) use that to build storage systems. The difference between XML and, for example, a dedicated filesystem, is that the XML was not built to organize and store data for the purpose of retreival, and the filesystem was.
Most companies receive far too many checks in a day to process them by hand. Generally speaking, most checks are simply processed via machine and stored. This is a risk the bank is taking, not you. If somebody were to try and defraud them, and it turned out they tried to cash an unsigned stolen check from your checkbook, they'd be out the money unless they could recover it from the crook.
I wouldn't worry too much about it. There are much more obvious and cruel ways in which banks screw over honest people on a daily basis. For some of the most corrupt practices, I recommend a stint with Bank of America. By far, they're the worst of the bunch I've ever dealt with.
When talking about "storage", we're talking about certain properties and functions that relate to actually manipulating, storing, and retrieving the data. For example, a filesystem is involved in "storage" because it provides functionality for all of those things, whether moving the data into a more logical structure (manipulation), or saving (storing) or fetching (retrieving) it.
XML doesn't intrinsically do any of these things. When people speak about "storage" in XML, they're talking about applications that use XML's descriptive ability to organize data so that it can be saved and recovered. For example, you may have an application that performs a website search by looking through XML files for a list of names. It will open the file, find the tags, and then test the stored data against the criteria, contining until it finds what it needs. This is a waste, as the task could be performed much better by a RDBMS.
You would use this XML file in other situations, however. For example, if you are a banker and you are sending data about a new client to DHS to review, you might encapsulate the data in your XML tags so that when it is recieved by DHS, a filter can move it from the file you sent into its own systems even though the data came out of your systems in a totally incomprehensible (to DHS) format.
Also, XML is not error prone - it is designed to be easily retrievable and validatable.
Heirarchical, non-related systems are extremely error prone, as they provide no way to prevent duplicating data sets, removing related data sets when a key piece of the data is removed, or safely retrieving all related data sets upon request. "Tree" databases have a very, very nasty habit of becoming quickly corrupted by invalid or duplicate data.
No, XML should not be used in relation to storing data. You can build a system which uses XML to store data, I'm not contesting that, and I already mentioned what that technology is: it's called a heirarchicial DBMS, and they've long been known to be inferior tools.
XML's purpose is not data storage, it's data description. People try to use those descriptive properties to generate applications which use XML stored on disk to store data within the stored file, but that's a waste. It's like trying to turn a car into a boat when you could just easily go obtain a boat. Sure, you can do it, but it's inefficient, error prone, and doesn't actually have any pros associated with it in 99.999999999% of all cases.
Despite the fact that the OP had numerous factual, logical, and emotional errors in his post, the best you could do was make up a bunch of pretend properties for him/her ("liberal", "rich kid", "Canadian") and go off on a vulgar tangent that may well have absolutely nothing to do with the actual poster in reality.
Gee, I just can't understand why conservatives (being that you implied you are a conservative) got stuck with that image of being a bunch of ignorant, under-educated boobs... nope, not with such terribly intelligent discourse as you've given us here today.
A dynamic, templating system should be used where the updates to the site are so frequent that it would be unreasonable to expect that the site's maintainers would be able to keep up if they had to edit the pages every time the state of the system changed. Slashdot would be a prime example.
However, if you are not changing data frequently, or the state of your site is not necessarily subject to the input of its users, you don't really need a database system at all, unless you're merely tapping it because it already exists for some other purpose. A site like CNN.com would be an example. It's not unreasonable to believe that the site could not be maintained by hand since they have near complete control over the changes, and the changes are not constant.
If XML is not for storing data, then why is the OpenDocument format XML?
That defines data, it does not store it. As I noted in another response to the original poster, XML is not handling any of the storage in any way, the filesystem is handling all of those functions the same way it would if it was retrieving any other type of file. When OOo opens that file, it doesn't use the XML in any way to retrieve the data, it uses the XML as an interface between text-only representation on the disck and formatted screen representation of that file. In other words, it's a transfer medium to translate the plain-text data to an actual office document, nothing more.
Somewhat more that (sic) column separation, perhaps?
And a Dodge Viper is more than a Model T, but both objects still exist for the same intrinsic purpose. The fact that one is more advanced and better suited to certain purposes doesn't make them different things.
XML has nothing to do with storing data. An XML file is not a "storage tool", and when people try to make it one, all they do is build a heirarchical DBMS, which is a system of data storage and retreival that failed at all but the most specialized applications back in the 60s when it was first attempted.
You're not storing the data "in XML", you're storing it on the filesystem in files that describe the data via XML. The performance benefit of the static data over the RDBMS data store is provided by the filesystem, not as a function of XML. To the contrary, your retrieval of the data is actually hindered by the XML because it increases the size of the files that must be retreived and transferred.
XML is not for "storing data". I can't believe people still find that confusing in this day and age. XML is for describing data. It's little more than a loosely built, glorified file format. It serves no more purpose to data than tabs seperating "columns" in a text file do.
XML is good for transferring data between systems. It is not good for storing data, which is what databases are for, or presenting data, which is what applications are for.
You don't need to follow basic computer security principles involved in "proving" behaviors if you have enough guns at your disposal.
A FASCIST in power is a tyrant, right?
No.
Many facists are democratically elected rulers. It badly weakens your argument when you fail to recognize the most basic terminology involved in it.
See, the problem with you is that you think that what you say is the way things are. Unfortunately for you, everyone can always go back and read my original post, and note - via the basic reading comprehension that you so grandly display no pretense of having - that what you're bitching about in it apparently only exists in your tiny, demented brain.
But I'm tired of the vehemently anti-Christian, anti-any-religion mindset on Slashdot
Then maybe you should stop posting and making normal Christians look like screaming retards, because making things up to be offended by sure does make you look like a lunatic fringe member...
Ignoring your typical, condescending, vehemently anti-religious comment about a large cross-section of normal folks with a certain set of faith beliefs you happen to disagree with in an attempt to feel enlightened...
The fringe I speak of is comprised of "a large cross-section of normal folks"? Who have a "certain set of faith beliefs [sic]"?
Congratulations, you just called the typical Christian church-goer a fringe lunatic because you were offended by my comment regarding an actual fringe of lunatics that, by definition, had nothing to do with the typical Christian church-goer.
Maybe you should spend a little less time being a reactionary, overly-critical zealot so that you have some extra open time to think before you post stupid comments like that.
I don't think it teaches anything about how life was created. It's about evolution, and evolution has no solid say on that particular question at the moment.
It teaches about how life, once it existed in its simplest form, got to be so complex. That's not the same thing. Not that Pat Robertson is capable of making such an important distinction, since the odds that he's even slightly acquainted with reality anymore are pretty much null, but I still felt the need to make that point.
The innovation creates the franchise. Try to keep up.
They're just waiting for it to mutate into Duke Nukem Forever.
How long until the lunatic right fringe elements start screaming over the subject matter, or until Jack Thompson files a (doomed to fail) lawsuit on the grounds that it dehumanizes human life and makes kids into killers who think their victims are nothing more than petri-dish bug projects?