Before we start, remember: a database is a collection of data. A DBMS is the system used to store, retrieve, maintain, etc. the data IN the database. A Relational Database Management System is a DBMS which relies on predicate logic, logical data independence, and set theory to maintain the data in the database. Codd invented this in (I think) 1969/70.
This makes no difference if you write your application correctly and check your data going in for VALIDITY. It shouldn't be the DB server's job to enforce this...
No. No, no, no, No, NO, NO. This backwards, uneducated thinking is why DB-driven applications are increasingly becoming more bloated, buggy, and just plain wrong.
The Relational Database Management System (RDBMS) is NOT just a place to stick data in. Codd, fed up with basically inventing a DBMS every time an application was written and being forced to implement checking and other things in the application, penned his ideas on Relational Theory.
The RDBMS, through application of predicate logic, guarantees correctness (consistency) of your data. It's that simple.
If you don't allow the RDBMS to guarantee your data is correct, then you are a fool, ignorant, or both.
the database shouldn't know that such and such is not a valid doohicky because the wotsit is set to foo.
*jumping up and down mad*
(ignoring the misuse of 'database') YES IT SHOULD! That's the WHOLE POINT of a DBMS! Certainly a good portion of logic should live in your application. But 'business rules', constraints, anything that deals with your data etc. BELONG in the RDBMS, because how else are you to ensure that the data you pull out of it is correct? You can't.
They might have access to your files if you are sharing them.
That's true, they could download a sampling of your files and then generate the hashes. I don't see the RIAA doing that, though. The checksums are only interesting in this isolated case - namely that the defendant is claiming that the MP3s were legally obtained (and could, presumably, provide the source media).
Going through thousands of MP3s and changing the data to change the checksum is the simplest way to make this claim - however since the MP3 process (rip-n-compress) is inherently lossy (given all the posts on this thread so far indicating that it is difficult to produce identical MP3s from the *same source*) you would need to prove that your file's flaws are only coincidentally identical to the commonly-stolen one (since you obtained it from a P2P source, after all).
So, you'd need to change enough of the data to remove ripping/encoding flaws that someone else made. Can you still do that and not destroy the MP3?
In short, I don't see that modifying the checksum is of any use. If you are sharing MP3s you are stupid and most likely will get caught and find yourself in court. People seem to think that they can get off on a 'technicality'. Are you even thinking that the RIAA isn't going to still file a subpoena because your hash doesn't match theirs? The RIAA smells blood - the best advice is to steer clear and not steal MP3s.
Of course, if they do some sort of method to de-couple the MP3 data from the ID3 tag data *then* compare MD5 checksums then yes, you could have a problem.
However I doubt that they will go to such trouble -- if they have access to your files you're pretty much caught red-handed. A different MD5 checksum won't get you off of the hook here.
Yeah, but editing the bytes/re-encoding/etc. is an overly complex solution to the problem. As the parent said simply add/change a character in the comments field of the ID3 tag; this is something that any user can do without complex tools and without risk to the data.
Obviously if *all* the fields are filled to the brim (very, very unlikely) with 'good' data then there's a chance that you could introduce inaccurate ID3 tag data, but I have yet to see anything mission-critical relying on the ID3 tag.
And look at the option price they're purchasing for: 2003-07-15 WILSON, MICHAEL SEAN Senior Vice President 6,000 Sale at $10.66 - $10.8 per share. (Proceeds of about $64,000)
2003-07-14 WILSON, MICHAEL Senior Vice President 6,000 Option Exercise at $0.66 per share. (Cost of $3,960)
Spend $4,000 to gross $64,000. I'm in the wrong line of work!
Do you not see the huge absurdity of BINARY XML? It's an oxymoron!
XML is 'supposed' to be a nice little data interchange format. It's not a data storage mechanism (because relational DBMSs are far, far superior) yet misguided people like this are trying to use it as one.
Converting XML to binary? Why go to all the trouble to run it through an XML parser etc. first if you're just going to send a binary file? Use a more efficient file format!
In reply to the parent post (by MattRog) of your post, how on earth can a fully normalized database save you from not having to use NULLs? I'm sorry, I just can't follow your point.
Because 'nulls' (or so-called three value logic) have no place in the relational model. Either you have a value or you don't.
In a fully normalized schema you'd have what are essentially 'R-tables' (in Codd/Date speak) which represent one entity type.
So, you probably would have: fname( PersonID, FirstName ) lname( PersonID, LastName ) etc.
Obviously storing a row with a PersonID with a null last name is redundant -- the lack of a row in lname is all you need (or actually don't need, as it were).
That, and there is virtually NO domain (aka type) checking at all.
I can happily insert numbers that are too large or too small (and it just rounds up/down, respectively), numbers that are actually strings, dates which are not dates, and any combination of the above.
But the 'business logic' (depends on your definition of business logic, really) is intrinsically tied to the data. Without it, your data is meaningless.
That's the (well a major) whole point of a relational database management system. Your RDBMS is a series of axioms -- namely constraints -- a la business rules.
The problem with traditional three-tiered architectures is that they are a throwback to 'roll-your-own' DBMSs that plagued the industry in the 50s, 60s, and 70s. At least many of the 'business rules engines' are declarative and not procedural, but it still needs to be under control of the RDBMS.
I've generally found quite the opposite in trying to teach complicated joins to people. I can understand it both ways, but the newbies generally don't like the mashing of everything together in the where clause.
I like the ANSI method because it clearly defines where the join conditions are.
What is the benefit to this? I don't get it. Well, I do, but I don't see how it is that entirely too useful.
All it tells you is how many rows are in the particular table. The number of rows in the result is, of course, count( * ) + 1 since you have to account for the aggregate.
I assume you're doing something like (some weird pseudocode): select * from table
put first row into rowcount
for( i = 1 to rowcount )
output 'row ' + i + ' of ' + rowcount
To the other guy who said it doubles query time that is not true if the count is using an index. Index scans are usually very fast.
The only reason why nulls are 'needed' is because the tables are not fully normalized. If you fully normalize your table the lack of a relationship is clear -- there is no row that matches parent = 123, fk = 456.
The RIAA's lawyers are not stupid. Something tells me the notices they send out do not say anything near to "We legally represent the copyright holder of the song YourFile.MP3" -- precisely due to the perjury clause. We've seen examples that are generally much more vague, but the vagueness is generally all it takes to get the Uni to take a look at it. Was the professor ever taken to court? Of course not.
Your argument doesn't pass the reasonable person test - no court in the US is ever going to think the RIAA is making that claim... because they aren't.
It didn't mention this in the article so I thought I'd post here and ask. I just recently purchased a US passport which doesn't expire for 10 years. Will I be required to purchase the 'upgrade' to the new passport or can I continue to use it until it expires in 2013?
With all the outstanding passports I couldn't imagine the US Gov would re-issue new ones for free. Hopefully we'll all be 'grandfathered' in, although since it is their property they could revoke them in Oct. 2004.:(
It's a lot of fun, too. Not to mention a lot of time and effort -- but if you have the time the results over electric and the Mach 3 are nothing short of fantastic.
Is the concept of an album - e.g. a group of songs conveniently less than 74 minutes in total length - be obsolete?
Originally, and I'm just speculating, the album made sense. There had to be enough music there to satisfy the audience and convince them that paying $XX dollars for it was 'worth it'. With the advent of the internet (thanks Al!) we no longer think of downloading an 'album' but downloading 'the songs we like'.
Should the distribution model of a CD be eschewed for a direct release of individual songs? Radio stations very, very rarely play more than a handful of tracks from an album as it is. If you want to listen to it in your stereo use WAP or Bluetooth to listen to your home PC playlist. Your car stereo could read DRM discs and play all your tracks on a burned DVD.
A lot of people think DRM is the devil - but implemented correctly it could allow for an individual to do anything they want with the purchased media and would allow for the record companies to continue to make money. It would get rid of questions like 'Is this MP3 legal?' because the only way it would be is if you had the certificate for it. No fuss, no muss.
Slashdot Mirror
Before we start, remember: a database is a collection of data. A DBMS is the system used to store, retrieve, maintain, etc. the data IN the database. A Relational Database Management System is a DBMS which relies on predicate logic, logical data independence, and set theory to maintain the data in the database. Codd invented this in (I think) 1969/70.
This makes no difference if you write your application correctly and check your data going in for VALIDITY. It shouldn't be the DB server's job to enforce this...
No. No, no, no, No, NO, NO. This backwards, uneducated thinking is why DB-driven applications are increasingly becoming more bloated, buggy, and just plain wrong.
The Relational Database Management System (RDBMS) is NOT just a place to stick data in. Codd, fed up with basically inventing a DBMS every time an application was written and being forced to implement checking and other things in the application, penned his ideas on Relational Theory.
The RDBMS, through application of predicate logic, guarantees correctness (consistency) of your data. It's that simple.
If you don't allow the RDBMS to guarantee your data is correct, then you are a fool, ignorant, or both.
the database shouldn't know that such and such is not a valid doohicky because the wotsit is set to foo.
*jumping up and down mad*
(ignoring the misuse of 'database') YES IT SHOULD! That's the WHOLE POINT of a DBMS! Certainly a good portion of logic should live in your application. But 'business rules', constraints, anything that deals with your data etc. BELONG in the RDBMS, because how else are you to ensure that the data you pull out of it is correct? You can't.
Of course, if they do some sort of method to de-couple the MP3 data from the ID3 tag data *then* compare MD5 checksums then yes, you could have a problem.
However I doubt that they will go to such trouble -- if they have access to your files you're pretty much caught red-handed. A different MD5 checksum won't get you off of the hook here.
Yeah, but editing the bytes/re-encoding/etc. is an overly complex solution to the problem. As the parent said simply add/change a character in the comments field of the ID3 tag; this is something that any user can do without complex tools and without risk to the data.
Obviously if *all* the fields are filled to the brim (very, very unlikely) with 'good' data then there's a chance that you could introduce inaccurate ID3 tag data, but I have yet to see anything mission-critical relying on the ID3 tag.
And look at the option price they're purchasing for:
2003-07-15 WILSON, MICHAEL SEAN
Senior Vice President 6,000 Sale at $10.66 - $10.8 per share.
(Proceeds of about $64,000)
2003-07-14 WILSON, MICHAEL
Senior Vice President 6,000 Option Exercise at $0.66 per share.
(Cost of $3,960)
Spend $4,000 to gross $64,000. I'm in the wrong line of work!
Oracle does it, too. Most college-level database courses learn SQL - in particular Oracle's version of SQL.
Of course remember in statistics you perform an infinite number of those sorts of tests. The mean of your observations should be 1%.
Yeah, but that's for NT4 which is ancient. Anything with a more recent OS?
But even as a developer you don't gain anything over something like an INI file or another plain-text configuration file.
This is just another misuse of a poor technology.
Do you not see the huge absurdity of BINARY XML? It's an oxymoron!
XML is 'supposed' to be a nice little data interchange format. It's not a data storage mechanism (because relational DBMSs are far, far superior) yet misguided people like this are trying to use it as one.
Converting XML to binary? Why go to all the trouble to run it through an XML parser etc. first if you're just going to send a binary file? Use a more efficient file format!
"the spin of the electron can be transported without any loss of energy"... So the process is 100% efficient?
I'm pretty sure that's the point.
Because 'nulls' (or so-called three value logic) have no place in the relational model. Either you have a value or you don't.
3NF is certainly not fully normalized.
In a fully normalized schema you'd have what are essentially 'R-tables' (in Codd/Date speak) which represent one entity type.
So, you probably would have:
fname( PersonID, FirstName )
lname( PersonID, LastName )
etc.
Obviously storing a row with a PersonID with a null last name is redundant -- the lack of a row in lname is all you need (or actually don't need, as it were).
That, and there is virtually NO domain (aka type) checking at all.
I can happily insert numbers that are too large or too small (and it just rounds up/down, respectively), numbers that are actually strings, dates which are not dates, and any combination of the above.
But the 'business logic' (depends on your definition of business logic, really) is intrinsically tied to the data. Without it, your data is meaningless.
That's the (well a major) whole point of a relational database management system. Your RDBMS is a series of axioms -- namely constraints -- a la business rules.
The problem with traditional three-tiered architectures is that they are a throwback to 'roll-your-own' DBMSs that plagued the industry in the 50s, 60s, and 70s. At least many of the 'business rules engines' are declarative and not procedural, but it still needs to be under control of the RDBMS.
A fully normalized table consists of nothing but a key-value pair. A key with a null value is meaningless, hence the lack of a row.
There is a huge difference in storing nulls and deriving (the outer join) nulls.
Now, I will say that current SQL DBMSs ensure that the null is almost required to obtain optimal performance.
However, given a truely relational DBMS, nulls wouldn't even be in the picture.
I've generally found quite the opposite in trying to teach complicated joins to people. I can understand it both ways, but the newbies generally don't like the mashing of everything together in the where clause.
I like the ANSI method because it clearly defines where the join conditions are.
What is the benefit to this? I don't get it. Well, I do, but I don't see how it is that entirely too useful.
All it tells you is how many rows are in the particular table. The number of rows in the result is, of course, count( * ) + 1 since you have to account for the aggregate.
I assume you're doing something like (some weird pseudocode):
select * from table
put first row into rowcount
for( i = 1 to rowcount )
output 'row ' + i + ' of ' + rowcount
To the other guy who said it doubles query time that is not true if the count is using an index. Index scans are usually very fast.
The only reason why nulls are 'needed' is because the tables are not fully normalized. If you fully normalize your table the lack of a relationship is clear -- there is no row that matches parent = 123, fk = 456.
The RIAA's lawyers are not stupid. Something tells me the notices they send out do not say anything near to "We legally represent the copyright holder of the song YourFile.MP3" -- precisely due to the perjury clause. We've seen examples that are generally much more vague, but the vagueness is generally all it takes to get the Uni to take a look at it. Was the professor ever taken to court? Of course not.
Your argument doesn't pass the reasonable person test - no court in the US is ever going to think the RIAA is making that claim... because they aren't.
It didn't mention this in the article so I thought I'd post here and ask. I just recently purchased a US passport which doesn't expire for 10 years. Will I be required to purchase the 'upgrade' to the new passport or can I continue to use it until it expires in 2013?
:(
With all the outstanding passports I couldn't imagine the US Gov would re-issue new ones for free. Hopefully we'll all be 'grandfathered' in, although since it is their property they could revoke them in Oct. 2004.
The best shave is with an open razor.
It's a lot of fun, too. Not to mention a lot of time and effort -- but if you have the time the results over electric and the Mach 3 are nothing short of fantastic.
Is the concept of an album - e.g. a group of songs conveniently less than 74 minutes in total length - be obsolete?
Originally, and I'm just speculating, the album made sense. There had to be enough music there to satisfy the audience and convince them that paying $XX dollars for it was 'worth it'. With the advent of the internet (thanks Al!) we no longer think of downloading an 'album' but downloading 'the songs we like'.
Should the distribution model of a CD be eschewed for a direct release of individual songs? Radio stations very, very rarely play more than a handful of tracks from an album as it is. If you want to listen to it in your stereo use WAP or Bluetooth to listen to your home PC playlist. Your car stereo could read DRM discs and play all your tracks on a burned DVD.
A lot of people think DRM is the devil - but implemented correctly it could allow for an individual to do anything they want with the purchased media and would allow for the record companies to continue to make money. It would get rid of questions like 'Is this MP3 legal?' because the only way it would be is if you had the certificate for it. No fuss, no muss.
WHOA! Apologies -- I replied to the wrong thread. My reply was to the thread starter that, aside from being ridiculous, is obviously a troll.