"What are you going on about? Are you afraid of JOIN's or something?"
Not if there are a few joins. But if 1 single extra column can mean the difference between a 200 character SQL query and a 2000 character SQL query, then yes I'd definitely consider adding a bit of redundant data to make my queries simpler. Doing a select on a simple integer column should also be a lot faster than all those joins.
Tell me. What part of "phone_number has many digits" is a good thing? How exactly does that make the schema more self-documenting? What purpose does it have other than making the query more complex and harder to read?
I'll give you another example. In a system I'm working on, we have a 'documents' table with columns (id,title). One of the requirements is that our users must be able to see changes made to a document in the past. So we have a 'document_revisions' table, with the columns (id,document_id,content,created_on,author_id). (I'm using surrogate primary keys here, but let us forget that for the time being.) A document has many document_revisions. Suppose the users want to see a list of all latest revisions (that is, for each document I want the latest revision). Ideally I'd join documents and document_revisions, then group the results by the document's primary key, then *inside* a group order the group results by created_on DESC, then get the first item of each group. Unfortunately, to the best of my knowledge, ordering inside a group is not possible, and so it's not possible to do this in 1 query without utilizing a subquery. Subqueries are expensive. I've tried several minutes to come up with a query, but it's 11:24 PM right now, and I'm a bit tired, and failed. So I'll leave it up to you. But if I waste a little space by adding an 'is_newest_revision' boolean column, and have the application update that column every time a new revision is inserted, then the query can be much simpler:
SELECT * FROM documents doc, document_revisions rev
WHERE doc.id = rev.document_id AND rev.is_newest_revision Just one join, no grouping, no subqueries, no aggregate functions. It's a simple query and the DBMS can execute it very quickly. Here I've wasted a little space but look at what I've gained.
In case you're worried about data integrity: I do all updates in a transaction, so it's not possible for two revisions of the same document to have a true value on is_newest_revision.
"As a bonus, a properly normalized database is self documenting. Presented with nothing more than a database schema drawn on a white board, you should be able to deduce how a business works to a fairly detailed level without ever reading code."
Of course. And while we're at it, let's also get rid of the datetime/timestamp type and replace it with a table (my database systems professor actually did that in one of my exams). Or get rid of the string type and replace it with a one-to-many relation to a 'characters' table.
"Spare me the "SQL IS SCARY" argument. You know what I find even more scary? The application code that typically tries to replace the scary SQL statement."
Then whomever wrote that application is incompetent. Just because you have seen incompetent programmers writing stupid SQL doesn't mean there aren't good reasons to keep SQL queries simple. My point from the very beginning, is that one should carefully weight the pros and cons of application code complexity and normalization, instead of blindly pursuing theoretical idealism. What part of that don't you understand?
"Wow, a composite key isn't always the best solution? No sh*t, Sherlock!"
While you say that in a mocking way, many people are indeed arguing that composite primary keys are always the best solution, and thus that Rails is a toy until it supports them.
Of course. I'm not saying normalization is a bad thing. My point from the beginning was that one should normalize as far as it's useful. Going any further might just make your application code more complex for no additional gain, thus why I said that normalization may not necessarily be a good thing.
In one of the apps I wrote, a user has many email addresses and an email address has many users (I explicitly allow multiple users to have the same email address). In the most correct case, the email_addresses table must have a unique 'email' column. I tried implementing that, and soon I found out that it's more work than is worth. So I removed the unique constraint and just let the system insert duplicate data - after all I had plenty of disk space, and I have any queries which may depend on the uniqueness of email addresses. The system has been up and running for 2 years now and it's working perfectly. To this date I haven't regretted that decision. This is a typical example of why I think theoretical correctness is not always the right thing to do.
OK, my bad. You're right. I'm very tired at the moment and I didn't think it through before typing that reply. My point still stands though: the professor went into the extreme and normalized phone numbers into relations with digits. If I do that in my application, it would be a nightmare to maintain.
"Holy. Crap. You're not the guy that writes Active Record, are you?"
If you're referring to DHH, then no, I'm not him. My stance isn't as extreme as his ("database is just a big hash") but I do agree with some of his points. Transactions = good. Foreign key constraints = good. Stored procedures = only use when absolutely necessary. Normalization = weight between pros and cons in application code complexity and data redundancies. Etc.
"The thing a lot of OSS developers seem to forget is that many applications are primarily for data processing with user interfaces thrown on top. I.e. Not every damn "web app" is a blog or wiki, where it's primary purpose is to be a web app."
Not every, but *a lot* of them are. Very often they're systems for displaying, storing and retrieving small to moderate amount of information (unless you're working on a really really big multi-million system).
"Fact is that, if Rails wants greater acceptance (and, yes, I realize it is already widely accepted -- I'm talking about continued growth), then it's going to need to support things like composite keys. Why? Because people use them, and the application may have come years before the web interface."
I don't think so. I'm pretty sure that people complain about composite primary keys because it's so easy to complain about. Most of them probably wouldn't consider using Rails even if it fixes all its "flaws". * There was a time when I took all Internet complaints very seriously. I worked very, very, very hard to meet peoples' demand, and I did it for free. In the end, it didn't help. Whenever I publish a fix for one complaint, they complain about other things. It's an endless cycle. The complainers can never be satisfied no matter what I do. For example, people complain about memory usage in Rails. I've developed a way to reduce the memory usage by 30%, and look - very few people are interested! The people interested in my work are extremely disproportional to the number of people complaining.
* But by fixing Rails "flaws", you've just made it worse. The reason why Rails is so great in the first place is because it's a very specialized framework. It's not trying to be the thing for everything, like J2EE. If you make it the thing for everything it'll be a lot more painful to work with. It's like saying that your television can't wash your clothes. While it's possible to make a television that does that, it would be a royal pain to make and to work with.
"You're wrong, and you're guessing based on your own apparently very limited experience. Why not just admit that for "simple" CRUD applications ROR is great, for some it still works well, and that for other applications it may not be a good fit... or not work at all."
I don't know what you've been reading, but that was my point all along!
And there is nothing wrong with that. Most of the web apps that I make are CRUD-like. I'd still rather choose RoR for its productivity boost over your theoretically-better-and-can-be-used-for-everything-but-totally-pain-in-the-pass-to-work-with $FAVORITE_FRAMEWORK.
"Proper design is impossible with rails without reducing performance (the requirement to have a serial primary key and then a natural unique just to satisfy proper data requirements). Rails also increases database maintenance through mention of the above, and increases resource utilization (disk space and IO), reduces transactional velocity (having to update multiple indexes that shouldn't be required) etc..."
In theory you are true. But I'd like to see some evidence that proofs that lack of support for non-integer primary keys is *the* source of performance problems in Rails. Have you ever benchmarked a Rails app? How do you know that 90% of the spent time is to be blamed on the use of surrogate primary keys instead of the rest of the stack? Often performance problems aren't where you think they are.
"However, I have talked myself to death with Rails and Java programmers before. The majority (not all) are stuck in there own little code generated world and don't want to actually do things correctly."
That sounds a bit like an assembly programmer blaming C programmers that they stick to own little code generated world.
"Not to mention that Rails significantly reduces your ability to do really cool stuff such as stored procedures "
I've been wondering this for a while. Why are stored procedures "cool"? Just because you can? Can you give me use cases in which stored procedures have a significant advantage over application-generated SQL queries?
I've witnessed a game server (which uses MS SQL) using stored procedures that look like this: DEFINE STORED PROCEDURE GetMonster(name) (this is something I made up; I don't remember the correct syntax, but you get the point) BEGIN
SELECT * FROM Monsters WHERE monstername = @name; END
And then I think "Doh! Why does this exist in the first place? Why not just write that SQL query inside a GetMonster() function inside the application?"
Well said. Most people complaining about Rails scalability are simply complaining because it's the newest hype, but because they're actually concerned for legitimate reasons. "Fixing" the source of their complaints (whatever that might be) would be a huge waste of time.
I tried. I seriously considered ASP.NET. And I didn't use it.
First of all, ASP.NET is almost Windows-only. Mono support is not ready for prime time. This would mean I'd have to use Windows for development work, and it'd significantly lower my productivity. For a while, I installed Visual Studio and played around with ASP.NET. I borrowed an ASP.NET book. But I didn't like the experience at all. Everything is tied to the IDE. I have reasonable C# experience and I quite like the language, but ASP.NET doesn't appeal to me at all. It seems like Microsoft is working very very hard to abstract the web away.
Yeah, blame it on the programmers. Taking elitism (or perhaps "anti-programmer-ism" is a better word) to a whole new height.
Yes, my database theory knowledge is limited. I admit it. I passed the 'database systems' course, but I'm not a professor in database systems, so *of course* my database theory knowledge is limited. That's why DBAs exist and why they are paid to do their job in the first place. But you know what, the database isn't the only thing that exists. There's also the actual application. If, by normalizing stuff to the extreme, makes the application 6 times harder to write (= missed deadlines, potentially more bugs, harder to maintain, etc) then I don't mind de-normalizing some stuff after carefully weighting the pros and cons.
As for "ivory tower database theory", consider the following scenario (this is based on a question from the "database systems" exam): We have a 'teachers' table with columns (first_name, last_name, address, city, phone_numbers). Here, phone_numbers is a set. We are asked to normalize the table. One of the obvious things to do here would be to change the 'phone_numbers' column into a table, and add a one-to-many relation from the 'teachers' table to the 'phone_numbers' table. The professor, however, took normalization to the extreme: he even introduced a 'numbers' table. So a 'phone_number' table has a one-to-many relationship with the 'numbers' table. (Or something like that; I can't remember the question completely.) Great. Perfect normalization. But I would never write such a database schema. I don't even want to think about the huge, ugly, and hard to maintain SQL queries that result from this. And this is what I mean by ivory tower: great in theory, but makes things a total pain in practice for 99% of the applications.
While theoretically you are correct, it doesn't apply to 99% of the web applications. Most web applications are very CRUD-like and deal with small to moderate amount of data. Most software on this planet is written to be used internally by an organization. Not everybody is building the next MySpace or the next Google search engine.
So one one side, we have J2EE (and similar frameworks), which is "enterprisey", flexible-until-your-head-pops-off, can-be-used-for-anything, etc etc. The downside of all that flexibility is they make the regular CRUD operations a royal pain to write.
On the other side, we have Ruby on Rails. It doesn't do absolutely anything. It has a limited scope. But within that scope, it does its job very, very, very, very well, much more than the competition. Hey, doesn't this ring a bell? It begins with a "U"...
Not everybody's developing the next MySpace you know. For the past 4 months, I've been working with some fellow students on a web application, to be used by some student organizations at my university. Performance is not important *at all*, and we've done absolutely no work on tweaking performance. The project's deadline is in a month. So far, Ruby on Rails is godsent. If we chose PHP we'd still be at less than 50%, *and* the code would be a lot more messy. Right now, communicating with the student organizations' representatives and our professors takes more time than writing the code -- as it should be.
That's great for you, but Ruby on Rails is not - and isn't intended to be - a framework for redundant distributed DB applications. Ruby on Rails is not trying to be the thing for everybody. And that's exactly what makes it so powerful and easy. Indeed - turning it into something for everybody actually makes it worse. I'd like to see some proof that composite primary keys are so important in web applications. So far I've seen no convincing evidence. Despite all the complaints about composite primary keys, new Rails websites are written everything, even by high-profile organizations like IBM, NASA, Oracle and Yahoo. And they seem to function just fine.
If you really, really, really, really need composite primary keys, you can still fallback to raw SQL queries in Rails.
"Sure, but that's because Ruby is a real VHLL. You could also have achieved that effect by switching to Perl or, if you don't mind thinking in object-oriented terms about absolutely everything (and can put up with syntactically significant whitespace), Python. That doesn't answer the question about Rails."
Uhm no I don't. I've programmed in Perl far longer than I've programmed in Ruby. I only started with Ruby about 2 years ago. I have experience with mod_perl and stuff like Template Toolkit. I have experience with Python. And Ruby on Rails *still* beats everything else I've used.
It isn't just Ruby, it's also Rails. It's the entire package. Rails is not just any framework, it's an entire design philosophy. It's opinionated software. It's Don't-Repeat-Yourself. It's REST. It's convention-over-configuration. All this stuff together makes me much, much more productive. Ruby on Rails actually makes web application programming more fun than desktop application programming.
I don't even consider normalization taken to the extreme, to be a good thing. It's a trade off, just like everything else - what you gain by normalization, you might lose in the form of added application complexity, or perhaps even something else. Just because normalization is "good" according to ivory-tower database theory, doesn't mean that anything that isn't fully normalized is "bad" or "broken".
"Yes I know that a serial/autoincrementing key makes it easy for the app... it makes it a lot harder for the DBA in a lot of cases."
Can you explain what exactly it is that makes it a lot harder? (And isn't a DBA paid to do his job?)
My productivity has been boosted four fold (not a joke!) compared to when I was still developing in PHP. *And* my code is now shorter, more readable, more maintainable, and more secure. I'm not looking back to PHP anymore except for the most simplistic (= less than 500 lines) web applications.
Oh yes it does. In the past 2 years I don't remember having the need to add my own MIME type. And I just installed Ubuntu (with GNOME) 2 months ago. GNOME already provides a very extensive database of MIME types.
Why would I want to add my own MIME types? I shouldn't have to. If I don't have to then I won't need a MIME type editor GUI.
And this is exactly what GNOME's doing - there's a sensible default database of MIME types. I've never felt the need to edit the MIME types, nor should I have to feel the need. This applies to other areas of GNOME as well.
It's not hard to implement. It already exists, and is called nProtect. I first encountered it on the Ragnarok Online website, an MMORPG with Korean roots. nProtect is an ActiveX module which installs a kernel driver (!!). I'm not sure how it works, but it appears this kind of product is very popular in Korea, where they use it instead of SSL (!).
So I see that you're resorting to insults and flaming. What a great and mature way to respond.
You said "making GPLv3 code useless for virtually all forms of businesses that actually interact with end-users". "Businesses that actually interact with end-users" include, say, shareware authors. Suppose that shareware author uses calendar software to manage his schedule, and that the calendar software he uses is GPLv3'ed. Now I have given you *one* example where GPLv3 software is not useless to a business that interacts with end-users, thereby making your statement, that it's "useless for all forms of businesses that actually interact with end-users", invalid. The fact that the shareware author uses the GPLv3 calendaring software does not force him to release his software under the GPL.
In your other post you said "GPLv3 software is useless to anybody working in any form of business". My previous example makes that statement invalid as well. In fact I have given you multiple examples in which a company uses GPLv3 software, which means that the GPLv3 software in question is *useful* to that business.
That would probably be up to the court to decide. Point is, you have to do your homework no matter what license your dependencies have. I don't see the difference between modules that are GPL'ed and modules that are commercially licensed, you have to check whether they're legal no matter what.
You say "fragment opensource toolbox". This whole "fragmentation" issue is overrated. People have complained for years that open sourcing Java will somehow fragment it, and somehow Java is still doing as fine as it did before. Mono didn't seem to have fragmented.NET. The existence of the tons of open source HTTP libraries and browsers don't seem to have fragmented the HTTP protocol.
And there you have it, "sell". You're already making the assumption that you're selling that product that uses GPL'ed libraries. What about GPL'e development tools? If you use GCC then your binaries are not GPL'ed. If you use GNU Bison to write your parsers then your parsers aren't GPL'ed. Suppose you use a hypothetical FooForum forum software which is licensed under GPLv3 on your website - this has no consequence whatsoever on whatever commercial software you distribute on the website. If you use a GPLv3 calendaring software within your company, then that doesn't affect your software either.
You're saying "making GPLv3 code useless for virtually all forms of businesses that actually interact with end-users", but this is false, what you actually mean is "I can't copy & paste other peoples' code without adhering to their license terms, so GPLv3 must be useless for all possible situations". That's ridiculous. Visual Studio provides the source code of some parts of the C/C++ runtime library, for debugging purposes. One is not allows to blindly copy & paste code from those files into their own applications, and must adhere to some licensing terms. According to your reasoning, Visual Studio is completely useless for private businesses because of possible license violations when you blindly copy & paste code from the MS runtime library source code.
Read the license and know what you can do and cannot do. It's as simple as that.
Uhm, why? The only way to violate the GPL is to not adhere to the terms of the license. This is in no way different than from commercial licenses.
What is so "dangerous"? If you violated the GPL, it meant you didn't read the license. It's *your* responsibility to read and adhere to the license, and to face the consequences if you didn't do so.
But would this really be your problem, or a problem of the module in question? If the module depends on a GPL module but is licensed in a GPL-incompatible license, then that module would be the violator, not you.
And why is this problem limited only to GPL? It's also possible for commercial libraries to have license violations. In the end you have to do your homework no matter what.
Slashdot Mirror
"What are you going on about? Are you afraid of JOIN's or something?"
Not if there are a few joins. But if 1 single extra column can mean the difference between a 200 character SQL query and a 2000 character SQL query, then yes I'd definitely consider adding a bit of redundant data to make my queries simpler. Doing a select on a simple integer column should also be a lot faster than all those joins.
Tell me. What part of "phone_number has many digits" is a good thing? How exactly does that make the schema more self-documenting? What purpose does it have other than making the query more complex and harder to read?
I'll give you another example. In a system I'm working on, we have a 'documents' table with columns (id,title). One of the requirements is that our users must be able to see changes made to a document in the past. So we have a 'document_revisions' table, with the columns (id,document_id,content,created_on,author_id). (I'm using surrogate primary keys here, but let us forget that for the time being.)
A document has many document_revisions.
Suppose the users want to see a list of all latest revisions (that is, for each document I want the latest revision). Ideally I'd join documents and document_revisions, then group the results by the document's primary key, then *inside* a group order the group results by created_on DESC, then get the first item of each group. Unfortunately, to the best of my knowledge, ordering inside a group is not possible, and so it's not possible to do this in 1 query without utilizing a subquery. Subqueries are expensive. I've tried several minutes to come up with a query, but it's 11:24 PM right now, and I'm a bit tired, and failed. So I'll leave it up to you.
But if I waste a little space by adding an 'is_newest_revision' boolean column, and have the application update that column every time a new revision is inserted, then the query can be much simpler:
SELECT * FROM documents doc, document_revisions rev
WHERE doc.id = rev.document_id AND rev.is_newest_revision
Just one join, no grouping, no subqueries, no aggregate functions. It's a simple query and the DBMS can execute it very quickly. Here I've wasted a little space but look at what I've gained.
In case you're worried about data integrity: I do all updates in a transaction, so it's not possible for two revisions of the same document to have a true value on is_newest_revision.
"As a bonus, a properly normalized database is self documenting. Presented with nothing more than a database schema drawn on a white board, you should be able to deduce how a business works to a fairly detailed level without ever reading code."
Of course. And while we're at it, let's also get rid of the datetime/timestamp type and replace it with a table (my database systems professor actually did that in one of my exams). Or get rid of the string type and replace it with a one-to-many relation to a 'characters' table.
"Spare me the "SQL IS SCARY" argument. You know what I find even more scary? The application code that typically tries to replace the scary SQL statement."
Then whomever wrote that application is incompetent. Just because you have seen incompetent programmers writing stupid SQL doesn't mean there aren't good reasons to keep SQL queries simple. My point from the very beginning, is that one should carefully weight the pros and cons of application code complexity and normalization, instead of blindly pursuing theoretical idealism. What part of that don't you understand?
"Wow, a composite key isn't always the best solution? No sh*t, Sherlock!"
While you say that in a mocking way, many people are indeed arguing that composite primary keys are always the best solution, and thus that Rails is a toy until it supports them.
Of course. I'm not saying normalization is a bad thing. My point from the beginning was that one should normalize as far as it's useful. Going any further might just make your application code more complex for no additional gain, thus why I said that normalization may not necessarily be a good thing.
In one of the apps I wrote, a user has many email addresses and an email address has many users (I explicitly allow multiple users to have the same email address). In the most correct case, the email_addresses table must have a unique 'email' column. I tried implementing that, and soon I found out that it's more work than is worth. So I removed the unique constraint and just let the system insert duplicate data - after all I had plenty of disk space, and I have any queries which may depend on the uniqueness of email addresses. The system has been up and running for 2 years now and it's working perfectly. To this date I haven't regretted that decision. This is a typical example of why I think theoretical correctness is not always the right thing to do.
OK, my bad. You're right. I'm very tired at the moment and I didn't think it through before typing that reply. My point still stands though: the professor went into the extreme and normalized phone numbers into relations with digits. If I do that in my application, it would be a nightmare to maintain.
"Holy. Crap. You're not the guy that writes Active Record, are you?"
If you're referring to DHH, then no, I'm not him. My stance isn't as extreme as his ("database is just a big hash") but I do agree with some of his points. Transactions = good. Foreign key constraints = good. Stored procedures = only use when absolutely necessary. Normalization = weight between pros and cons in application code complexity and data redundancies. Etc.
"The thing a lot of OSS developers seem to forget is that many applications are primarily for data processing with user interfaces thrown on top. I.e. Not every damn "web app" is a blog or wiki, where it's primary purpose is to be a web app."
Not every, but *a lot* of them are. Very often they're systems for displaying, storing and retrieving small to moderate amount of information (unless you're working on a really really big multi-million system).
"Fact is that, if Rails wants greater acceptance (and, yes, I realize it is already widely accepted -- I'm talking about continued growth), then it's going to need to support things like composite keys. Why? Because people use them, and the application may have come years before the web interface."
I don't think so. I'm pretty sure that people complain about composite primary keys because it's so easy to complain about. Most of them probably wouldn't consider using Rails even if it fixes all its "flaws". *
There was a time when I took all Internet complaints very seriously. I worked very, very, very hard to meet peoples' demand, and I did it for free. In the end, it didn't help. Whenever I publish a fix for one complaint, they complain about other things. It's an endless cycle. The complainers can never be satisfied no matter what I do.
For example, people complain about memory usage in Rails. I've developed a way to reduce the memory usage by 30%, and look - very few people are interested! The people interested in my work are extremely disproportional to the number of people complaining.
* But by fixing Rails "flaws", you've just made it worse. The reason why Rails is so great in the first place is because it's a very specialized framework. It's not trying to be the thing for everything, like J2EE. If you make it the thing for everything it'll be a lot more painful to work with. It's like saying that your television can't wash your clothes. While it's possible to make a television that does that, it would be a royal pain to make and to work with.
"You're wrong, and you're guessing based on your own apparently very limited experience. Why not just admit that for "simple" CRUD applications ROR is great, for some it still works well, and that for other applications it may not be a good fit... or not work at all."
I don't know what you've been reading, but that was my point all along!
And there is nothing wrong with that. Most of the web apps that I make are CRUD-like. I'd still rather choose RoR for its productivity boost over your theoretically-better-and-can-be-used-for-everything-but-totally-pain-in-the-pass-to-work-with $FAVORITE_FRAMEWORK.
"Proper design is impossible with rails without reducing performance (the requirement to have a serial primary key and then a natural unique just to satisfy proper data requirements). Rails also increases database maintenance through mention of the above, and increases resource utilization (disk space and IO), reduces transactional velocity (having to update multiple indexes that shouldn't be required) etc..."
In theory you are true. But I'd like to see some evidence that proofs that lack of support for non-integer primary keys is *the* source of performance problems in Rails. Have you ever benchmarked a Rails app? How do you know that 90% of the spent time is to be blamed on the use of surrogate primary keys instead of the rest of the stack? Often performance problems aren't where you think they are.
"However, I have talked myself to death with Rails and Java programmers before. The majority (not all) are stuck in there own little code generated world and don't want to actually do things correctly."
That sounds a bit like an assembly programmer blaming C programmers that they stick to own little code generated world.
"Not to mention that Rails significantly reduces your ability to do really cool stuff such as stored procedures "
I've been wondering this for a while. Why are stored procedures "cool"? Just because you can? Can you give me use cases in which stored procedures have a significant advantage over application-generated SQL queries?
I've witnessed a game server (which uses MS SQL) using stored procedures that look like this:
DEFINE STORED PROCEDURE GetMonster(name) (this is something I made up; I don't remember the correct syntax, but you get the point)
BEGIN
SELECT * FROM Monsters WHERE monstername = @name;
END
And then I think "Doh! Why does this exist in the first place? Why not just write that SQL query inside a GetMonster() function inside the application?"
Well said. Most people complaining about Rails scalability are simply complaining because it's the newest hype, but because they're actually concerned for legitimate reasons. "Fixing" the source of their complaints (whatever that might be) would be a huge waste of time.
I tried. I seriously considered ASP.NET. And I didn't use it.
First of all, ASP.NET is almost Windows-only. Mono support is not ready for prime time. This would mean I'd have to use Windows for development work, and it'd significantly lower my productivity. For a while, I installed Visual Studio and played around with ASP.NET. I borrowed an ASP.NET book. But I didn't like the experience at all. Everything is tied to the IDE. I have reasonable C# experience and I quite like the language, but ASP.NET doesn't appeal to me at all. It seems like Microsoft is working very very hard to abstract the web away.
Yeah, blame it on the programmers. Taking elitism (or perhaps "anti-programmer-ism" is a better word) to a whole new height.
Yes, my database theory knowledge is limited. I admit it. I passed the 'database systems' course, but I'm not a professor in database systems, so *of course* my database theory knowledge is limited. That's why DBAs exist and why they are paid to do their job in the first place.
But you know what, the database isn't the only thing that exists. There's also the actual application. If, by normalizing stuff to the extreme, makes the application 6 times harder to write (= missed deadlines, potentially more bugs, harder to maintain, etc) then I don't mind de-normalizing some stuff after carefully weighting the pros and cons.
As for "ivory tower database theory", consider the following scenario (this is based on a question from the "database systems" exam):
We have a 'teachers' table with columns (first_name, last_name, address, city, phone_numbers). Here, phone_numbers is a set. We are asked to normalize the table. One of the obvious things to do here would be to change the 'phone_numbers' column into a table, and add a one-to-many relation from the 'teachers' table to the 'phone_numbers' table.
The professor, however, took normalization to the extreme: he even introduced a 'numbers' table. So a 'phone_number' table has a one-to-many relationship with the 'numbers' table. (Or something like that; I can't remember the question completely.)
Great. Perfect normalization. But I would never write such a database schema. I don't even want to think about the huge, ugly, and hard to maintain SQL queries that result from this. And this is what I mean by ivory tower: great in theory, but makes things a total pain in practice for 99% of the applications.
While theoretically you are correct, it doesn't apply to 99% of the web applications. Most web applications are very CRUD-like and deal with small to moderate amount of data. Most software on this planet is written to be used internally by an organization. Not everybody is building the next MySpace or the next Google search engine.
So one one side, we have J2EE (and similar frameworks), which is "enterprisey", flexible-until-your-head-pops-off, can-be-used-for-anything, etc etc. The downside of all that flexibility is they make the regular CRUD operations a royal pain to write.
On the other side, we have Ruby on Rails. It doesn't do absolutely anything. It has a limited scope. But within that scope, it does its job very, very, very, very well, much more than the competition. Hey, doesn't this ring a bell? It begins with a "U"...
I know what I'm choosing.
Not everybody's developing the next MySpace you know. For the past 4 months, I've been working with some fellow students on a web application, to be used by some student organizations at my university. Performance is not important *at all*, and we've done absolutely no work on tweaking performance. The project's deadline is in a month. So far, Ruby on Rails is godsent. If we chose PHP we'd still be at less than 50%, *and* the code would be a lot more messy. Right now, communicating with the student organizations' representatives and our professors takes more time than writing the code -- as it should be.
I would. And Rails supports exactly that.
That's great for you, but Ruby on Rails is not - and isn't intended to be - a framework for redundant distributed DB applications. Ruby on Rails is not trying to be the thing for everybody. And that's exactly what makes it so powerful and easy. Indeed - turning it into something for everybody actually makes it worse. I'd like to see some proof that composite primary keys are so important in web applications. So far I've seen no convincing evidence. Despite all the complaints about composite primary keys, new Rails websites are written everything, even by high-profile organizations like IBM, NASA, Oracle and Yahoo. And they seem to function just fine.
If you really, really, really, really need composite primary keys, you can still fallback to raw SQL queries in Rails.
"Sure, but that's because Ruby is a real VHLL. You could also have achieved that effect by switching to Perl or, if you don't mind thinking in object-oriented terms about absolutely everything (and can put up with syntactically significant whitespace), Python. That doesn't answer the question about Rails."
Uhm no I don't. I've programmed in Perl far longer than I've programmed in Ruby. I only started with Ruby about 2 years ago. I have experience with mod_perl and stuff like Template Toolkit. I have experience with Python. And Ruby on Rails *still* beats everything else I've used.
It isn't just Ruby, it's also Rails. It's the entire package. Rails is not just any framework, it's an entire design philosophy. It's opinionated software. It's Don't-Repeat-Yourself. It's REST. It's convention-over-configuration. All this stuff together makes me much, much more productive. Ruby on Rails actually makes web application programming more fun than desktop application programming.
People have discussed this over and over and over again. I presume you're talking about support for composite primary keys. They aren't necessarily a good thing. Go read http://rapidapplicationdevelopment.blogspot.com/2007/08/in-case-youre-new-to-series-ive.html
I don't even consider normalization taken to the extreme, to be a good thing. It's a trade off, just like everything else - what you gain by normalization, you might lose in the form of added application complexity, or perhaps even something else. Just because normalization is "good" according to ivory-tower database theory, doesn't mean that anything that isn't fully normalized is "bad" or "broken".
"Yes I know that a serial/autoincrementing key makes it easy for the app... it makes it a lot harder for the DBA in a lot of cases."
Can you explain what exactly it is that makes it a lot harder? (And isn't a DBA paid to do his job?)
My productivity has been boosted four fold (not a joke!) compared to when I was still developing in PHP. *And* my code is now shorter, more readable, more maintainable, and more secure. I'm not looking back to PHP anymore except for the most simplistic (= less than 500 lines) web applications.
Oh yes it does. In the past 2 years I don't remember having the need to add my own MIME type. And I just installed Ubuntu (with GNOME) 2 months ago. GNOME already provides a very extensive database of MIME types.
Why would I want to add my own MIME types? I shouldn't have to. If I don't have to then I won't need a MIME type editor GUI.
And this is exactly what GNOME's doing - there's a sensible default database of MIME types. I've never felt the need to edit the MIME types, nor should I have to feel the need. This applies to other areas of GNOME as well.
It's not hard to implement. It already exists, and is called nProtect. I first encountered it on the Ragnarok Online website, an MMORPG with Korean roots.
nProtect is an ActiveX module which installs a kernel driver (!!). I'm not sure how it works, but it appears this kind of product is very popular in Korea, where they use it instead of SSL (!).
So I see that you're resorting to insults and flaming. What a great and mature way to respond.
You said "making GPLv3 code useless for virtually all forms of businesses that actually interact with end-users". "Businesses that actually interact with end-users" include, say, shareware authors. Suppose that shareware author uses calendar software to manage his schedule, and that the calendar software he uses is GPLv3'ed. Now I have given you *one* example where GPLv3 software is not useless to a business that interacts with end-users, thereby making your statement, that it's "useless for all forms of businesses that actually interact with end-users", invalid. The fact that the shareware author uses the GPLv3 calendaring software does not force him to release his software under the GPL.
In your other post you said "GPLv3 software is useless to anybody working in any form of business". My previous example makes that statement invalid as well. In fact I have given you multiple examples in which a company uses GPLv3 software, which means that the GPLv3 software in question is *useful* to that business.
That would probably be up to the court to decide. Point is, you have to do your homework no matter what license your dependencies have. I don't see the difference between modules that are GPL'ed and modules that are commercially licensed, you have to check whether they're legal no matter what.
.NET. The existence of the tons of open source HTTP libraries and browsers don't seem to have fragmented the HTTP protocol.
You say "fragment opensource toolbox". This whole "fragmentation" issue is overrated. People have complained for years that open sourcing Java will somehow fragment it, and somehow Java is still doing as fine as it did before. Mono didn't seem to have fragmented
And there you have it, "sell". You're already making the assumption that you're selling that product that uses GPL'ed libraries.
What about GPL'e development tools? If you use GCC then your binaries are not GPL'ed. If you use GNU Bison to write your parsers then your parsers aren't GPL'ed. Suppose you use a hypothetical FooForum forum software which is licensed under GPLv3 on your website - this has no consequence whatsoever on whatever commercial software you distribute on the website. If you use a GPLv3 calendaring software within your company, then that doesn't affect your software either.
You're saying "making GPLv3 code useless for virtually all forms of businesses that actually interact with end-users", but this is false, what you actually mean is "I can't copy & paste other peoples' code without adhering to their license terms, so GPLv3 must be useless for all possible situations". That's ridiculous. Visual Studio provides the source code of some parts of the C/C++ runtime library, for debugging purposes. One is not allows to blindly copy & paste code from those files into their own applications, and must adhere to some licensing terms. According to your reasoning, Visual Studio is completely useless for private businesses because of possible license violations when you blindly copy & paste code from the MS runtime library source code.
Read the license and know what you can do and cannot do. It's as simple as that.
Uhm, why? The only way to violate the GPL is to not adhere to the terms of the license. This is in no way different than from commercial licenses.
What is so "dangerous"? If you violated the GPL, it meant you didn't read the license. It's *your* responsibility to read and adhere to the license, and to face the consequences if you didn't do so.
But would this really be your problem, or a problem of the module in question? If the module depends on a GPL module but is licensed in a GPL-incompatible license, then that module would be the violator, not you.
And why is this problem limited only to GPL? It's also possible for commercial libraries to have license violations. In the end you have to do your homework no matter what.