I really hope they're actually storing the meta-data in a DBMS table and only using XML as an interface when some DLL function 'get_xml_metadata' is called.
Re:Been saying it for years
on
CNet on WinFS
·
· Score: 1
The relational model is a general model of data. It can store anything.
And by the way -- data either has structure or it doesn't; the only useful unstructured data you'll find in a filesystem is the contents of/dev/rand.
That and the stupid 'calendar' remark. I don't use KDE (Gnome is what came on my RH box and it works for me) but EVER SINCE WINDOWS 95 you *double* click the clock to get a calendar. I mark this article -1, Troll.
It only 'supports' *some* logical integrity if you code it that way -- which means you have to do more work, it's more succeptible to bugs, you can forget to do it, etc.. Of course, there is more to integrity than foriegn keys.
Integrity generally means a whole lot of things - mostly 'logical' (think referential, domains, etc.) and 'physical' (ACID transactions, writing to disk, etc.).
You, perhaps inadvertently, mentioned the biggest advantage to the relational DBMS - declarative constraints/queries/etc. It's better (simpler, faster, less error prone) to be able to write declarative statements (e.g. 'Get me X') than procedural ('Here's how to get X') to do anything with data management.
You seem to know a bit on relational ideas, but really don't know much about the relational model.
The relational model is a general model of data -- it can model anything, including what one would think of as a typical object. Remember that no SQL product today is a RDBMS.
The fact that MySQL is 'dumb' has nothing to do with the absurdity of this product (and the 'RDBMS is dead' arguements).
Most modern-day SQL DBMS have DBMS-controlled data caches which store commonly accessed (generally on a MRU/LRU basis) data whose access is controlled by proper costing algorithms.
It's far easier to do it the MySQL way (assume the OS will cache it) but not nearly as powerful.
But the thing is that the RDBMS (which a 'true' one does not exist, of course) using logic and a sound model ensures that your data is safe and correct. This Prevlayer product has none of these and is basically, "We thought this might be neat, but can't really back it up by any sort of sound foundation. Good luck!"
to quote Fabian Pascal: The problem is that those who say 'right tool for the job' are usually those who have no clue what the job is -- they only know tools and how to apply them mechanically.
Personally, I like the Docking Station idea a bit better because it's far easier to set up and tear down which sounds petty but if you have to do it every day (e.g. you take your laptop home with you) you'll really appreciate it.
Also, LCDs aren't the most durable pieces of equipment - I think the chances of something breaking would increase significantly when you detach/reattach it.
Still, if the IBMs are cheaper than the docking station then I'd get one of those... But I know many companies have standardized on Dell so if you're looking for something like this in a Dell shop you don't have to break ranks.
There is no such thing as a 'Relational Database' - it's a Relational Database Management System. How the data is stored is irrelevant to the model (it's up to the RDBMS to determine how to store the data internally).
I'm not sure if you're being sarcastic or not, but a tuple (in the relational model) is an element (e.g. row) of a relation. I don't know what you mean by 'adjustble[sic] arrayed variables'. One difference is that arrays have an order and tuples do not.
By Physical I mean physical in the Relational sense, not 'writing 1s and 0s at the disk level'. Per Codd's Rule 8, Physical Data Independence: Interactive applications and application programs should not have to be modified whenever changes in internal storage structures and access methods are made to the database.
So physical in the cases of RDBMS would be the actual row format. XML, comma delimited lists, etc. would be examples of a 'physical' row format, and the 'logical' would be the table-ized presentation we're all used to.
Consider the 'snippet' of data that you talk about. It very well may live in a file, or spread out over several files. But that, along with the 'format' (XML, comma, etc.) is an implementation detail of the model which should not be exposed to the user. Like you say - it is simply data and how it is stored is irrelevant.
So - in the case of the relational model the user is not exposed to a 'file system' because that is an implementation detail. As far as abstraction is concerned I contend that exposing a file-oriented model to the end-user is far from intuitive. We think in 'emails', 'reports to the boss', 'post-its stuck to my monitor' etc. - and given proper tools (e.g. a proper RDBMS and presentation layers) they would never need to see the underlying implementation.
The relational model already has provisions for 'metadata' - it's built-in!! And as far as transferring between systems there are about a billion different formats, the least of which is XML (which I dislike for a number of reasons but seemingly has become the standard). Given knowledge on both ends (which would be required in your scenario as well) you could seamlessly transfer documents, contacts, emails, etc. between systems and maintain their related properties.
I don't think we're too far off in the end result, but the implementations are far different (and, given the relational model has already been proved to be sound, it makes perfect sense to use it).
Wow, you've been on Oracle since version 6? What a beast that was!
You have not used Oracle's database (unless you write low-level driver calls to the actual data itself) - you use Oracle's DBMS product.
In any rate, I find it difficult that you can say that MySQL is more 'accurate' than Oracle (and by extension PostgreSQL, or MS SQL Server, or Sybase ASE or...).
The constraint handling is poor at best (you can only have very minimal constraints). You have no such thing a triggers or views. The datatype bounds checking is horrendous (you can issue an insert statement with character values for numbers, for example, and it won't whine; it silently truncates values which are too small/large for the datatypes; you can insert nonsense dates in datetimes, etc.).
Obviously the biggest indicator of your trollish nature is the line: "MySQL has already killed Oracle's database". What a laugh! That is, like almost all of your post, 100% unsubstantiated and undefined. If any open-source product would ever be in a position to chip away at Oracle it would be PostgreSQL. At least those guys know a little bit about the relational model (even if they insist on breaking it).
In the relational model that is all encapsulated in the physical (e.g. internal to the RDBMS) data type. You, as an application developer/user doesn't give a hoot how it is physically stored - that's the whole point of abstraction! The concept of a "file" is gone - you would have a table datatype that would be defined with rows/columns/etc. and you would just select from it in your application.
The relational model also allows for definite relationships between the tuples (and indeed the different elements of the tuple).
For one that knows very, very little of the relational model you are quick to reject it.
Because, of course, performance is the sole indicator of a product's worth. Using that reasoning, everyone should be driving an Indy car instead of a station wagon.
Sure, the Volvo ($enterprise_DBMS) may not be quickest off the line as a Ferrari (MySQL) but I'd rather be in the Volvo when something goes wrong.
That paper fails to explain exactly how the relational model fails. Remember, the relational model *is* set theoretic and it would be trivial to solve the 'Santa' problem as posed in the article in a truly RDBMS.
The author makes the fallacy of equating SQL with Relational, so I can see how he might think the relational model can't cut it.
Before starting we should define (courtesy of Dictionary.com, paraphrased) some terms since I've seen them misused all over the place on this topic.
Database: One or more large structured sets of data. A simple database might be a single file containing many records, each of which contains the same set of fields where each field is a certain fixed width.
Database Management System (DBMS): A program or set of programs that manage databases, which includes data integrity and security. Examples are Oracle, PostgreSQL, Sybase ASE, etc.
To those who are saying "It doesn't make sense to treat the filesystem as a DBMS!" I ask you: "What is a multi-user (Windows NT, Unix, etc.) operating system?" It's a set of programs (or one, if you only include the kernel) that manage your computer and truly a large part of the OS' job is to manage your data. It has facilities to edit data, maintain user permissions and concurrency, handle searches, etc. - in fact, it has many, if not all, of the aspects of a DBMS already! You might as well call an OS a Computer Management System.
However - it lacks one key feature of the Relational DBMS - namely physical data independence. Before I explain that, let me ask you a question: What has the current hierarchical structure of file systems taught us?
Answer: It taught us that files and programs can only live in one directory and by extension of the directory idea (grouping like items) can only have one meaning. An MP3 described as/mp3/Adam_Kontras/Bread_in_the_Freezer.mp3 only tells me the name and the author's name but only if I know about the structure of the path. Can I take any MP3 and derive the author name by going up a directory? Not if I have/mp3/Adam_Kontras/4TVs/01-Intro.mp3!
Bread in the Freezer is a 'funny' song so if I wanted to I could put my funny authors in/mp3/humor/ (e.g./mp3/humor/Adam_Kontras/...) but not all of Adam's songs are funny. So I could do/mp3/Adam_Kontras/humor/... but now I lose the ability to see the authors that have funny songs. I suppose I could create symlinks and sprinkle them around, but then I can easily lose track of where the original file is located.
So, not only can a particular file have a single meaning it is essentially an arbitrary one. I can't derive value from the path unless I have mapping schemes somewhere that tell me that MP3s are stored by/Author/Album/Track or/Author/Track or $OneTrueWay.
Most importantly: Why should I?
That's where the Relational Model comes into play. Why should I care where files are stored on my hard drive? I only care that the file exists. The relational model separates the logical from the physical and allows me to get to the heart of the issue: my data.
That's why the relational model makes perfect sense as a storage mechanism. I no longer need to know WHERE it lives. It could live in/usr/foo, or heck it could even live on a different server. Given a suitable front-end which can generate the queries (or views) I would never need to memorize a file path ever again - because it would be meaningless.
Slashdot Mirror
you forgot:
ACLU 2 (passing out expensive Cuban cigars and cognac): Gentleman, a toast -- to evil!
To carry the (dead) joke further:
I for one welcome our new search-engine overlords.
Very very good! A thinking practitioner!
When only machines are talking it really doesn't matter WHAT the format is -- preferably it is unambiguous and somewhat speedy to transmit and parse.
As I said in another post - I seriously hope that the data is stored in a DBMS table and the XML-ized version is one (out of many) way to retrieve it.
I really hope they're actually storing the meta-data in a DBMS table and only using XML as an interface when some DLL function 'get_xml_metadata' is called.
The relational model is a general model of data. It can store anything.
/dev/rand.
And by the way -- data either has structure or it doesn't; the only useful unstructured data you'll find in a filesystem is the contents of
That and the stupid 'calendar' remark. I don't use KDE (Gnome is what came on my RH box and it works for me) but EVER SINCE WINDOWS 95 you *double* click the clock to get a calendar. I mark this article -1, Troll.
Did I talk about 'communications'? No. Read the grandparent -- "XML is for databases".
Couldn't resist: So if everyone else was jumping off of a bridge, you would, too?
It only 'supports' *some* logical integrity if you code it that way -- which means you have to do more work, it's more succeptible to bugs, you can forget to do it, etc.. Of course, there is more to integrity than foriegn keys.
Integrity generally means a whole lot of things - mostly 'logical' (think referential, domains, etc.) and 'physical' (ACID transactions, writing to disk, etc.).
You, perhaps inadvertently, mentioned the biggest advantage to the relational DBMS - declarative constraints/queries/etc. It's better (simpler, faster, less error prone) to be able to write declarative statements (e.g. 'Get me X') than procedural ('Here's how to get X') to do anything with data management.
And, of course:
here and here.
You seem to know a bit on relational ideas, but really don't know much about the relational model.
h tm
The relational model is a general model of data -- it can model anything, including what one would think of as a typical object. Remember that no SQL product today is a RDBMS.
Rather than wasting my time typing it out, check out this site:
http://www.dbdebunk.citymax.com/page/page/627014.
But you haven't mentioned anything about integrity, which is quite possibly the most important job a DBMS has: ensuring the data is correct.
Also, of course, how would you perform a JOIN (e.g. relate two lists)?
The fact that MySQL is 'dumb' has nothing to do with the absurdity of this product (and the 'RDBMS is dead' arguements).
Most modern-day SQL DBMS have DBMS-controlled data caches which store commonly accessed (generally on a MRU/LRU basis) data whose access is controlled by proper costing algorithms.
It's far easier to do it the MySQL way (assume the OS will cache it) but not nearly as powerful.
But the thing is that the RDBMS (which a 'true' one does not exist, of course) using logic and a sound model ensures that your data is safe and correct. This Prevlayer product has none of these and is basically, "We thought this might be neat, but can't really back it up by any sort of sound foundation. Good luck!"
to quote Fabian Pascal:
The problem is that those who say 'right tool for the job' are usually those who have no clue what the job is -- they only know tools and how to apply them mechanically.
Which means the vast majority of practitioners.
And I, and others, have pointed out XML is a horrible data storage format.
Dell has a 'Desktop Replacement' docking station that does much the same thing but you don't have to detatch your screen to do it.
Personally, I like the Docking Station idea a bit better because it's far easier to set up and tear down which sounds petty but if you have to do it every day (e.g. you take your laptop home with you) you'll really appreciate it.
Also, LCDs aren't the most durable pieces of equipment - I think the chances of something breaking would increase significantly when you detach/reattach it.
Still, if the IBMs are cheaper than the docking station then I'd get one of those... But I know many companies have standardized on Dell so if you're looking for something like this in a Dell shop you don't have to break ranks.
There is no such thing as a 'Relational Database' - it's a Relational Database Management System. How the data is stored is irrelevant to the model (it's up to the RDBMS to determine how to store the data internally).
I'm not sure if you're being sarcastic or not, but a tuple (in the relational model) is an element (e.g. row) of a relation. I don't know what you mean by 'adjustble[sic] arrayed variables'. One difference is that arrays have an order and tuples do not.
By Physical I mean physical in the Relational sense, not 'writing 1s and 0s at the disk level'. Per Codd's Rule 8, Physical Data Independence: Interactive applications and application programs should not have to be modified whenever changes in internal storage structures and access methods are made to the database.
So physical in the cases of RDBMS would be the actual row format. XML, comma delimited lists, etc. would be examples of a 'physical' row format, and the 'logical' would be the table-ized presentation we're all used to.
Consider the 'snippet' of data that you talk about. It very well may live in a file, or spread out over several files. But that, along with the 'format' (XML, comma, etc.) is an implementation detail of the model which should not be exposed to the user. Like you say - it is simply data and how it is stored is irrelevant.
So - in the case of the relational model the user is not exposed to a 'file system' because that is an implementation detail. As far as abstraction is concerned I contend that exposing a file-oriented model to the end-user is far from intuitive. We think in 'emails', 'reports to the boss', 'post-its stuck to my monitor' etc. - and given proper tools (e.g. a proper RDBMS and presentation layers) they would never need to see the underlying implementation.
The relational model already has provisions for 'metadata' - it's built-in!! And as far as transferring between systems there are about a billion different formats, the least of which is XML (which I dislike for a number of reasons but seemingly has become the standard). Given knowledge on both ends (which would be required in your scenario as well) you could seamlessly transfer documents, contacts, emails, etc. between systems and maintain their related properties.
I don't think we're too far off in the end result, but the implementations are far different (and, given the relational model has already been proved to be sound, it makes perfect sense to use it).
Wow, you've been on Oracle since version 6? What a beast that was!
...).
You have not used Oracle's database (unless you write low-level driver calls to the actual data itself) - you use Oracle's DBMS product.
In any rate, I find it difficult that you can say that MySQL is more 'accurate' than Oracle (and by extension PostgreSQL, or MS SQL Server, or Sybase ASE or
The constraint handling is poor at best (you can only have very minimal constraints). You have no such thing a triggers or views. The datatype bounds checking is horrendous (you can issue an insert statement with character values for numbers, for example, and it won't whine; it silently truncates values which are too small/large for the datatypes; you can insert nonsense dates in datetimes, etc.).
Obviously the biggest indicator of your trollish nature is the line: "MySQL has already killed Oracle's database". What a laugh! That is, like almost all of your post, 100% unsubstantiated and undefined. If any open-source product would ever be in a position to chip away at Oracle it would be PostgreSQL. At least those guys know a little bit about the relational model (even if they insist on breaking it).
MySQL guys go 'Codd who?'
In the relational model that is all encapsulated in the physical (e.g. internal to the RDBMS) data type. You, as an application developer/user doesn't give a hoot how it is physically stored - that's the whole point of abstraction! The concept of a "file" is gone - you would have a table datatype that would be defined with rows/columns/etc. and you would just select from it in your application.
The relational model also allows for definite relationships between the tuples (and indeed the different elements of the tuple).
For one that knows very, very little of the relational model you are quick to reject it.
Oh, please, keep those (trolls) coming.
Because, of course, performance is the sole indicator of a product's worth. Using that reasoning, everyone should be driving an Indy car instead of a station wagon.
Sure, the Volvo ($enterprise_DBMS) may not be quickest off the line as a Ferrari (MySQL) but I'd rather be in the Volvo when something goes wrong.
Yes we do need a new model and yes, we have one: it's called the Relational Model.
We've discussed this before.
That paper fails to explain exactly how the relational model fails. Remember, the relational model *is* set theoretic and it would be trivial to solve the 'Santa' problem as posed in the article in a truly RDBMS.
The author makes the fallacy of equating SQL with Relational, so I can see how he might think the relational model can't cut it.
Before starting we should define (courtesy of Dictionary.com, paraphrased) some terms since I've seen them misused all over the place on this topic.
/mp3/Adam_Kontras/Bread_in_the_Freezer.mp3 only tells me the name and the author's name but only if I know about the structure of the path. Can I take any MP3 and derive the author name by going up a directory? Not if I have /mp3/Adam_Kontras/4TVs/01-Intro.mp3!
/mp3/humor/ (e.g. /mp3/humor/Adam_Kontras/...) but not all of Adam's songs are funny. So I could do /mp3/Adam_Kontras/humor/... but now I lose the ability to see the authors that have funny songs. I suppose I could create symlinks and sprinkle them around, but then I can easily lose track of where the original file is located.
/Author/Album/Track or /Author/Track or $OneTrueWay.
/usr/foo, or heck it could even live on a different server. Given a suitable front-end which can generate the queries (or views) I would never need to memorize a file path ever again - because it would be meaningless.
Database: One or more large structured sets of data. A simple database might be a single file containing many records, each of which contains the same set of fields where each field is a certain fixed width.
Database Management System (DBMS): A program or set of programs that manage databases, which includes data integrity and security. Examples are Oracle, PostgreSQL, Sybase ASE, etc.
To those who are saying "It doesn't make sense to treat the filesystem as a DBMS!" I ask you: "What is a multi-user (Windows NT, Unix, etc.) operating system?" It's a set of programs (or one, if you only include the kernel) that manage your computer and truly a large part of the OS' job is to manage your data. It has facilities to edit data, maintain user permissions and concurrency, handle searches, etc. - in fact, it has many, if not all, of the aspects of a DBMS already! You might as well call an OS a Computer Management System.
However - it lacks one key feature of the Relational DBMS - namely physical data independence. Before I explain that, let me ask you a question:
What has the current hierarchical structure of file systems taught us?
Answer: It taught us that files and programs can only live in one directory and by extension of the directory idea (grouping like items) can only have one meaning. An MP3 described as
Bread in the Freezer is a 'funny' song so if I wanted to I could put my funny authors in
So, not only can a particular file have a single meaning it is essentially an arbitrary one. I can't derive value from the path unless I have mapping schemes somewhere that tell me that MP3s are stored by
Most importantly: Why should I?
That's where the Relational Model comes into play. Why should I care where files are stored on my hard drive? I only care that the file exists. The relational model separates the logical from the physical and allows me to get to the heart of the issue: my data.
That's why the relational model makes perfect sense as a storage mechanism. I no longer need to know WHERE it lives. It could live in
Online replication is generally considered by professional DBAs a fools errand.
Not if you use a capable replication solution (see rep server and open switch).