Ruby on Rails 2.0 is Done

Jamie noted that ruby on rails 2.0 is done. In addition to upgrade and installation instructions, the article lists a number of the more interesting new features in the release which appears to be quite extensive.

Comments

ORM still broken?

[poet]

I wonder if they still disallow proper database design by having a requirement of an autoincrementing number for the primary key.... The Rails developers could learn a thing about databases. Start here: http://en.wikipedia.org/wiki/Database_normalization . 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.

Re:ORM still broken?

[ILuvRamen]

they could learn a thing about programming! From what I've heard, if you use the objects in the "rails" that they premade, you're stuck doing it their with with their methods and properties and if you want to do it another way, you're out of luck. Making the huge mistake that everyone would only ever want to do something your way is how you kill a programming language.

Re:ORM still broken?

[K. S. Kyosuke]

Making the huge mistake that everyone would only ever want to do something your way is how you kill a programming language.

What a relief... As a lisper and rubyist, I'm glad to hear that Python is going to die! Good riddance!

Re:ORM still broken?

[FooBarWidget]

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?)

Re:ORM still broken?

[Anonymous Coward]

The Rails developers could learn a thing about databases.

HA HA HA HA HA

Fucking understatement of the year, bro.

Hmm, monolithic record-oriented design (all facts for a single entity in one table), using one-to-one links ("universal IDs"), and queries that fetch all attributes at once, and save all at once, minimal use of joins, implementing complex queries in procedural code? WELCOME TO COBOL! Har har har.

I swear, if I had a nickle for every time somebody on the Rails list said "don't do that, it's bad design" in response to someone trying to figure out how to implement a *proper* intuitive design.... I'd be able to fund my own Web 2.0 startup, or some shit...

The rest of Rails is pretty good though. And I'll admit, SQL databases don't exactly make it easy for anybody (how about letting DBAs create a VIEW with the "Rails design", on top of a properly designed database? That's what views are for! Codd is rolling in his grave).

Re:ORM still broken?

[heinousjay]

For the sake of discussion, what would you suggest, and what benefits would it bring to the process?

Re:ORM still broken?

[JoeCommodore]

If you are working with a redundant distributed DB (where the satellites don't always have connection so the data is mirrored) trying to integrate added data among the nodes is a nightmare with an auto incrementing numeric key.

Re:ORM still broken?

[FooBarWidget]

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.

Re:ORM still broken?

[K. S. Kyosuke]

(And, BTW, that was just an irony to point out the absurdity of the parent's statement. ;-))

Re:ORM still broken?

[Anonymous Coward]

Yup, 5th normal form is a tad much, but there is no reason to don't go 3rd.

It also SIMPLIFIES application, you just have to think accordingly.

Re:ORM still broken?

[Anonymous Coward]

Why would you not want a composite primary key for a many-to-many link table?

Re:ORM still broken?

[CastrTroy]

See there you go generalizing about web applications. Here's a hint. Web applications could be just about any application in the world. There's nothing in particular about a web application that makes it web, Except the web interface. And that may be only one interface to the application. There may very well be other interfaces that connect to the same data. So if there is a need for compound primary keys in any application (which there is) then there are uses for compound primary keys in web applications.

And saying that you can still fall back to raw SQL queries in rails is like saying you can still write assembly and fortran in C. Once you start doing that, you're not using C anymore. Just like once you start using raw SQL in ruby, you've kind of gone off the rails.

Re:ORM still broken?

[FooBarWidget]

I would. And Rails supports exactly that.

Re:ORM still broken?

[thammoud]

A DBA that uses composite primary keys does not deserve the title. You should never designate a primary key whose value can change. Use business keys for that.

Re:ORM still broken?

[Anonymous Coward]

Getting a *PROGRAMMER'S* opinion on data modeling is probably not a good idea. The view everything as objects or records, which is what they use in their programming. That's a subset of what the relational model allows.

Here's the simple, easy-to-comprehend reason why surrogate keys should not be used universally: Your logical model should exactly correspond to the client's conceptual model.

If the client says that "orders have order items, numbered 1,2,3,4..." then your model should have (ORDER#, LINE#) as the compound key for order items. If the client says "customers are identified by an arbitrary customer number", then it's okay to use an artificial ID. If the client says "customers are identified by SSNs" then that's your key.

Pretty simple concept, but completely lost on programmers who think the database is the "backing store" for their code (which will likely be replaced or rewritten in few year anyway, especially stuff like PHP, Ruby, etc). No, the database is the foundation of the business. It should be properly designed.

BUT, it's true, today's SQL databases are pathetic. They don't make this stuff easy. The don't let you create a data type that automatically renumbers the "LINE#" field if entries are deleted or removed. They don't let you create fully updateable views, making it trivial to create alternative key structures on top of your properly designed base tables. They make it hard to refactor and transition schema (views are like methods in OO code.. they let you encapsulate). They make joins expensive. So yes, there's a tradeoff and usually I give up and use surrogate keys most of the time (not ALL of the time though.. depends).

It's not WRONG to be faithful to the conceptual model 100%. It's a limitation of TODAY'S tools. But the programmers continue to spew their nonsense, the database vendors put out products optimized for programmers... it's a vicious circle.

Also, I don't know why you're bringing normalization into this discussion. I suspect your knowledge of "ivory-tower " database theory is limited, thus you incorrectly label all ad-hoc design rules as "normalization". (What exactly do you use to when working with databases, if you don't like theory?) Normalization has to do with key dependencies, not the structure of the keys, and is not required by the relational model because it is a *design* concept.

But since you bring it up, denormalization ALWAYS results in either a loss of data integrity, or a loss of performance. If you denormalize without maintaining integrity (the usual way), then you've fundamentally changed your model (what's allowed in the DB is different now). You better BE DAMN SURE you need it, and you better DOCUMENT IT out the ass. If you denormalize, but add constraints to maintain integrity, then you've killed performance for no reason (however this is useful when transition from denormalized designs back to normalized designs).

Re:ORM still broken?

[Anonymous Coward]

Then what is everyone complaining about?

If I have a table called Loans (PK = loan_id) and a table called TaxParcels (PK taxparcel_id) and I wanted a many-to-many link table I would naturally have a primary key on this table of (loan_id, taxparcel_id). Yes?

Re:ORM still broken?

[FooBarWidget]

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.

Re:ORM still broken?

[poet]

Actually no I am not talking about compound keys (although yes that is very, very important). I was talking about:

CREATE TABLE foo (company_name text PRIMARY KEY)

Which as I understand it, Rails is too stupid to understand. Granted, the only ORM that I know of that isn't is the one being used by Catalyst but still. It is a major design mistake to assume that your data can be correctly represented in a normalized structure using (id serial PRIMARY KEY).

I am also not talking about extreme normalization. I am talking about basic normalization... e.g; up to say the Third Normal Form.

The job of the DBA is to enforce proper database semantics, including design, performance, and maintenance.

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...

I can go on and on.

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.

Not to mention that Rails significantly reduces your ability to do really cool stuff such as stored procedures (yes you can break out and do it manually but then why are you using Rails?), Federated databases and on and on and on.

Re:ORM still broken?

[erwan]

Can you explain what exactly it is that makes it a lot harder? (And isn't a DBA paid to do his job?) Most real world business applications use partitionning in order to cope with very big tables. An auto-increment key is not a good candidate for splitting a table, as it will prevent spreading the data across the partitions for parallel processing, so you have to play with an application key (the auto-increment) and a partitionning key that the application has to set anyway when creating rows, which is far from optimal ... Anyway, good developpers understand the implication of what they do for the underlying database ... DBAs and DBMS won't fix your bad design decisions.

Re:ORM still broken?

[larry bagina]

postgresql views are updatable (you need to create a rule to remap the columns, though).

Re:ORM still broken?

[Bill, Shooter of Bul]

"If you denormalize, but add constraints to maintain integrity, then you've killed performance for no reason (however this is useful when transition from denormalized designs back to normalized designs)."

You can't say that will be the case 100% of the time. Most of the times denormalisation is chosen to improve the performance. In which case its faster to be denormailized, even with constraints. There are many different variables that come in to play when discussing database design that can't be accounted for with general rules. Yes, you should apply best practices and consult various rules of thumb, but nothing can replace testing the design with realistic data.

Re:ORM still broken?

[FooBarWidget]

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.

Re:ORM still broken?

[Anonymous Coward]

An auto increment key isn't unique across instances of an application. Thus if you set up two distinct instances of a given app within an organization, and then want to move data between them, you're in trouble since you have key collisions e.g. both the finance and the it department servers have a user number 69, only finance think's he's Bob Jones, and IT thinks he's Ted Williams.

A pseudo unique guid, on the other hand, is unique across any practical number of instances, meaning you can always move data between them without keyspace collisions. (yes, I know, there are some apps out there with sufficiently high transaction volumes that the chances of a collision of pseudo unique guids is non trivial, but lets face it, they're pretty damn rare).

Re:ORM still broken?

[dfdashh]

Why are surrogate keys a pain in the ass for DBAs? My guess is their difficulty in high-availability or disaster-recovery scenarios. When most application frameworks create autoincrementing surrogate keys, it is tough to get them synced over to a disaster recovery site and maintain consistency. Inserting explicit values into a sequenced table in Sybase, for example, requires table-owner intervention (usually the DBA) and not just access to insert into the table. Ever had to do asynchronous, multi-master'ed data correction with lots of these keys hanging around? Didn't think so.

Surrogate keys, by definition, also replace a table's naturally identifying characteristics. This means that you'll be creating additional indexes if some natural search columns are present. With those additional indexes come additional data storage to house them. There's also the chance that the surrogate key will be used by the query optimizer anyway, sometimes resulting in horribly inefficient joins.

Re:ORM still broken?

[smallpaul]

Pretty simple concept, but completely lost on programmers who think the database is the "backing store" for their code (which will likely be replaced or rewritten in few year anyway, especially stuff like PHP, Ruby, etc). No, the database is the foundation of the business. It should be properly designed.

You're generalizing from your specific situation. Often the goal is to sell the company in a few years to another company that will require you to integrate with their databases in any case. In that case both the code and the database are disposable (in the long run, both always are) but time to market is the immutable requirement. Every situation is different. It's even possible in some circumstances that performance is more important than integrity.

Re:ORM still broken?

[FooBarWidget]

"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?"

Re:ORM still broken?

[shmlco]

"While theoretically you are correct, it doesn't apply to 99% of the web applications."

Is that related to the fact that 99% of all quoted facts are BS made up on the spot?

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.

Re:ORM still broken?

[Enahs]

Not true. You can work with a number of different conventions...easier on the DBA, but harder on the person developing the Rails app.

I don't think this is entirely the best way, but here's ONE way I found by Googling: http://lindsaar.net/2007/11/28/connecting-active-record-to-a-legacy-database-with-stored-procedures

I know I've seen tips and tricks for PostgreSQL before, but I'm having trouble locating them at the moment. D'oh!

It's even covered in the Pragmatic Programmers' book on Rails. My copy is in a duffel bag in my car trunk, and it's raining hard outside. I'm too lazy to go look. ;-) I've never had to work with legacy databases, to tell the truth, and only use Rails for an in-house app, so I used their conventions. For what I was (and still am) doing, working against Rails was like pushing rope.

There's a lot of comments on this story that have patently untrue "Informative" statements...but then again, this is Slashdot, where authoritatively-delivered misinformation is rewarded. For example, it's not true that Rails forces conventions on you, but arrogantly stating that it's so garnered high ratings for another comment. People, the "authoritative" people you see here on Slashdot are the same people you roll your eyes at in, say, inter-deparmental meetings, and are usually the guy who qualifies stupid ideas with "and I used to hack in Forth on a PDP-11 before you were born, so I think I know what the #$%! I'm talking about!" So please...if you roll your eyes in real life, don't reward that behavior on /. Having said all that, I'll admit that Rails and/or DB design is a weak subject area for me, so I'll just shut up now ;-)

Re:ORM still broken?

[Anonymous Coward]

hah, I got it... apparently the modders didn't!

Re:ORM still broken?

[Anonymous Coward]

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?"

We use stored procedures for extra security and to make sure that programmers don't mess things up.

Re:ORM still broken?

[crayz]

If you do a search for "composite keys rails", hit #1 is this, a gem written by a fairly prominent ruby programmer that makes it trivially easy to use composite primary keys within ActiveRecord. My guess is if you actually cared about this issue, rather than just raising it as a canard to bash Rails with, you would have found this solution to your problem and wouldn't be posting here

Re:ORM still broken?

[crayz]

No, in Rails conventions you would have a join table, called 'loans_tax_parcels' with the loan_id/tax_parcel_id fields, and then your Loan model would say:
has_and_belongs_to_many :tax_parcels

and your TaxParcel model would say:
has_and_belongs_to_many :loans

And then you could do @loan.tax_parcels, or TaxParcel.find(:all, :include => :loans), etc.

Re:ORM still broken?

[crayz]

And I'll admit, SQL databases don't exactly make it easy for anybody (how about letting DBAs create a VIEW with the "Rails design", on top of a properly designed database? That's what views are for! Codd is rolling in his grave).

Go for it - I've done it more than once when I needed to get data out of legacy(and very poorly designed) databases. Rails supports this and it works just fine. The one point you make that I really agree with you on is ActiveRecord's inability to detect changed attributes and save only them to the database. You may want to take a look at DataMapper, a bit of a different take on a Ruby ORM

Re:ORM still broken?

[CastrTroy]

You're right, I'm not a Rails developer. I haven't looked up composite keys. What I was doing in my post was responding to the parent, who thought that composite keys weren't supported, and his short-sighted, narrow minded view that you should never need to use composite keys. It's great to hear that Rails supports this, because it actually lets me take Rails seriously. I wasn't raising the issue, I was responding to other users to seem to think that composite keys is an unneeded feature.

Re:ORM still broken?

[CrazedWalrus]

Holy. Crap. You're not the guy that writes Active Record, are you?

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.

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 use RoR at all, but these comments saying that composite primary keys are useless are simply insane. They're a fact of life, and if ActiveRecord doesn't support them, it's automatically precluded from use in existing applications that use them.

If AR does support them now, hey, great. In that case, I can't understand why this argument is even happening.

Re:ORM still broken?

[crayz]

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?"

Heh. In Rails that would be Monster.find_all_by_name('whatever'). Without creating any methods at all - ActiveRecord 'created' it for you. The guy below mentioning protecting data from programmers - if that's the philosophy you want to use, why not just quit now?

Re:ORM still broken?

[Anonymous Coward]

"BUT, it's true, today's SQL databases are pathetic. They don't make this stuff easy. The don't let you create a data type that automatically renumbers the "LINE#" field if entries are deleted or removed." Except that they do? Maybe that statement is true if you define "today's SQL databases" as MySQL.

Re:ORM still broken?

[Anonymous Coward]

"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 thought that is what he was arguing from the beginning?

Re:ORM still broken?

[smackjer]

I think database developers could learn a thing or two about Rails.

"all facts for a single entity in one table"
Just break the entity up into composite parts that map to separate tables/model classes, each of which "belongs to" to the master object. There are other ways to do it too, if you want to write some code.

"using one-to-one links ("universal IDs")"
I don't know what you're talking about. I don't think these are industry terms. If you're referring to "surrogate keys", there are perfectly valid reasons to do so, and perfectly valid reasons to use them instead of natural keys.

"queries that fetch all attributes at once, and save all at once"
You can easily fetch only the attributes that you need. Model.find(:all, :select => 'a,b,c') will only select columns a, b, and c. Yes, all of the attributes are saved at once, but how often do you only want to save some of the attributes? It doesn't cost much to update unchanged columns -- it's probably cheaper (total guess, but makes sense) to just update them all rather than figure out which ones have changed.

"minimal use of joins"
Sure, if you don't know how to use them. Rails makes eager fetching easy with the :include option in finders, which is implemented as a left outer join. You can write your own joins if necessary.

"implementing complex queries in procedural code"
This is not an issue if someone understands encapsulation. It's up to the developer to do it right -- Rails doesn't do it wrong.

Re:ORM still broken?

[coryking]

What are you going on about? Are you afraid of JOIN's or something?

Have you ever worked on a properly normalized database schema? I have, and it is a dream. When your database is designed correctly, you can mine it for pretty much any kind of information that you dream of.

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.

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.

Re:ORM still broken?

[Anonymous Coward]

> A DBA that uses composite primary keys does not deserve the title. The rest of your post I agree with, but a composite PK is fine as long as the keys don't change. A composite key on foo_id and bar_id is a good example. No need to have an extra ID key there if those two columns already uniquely identify the row. Fewer indices, too.

Re:ORM still broken?

[jadavis]

Yup, 5th normal form is a tad much, but there is no reason to don't go 3rd.

"A tad much"? Either you're being facetious, or you have a profound misunderstanding of normalization.

In many cases, a relation in 3NF is in 5NF. In fact, you have to be somewhat creative to think of a practical example of something in 3NF but not in 5NF.

"Normalization" is highly misunderstood. There is no such thing as "extreme normalization". If you see an example of something in 2NF, and then see a 3NF design side by side, you would probably think to yourself "yeah, the 3NF design looks better to me".

Re:ORM still broken?

[coryking]

That stored procedure is awesome (well, it actually isn't very good sql, but it doesn't matter right now). As the developer, you just need to worry about passing the monster name and the database spits out everything you want.

If you do most of the logic in your stored procedures, it makes it easy to bolt on new features written in various languages. If you decide to have a perl script for a cron job, you just call the same stored procedures your ruby app is calling. If you want a windows front end for your admin staff, the windows app calls the same stored procedure too.

Once you bury the database logic in the application code, you have to rewrite it for every application. It is, in a way, a very evil form of copy & paste programming. Now every change in the database requires you to go into every single application and change something. Kinda like when you get slutty with your code and copy & paste it rather than abstract it out into a library.

And I'm aware stored procedures don't play nice if you are worried about cross-database issues because you sell the software. This only works when you get complete control over the application & database stack.

PS: MySQL stored procedures suck. Use a real database with a better stored procedure language.

Re:ORM still broken?

[ILuvRamen]

well then guess what, you're wrong! Even in VB if you want to do something else with let's say the date/time class that it can't do, you have to re-write the entire class yourself. It IS stupid, it IS wrong, and IS bad programming language design. And with ruby on rails, you're so stuck into their mould of what you should be doing, it's ridiculous. I've heard horror stories about certain objects that are so super complicated but only do stuff one way so you have to work around them.

Re:ORM still broken?

[orasio]

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. Some software on this planet might be very CRUD-like. In my experience, all web aplications, specially those for internal use, are CRUD apps with a twist. I haven't seen any CRUD-like app that I could solve in a straightforward way. In general, that twist takes longer to implement than the CRUD part does. In fact, it takes longer to define accurately. Development time is important, but not even that important. The strength of using JEE, or any other big, flexible technology, is that you can define (or get people to define) stuff without thinking about the implementation, and it won't be that hard adapting the tools to what you designed. You can even map preexistent database tables (very common for internal apps) using ORM, although that can affect performance for big datasets.

Not everybody is working on small shops, on non mission critical apps. When you have big stuff, or big clients, you need to be very flexible, because you can't control everything. You can get the database shoved down your throat, communication protocols, unneeded specs, everything. That is what flexibility is for. A consultant can come and say that you need a high availability distributed architecture, you might have to change stuff for security reasons, for performance. Flexible frameworks let you do that.

Of course, it's nice that there is stuff like ROR for those who don't need to deal with medium to big projects, but I don't think they are 99% of anything.

Re:ORM still broken?

[arevos]

Meh, all SQL-based databases are broken to some extent, and ActiveRecord requiring primary keys on all tables is less an affront to Codd's design than the things built into any SQL database you care to name. SQL is as much a hack as ActiveRecord, and not as concise.

Re:ORM still broken?

[TheSkyIsPurple]

My database theory is weak as well, but doesn't normalization basically mean to ensure everything is represented in the database exactly once... no duplicate information and no extraneous information. Checking Wikipedia... http://en.wikipedia.org/wiki/Database_normalization... yep, that's pretty close.
(At least until you bring on a specific normal form)

We know nothing about the data space itself, or the constraints in which it will live, and no key info was specified, so we can't even intelligently determine what those would be... We have a naked table in space... no relationship to anything else, unless we start making assumptions. Why would database guy be making assumptions about organizational data and processes?

What if you have multiple people at one address with the same name and phone number? (A friend of mine had 5 sisters who had same first and last name, at the same address with the same phone number... In this case, the table design itself is deficient, and that requires you to fix the flaw before reiterating through normalization, wouldn't it?)

Given what we've been provided, since you're dealing with just one table in a vacuum, might it not already be normalized? (depending on what "set" means in this context, a constraint on the column would suffice, no?) Who's to say what dependencies exist between the columns?

Re:ORM still broken?

[leonbloy]

Start here: http://en.wikipedia.org/wiki/Database_normalization And after that, you can read this: http://en.wikipedia.org/wiki/Surrogate_key.
The debate about surrogate (or artificial) keys against intelligent (or natural) keys is an old one, and both have their points. But the truth is that modern practice tends to favour the former (specially if the natural keys are composite). Not only RoR, the majority of ORM around there (in particular, Hibernate, the most successful one) clearly favours surrogate keys.

Re:ORM still broken?

[Raideen]

The teachers table wouldn't have a one to many relationship with the phone numbers table. It would be a many to many relationship because a teacher can have more than one phone number and it's possible that one phone number is used by several teachers (by sharing an office or living together). A join on a many to many relationship would be extremely costly. The way to fix that is to introduce another table that links the two together. You overlooked the possibility of data duplication on both sides.

Re:ORM still broken?

[CarpetShark]

A DBA that uses composite primary keys does not deserve the title. You should never designate a primary key whose value can change.

You're assuming that all composite primary keys use values that do change. That's highly unlikely, given the number of tables in the world filled with historical data. That said, I agree (for other reasons) that surrogate keys are much better.

Re:ORM still broken?

[Yath]

Pretty funny comment :) But I guess the joke is on the mods in this case.

Re:ORM still broken?

[lymond01]

Yes, back in my first foray into web/middleware/database design, I used Apache/PHP/MS Access. With autoincrement. On a production server. The Access database got corrupted, had to be repaired, and then would no longer auto-increment. So my Primary Key was useless, I had to shut down the application, move data around and learned to increment manually through the code. It was in the middle of recruitment, so it was sort of worst case scenario.

So yes, I agree with not forcing auto-incrementing fields.

Re:ORM still broken?

[Anonymous Coward]

Yeah, blame it on the programmers.

It's the programmers who perpetuate sloppy thinking in data management. Ask 10 programmers what an "object" is, you'll get 10 different answers. Note: data management and programming are TWO DIFFERENT DISCIPLINES.

That's why DBAs exist and why they are paid to do their job in the first place.

Then why are you making pronouncements about data management?

But you know what, the database isn't the only thing that exists. There's also the actual application.

What do you mean *THE* application? The only systems I've worked on with ONE application are little toy apps or startups or tiny mom-and-pop companies. Have you ever worked with a system that is DECADES old? This stuff starts to get a lot more important.

So, you must also be inexperienced. So you don't know a lot of theory, and you don't have a lot of experience, again, why are you making pronouncements about data management?

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.

First of all, don't base your view of theory on your professors. When I talk about theory, I don't mean the ACADEMIC world. Database theory exists ONLY to implement real-world databases. It has no other purpose. It was developed strictly for that purpose. Again, if you don't like database theory, WHAT DO YOU USE to help you understand your real-world data management?

You say you would "NEVER" write such a schema? Really? You NEVER would? Why not? I've done things like that before, when I needed to add a column to an existing schema without breaking existing apps (because the DB in question was MySQL, which has non-existent/shitty view support).

From a theory point of view (sorry to offend you), splitting off columns is logically equivalent to combining them into one table. Just like "1+a+1" is the same as "a+2". If one design is clearer, and doesn't degrade performance, why wouldn't you use it? SQL queries aren't hard to maintain if think in relational algebra and mentally convert to/from SQL.

I'll repeat it again. Normalization is a description of a particular *design*. You don't need to normalize. Anyone who tells you that you MUST normalize, or makes fun of database theory by using the term "normalization" as a pejorative, is as clueless as someone who insists that all attributes of single entitle must be one table. Use what works, BUT UNDERSTAND the underlying fundamentals.

Re:ORM still broken?

[FooBarWidget]

"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.

Re:ORM still broken?

[jadavis]

If, by normalizing stuff to the extreme, makes the application 6 times harder to write

Well, it certainly is clear that your "data theory knowledge is limited". What does "normalizing to the extreme" mean? There are 5 (or 6, if dealing with temporal data) widely recognized normal forms, each with a very formal definition.

Most well-designed databases are already in 5NF. If a relation is in 3NF, it's probably also in 5NF, unless you are dealing with multi-valued or cyclic dependencies, something that occurs rarely in practice.

And if it's not in 3NF, and you saw the design side by side with a 3NF database, you would probably agree that the 3NF was a better design. And it would probably be in 5NF, too.

So normalization just formalizes the concept of good design, so that when designs get very complicated, you can still assure yourself that you have a reasonably good design based on your business rules (constraints). The formal model for normalization is not even really needed for simple designs, because 3NF is obviously the good design.

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.)

Huh? That makes no sense at all. Perhaps you should get a new professor, or read a good book. Any reasonable representation of the real world would see that "phone numbers" are their own domain (set of valid values). If it had particular meaning for your application, you might see a phone number as country_code + area_code + number, that is, 3 separate domains. For instance, maybe you want to know the country that the number applies to, and the general area the number applies to. But that's only if you actually want to maintain those mappings in order to extract the meaning from the input data.

There is a very fundamental difference between normalization, and turning the data you have into consistent information that has meaning to computers (and therefore from which automated inferences can be made). A trivial example to illustrate the difference is:

CREATE TABLE stuff (id INT PRIMARY KEY, t TEXT);

That table is perfectly normalized (it's in 5NF). But the data has not been imbued with much meaning. You can't infer new, useful facts that you didn't already know. Or, at least you can't make those inferences in an automated way using formal logic. You could always look back at the code that inserted the data (which version of the code was that again?), and look at the data yourself, and manually infer enough about the data to answer your question. I prefer the automated way, personally.

It's up to you to decide what has meaning in your application. If the meaning of a phone number to you is "something you dial", you might not care about the country code. If you want your application to automatically dial phone numbers for you to conduct a customer survey, and need to sample from many regions, perhaps you care very much about the area code and country code.

Once you have identified those things that have meaning, you can distill them into more formal definitions, and construct your database in a such a way that you can ask meaningful questions and get reliable results.

Oh, and if you're designing applications that generate data that will be important to your company for a long time, don't be proud of your ignorance of data management.

Re:ORM still broken?

[infonography]

(And, BTW, that was just an irony to point out the absurdity of the parent's statement. ;-)) (And, BTW, that was just an irony to point out the absurdity of the parent's statement. ;-))

Oh wait, that wasn't my mistake, that was yours. I wonder if they will find the gene that makes people repeat other people mistakes.

Re:ORM still broken?

[FooBarWidget]

"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.

Re:ORM still broken?

[jadavis]

I would word this more simply:

ActiveRecord uses the following equation: "save = commit". But "save" is fundamentally different from "commit". "Save" takes whatever the application state is, and copies it to permanent storage, so that the application state can be restored later.

"commit" means that you must reconcile whatever data you've collected with all of the data that you've previously collected , so that the data is consistent, and has a formal meaning, from which you can later ask meaningful questions, and get reliable answers.

Note that "save" is very context-sensitive. What version of the application are you restoring the state to? What assumptions surround the state information that may no longer be true?

Also note that applications can only see a small subset of the data, so cannot reconcile the current state with other (perhaps conflicting) information that has already been collected.

I largely agree with your complaints; I think they all come from this fundamentally wrong equation made by ActiveRecord (and ORMs in general).

However, you say that:
"I am also not talking about extreme normalization. I am talking about basic normalization... e.g; up to say the Third Normal Form."

Show us a design that's in 3NF, and then show a different design based on the same business rules in 5NF. It's hard to think of an example, because most 3NF designs are 5NF. So what is "extreme normalization" then? It makes no sense at all.

Re:ORM still broken?

[digitig]

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
Wow, a composite key isn't always the best solution? No sh*t, Sherlock!

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. Indeed it is a compromise, and it's not even always possible. But most people who dismiss it aren't actually aware of what it actually gives them, so I've seen some truly terrible tradeoffs. The main thing it gives you is data consistency. If you don't care whether your data is consistent then you can throw normalisation away quite happily. If you do care about data consistency, well, the alternatives to normalisation usually (not always) end up more complicated than normalisation would have been. As you say, lack of normalisation isn't proof that a database is broken, but it's very good reason to be suspicious -- it's far more than just an ivory tower ideal.

Re:ORM still broken?

[Anonymous Coward]

Sometimes you need to use composite primary keys because that's what is called for. (Hint: They wouldn't be written into all decent RDBMS's if they weren't something you sometimes DO need to use). Business keys can also be composite keys.

I hope you don't have the title of DBA if you don't realize that.

Re:ORM still broken?

[jadavis]

My stance isn't as extreme as his ("database is just a big hash")

That's not extreme, in fact, that's the first thing that occurs to most people. And the first DBMSs were something relatively close to that, or they were hierarchical.

But people had problems with that kind of database. It made very few guarantees about data consistency, so that meant that it was very hard to rely on the results of any question you might want to ask. The consistency was left up to the application, which only sees a small subset of the data at any one time, so it was rare that any real consistency was enforced.

Furthermore, there were no operations that mapped directly to logical operations, so nobody had the benefit of formal logic when trying to make complex inferences about the data.

So, they invented relational databases.

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).

It has nothing to do with the size of the data set. Even small datasets are usually much to large for humans to manually inspect the data.

It has much more to do with how important your data is, and what kinds of objective questions will you need to be able to answer from that data reliably and automatically?

I've developed a way to reduce the memory usage by 30%

Interesting, I'll take a look.

Re:ORM still broken?

[FooBarWidget]

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.

Re:ORM still broken?

[jjohnson]

It's not auto-incrementing that was your problem there. Any production-quality RDBMS handles auto-incrementing exactly as you would in code--better, probably.

Re:ORM still broken?

[FooBarWidget]

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.

Re:ORM still broken?

[FooBarWidget]

"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.

Re:ORM still broken?

[jjohnson]

You're a real jerk.

First, the linked article said that surrogate keys are always the better choice, not that natural/composite keys aren't always best. It presents some good arguments, too.

Second, the parent wasn't distinguishing between normalizing and not normalizing, he was pointing out that implementing 'extreme' normalization (like going all the way to sixth normal form) is usually counterproductive. I don't know about you, but I rarely go beyond third, and any references I've read about normalization agree that anything beyond that is rarely useful.

Way to keep up the ./ tradition of loudly disagreeing with something you didn't read properly, or at all.

Re:ORM still broken?

[digitig]

I am suggesting that composite keys may sometimes be the best solution (and so should be supported) and may sometimes not be the best solution. Referencing an article that gives an example of a case where they're not the best solution doesn't actually say anything at all to that debate.

Re:ORM still broken?

[FooBarWidget]

"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?

Re:ORM still broken?

[Anonymous Coward]

Making the huge mistake that everyone would only ever want to do something your way is how you kill a programming language.

"Ruby on Rails" isn't a programming language. Ruby is the programming language. "Ruby on Rails" is a web framework thing. They're completely separate and it's entirely possible to use Ruby without downloading and using Rails. It's like the difference between Java and JSP.

Sorry to be so pedantic. I think maybe I've had one too many recruiters ask me about Rails when they see Ruby mentioned on my resume.

Re:ORM still broken?

[digitig]

You're a real jerk. Why, thank you. It's good to see we can keep to the real issues.

First, the linked article said that surrogate keys are always the better choice, not that natural/composite keys aren't always best. It presents some good arguments, too. I couldn't find a single general argument in there; just an argument that surrogate keys were better in one specific case.

Second, the parent wasn't distinguishing between normalizing and not normalizing I know, which is why I kept pointing out that I was agreeing with the parent.

he was pointing out that implementing 'extreme' normalization (like going all the way to sixth normal form) is usually counterproductive. I don't know about you, but I rarely go beyond third, and any references I've read about normalization agree that anything beyond that is rarely useful. I'd never consider stopping short of BCNF unless there was a really strong reason to enforce consistency another way (I can't imagine a situation in which I wouldn't care about consistency). I'd consider higher forms, but they're certainly less automatic.

Way to keep up the ./ tradition of loudly disagreeing with something you didn't read properly, or at all. So I see -- because if you'd properly read what I wrote you'd see that I was agreeing with the parent, just qualifying it.

Re:ORM still broken?

[Bill, Shooter of Bul]

Just curious: why isn't performance even mentioned in this thread? It should be a tradeoff between (application code complexity, normalization, and performance). Choose the most important one and design accordingly, sacrificing the others only when necessary.

Re:ORM still broken?

[jjn1056]

Well, maybe 'phone_numbers' to 'numbers' might be a little far, unless you have a business need to restrict numbers in some way. I understand the idea though, that you shouldn't have so many values in your tables, just a lot of FK to very simple tables with just a PK and a value. I don't see this as fundamentally wrong, and sometimes in the end can help make you DB design more flexible. Also any decent ORM would make this easy. My ORM of choice DBIx::Class (current version: http://search.cpan.org/~ash/DBIx-Class-0.08008/) would probably look like

my $telephone = $teacher->phone_number->number;

I'd probably preload the numbers table in the phone_number join to simplify it even more.

If the ORM is designed well it makes it easier to do the right thing DB design-wise, in my opinion.

--john

Re:ORM still broken?

[FooBarWidget]

"As the developer, you just need to worry about passing the monster name and the database spits out everything you want."

So you want the developer to treat the database as a black box? Is that a good thing? It sounds like you're working with incompetent developers.

"If you do most of the logic in your stored procedures, it makes it easy to bolt on new features written in various languages. If you decide to have a perl script for a cron job, you just call the same stored procedures your ruby app is calling. If you want a windows front end for your admin staff, the windows app calls the same stored procedure too."

In this specific case, the game server is written in C++. There are no additional tools that access the database. So what's the point in using this stored procedure? Even if there are additional tools (should they be written in C++ as well), what's the advantage of this stored procedure over sharing the database model class?

"Once you bury the database logic in the application code, you have to rewrite it for every application."

Oh my, and all this time I thought object oriented programming and dynamic libraries solved this 20-30 years ago.

Re:ORM still broken?

[soloha]

Obviously those people were inexperienced with Ruby and or Rails. You can add new methods, or override the methods in any class you want. It's very easy to change they way any object behaves. And the concept of code blocks is extremely powerful and flexible (yes, yes, not an original idea - borrowed from Small Talk)...

Re:ORM still broken?

[rbanffy]

Well...

While normalization is a very good thing, an artificial identifier for every object (mind you, those lines represent objects in the program space - they are only persisted in the database and no operations should be done directly on the database itself) makes a lot of sense when you are doing OOP with persistence relational databases.

I would risk the jury is still out on this one. It may violate strict normalization rules but it also seems too useful to simply disregard the idea as Something Inherently Bad. The consequences are not clear and we need to explore this idea a little more.

Re:ORM still broken?

[epine]

I agree with another poster. It is not obvious for any software project that given an approach that is sometimes the right solution, that it benefits the indented audience to inflict support for that approach upon the feature set.

Typically when an application has narrow requirements that are so absolutely right you can't live without them, the application does not turn out to be suitable for RAD tools of any kind.

OTOH, if you can demonstrate that adding composite keys will *simplify* the design and implementation and use and documentation and performance and backward compatibility of Rails, then it should of course be added.

Re:ORM still broken?

[rbanffy]

I don't think you are stuck with their way of doing it. Rails is not a language - it's a framework. It's very common that, in order to gain the advantages a given framework offers, one also has to work with it, not against it.

If you want to do things in any other way, feel free to write your own framework.

If you really dislike the Rails way, I would suggest you pick another one - there are plenty. I don't know of any using Ruby, but, if you are into Python, you could use Zope 3 (I will give Zope 3 classes for the next week) or Grok and, if you need relational mapping, you could go with Storm instead of the ZODB.

Re:ORM still broken?

[shmlco]

"... your theoretically-better-and-can-be-used-for-everything-but-totally-pain-in-the-pass-to-work-with $FAVORITE_FRAMEWORK."

There you go, making assumptions again. I don't HAVE a favorite framework, or language, for that matter. I use what's appropriate for the task at hand, or, as more often the case, what the client mandates they want used for a specific job.

So you're setting up a "theoretically-better-and-can-be-used-for-everything-but-totally-pain-in-the-pass-to-work-with" straw man so you can try knocking him down with your RoR fanaticism.

Re:ORM still broken?

[dubl-u]

Getting a *PROGRAMMER'S* opinion on data modeling is probably not a good idea. [...] No, the database is the foundation of the business. It should be properly designed.

Over the years I have developed a simple rule.

In every profession, there are people who say, "No, MY specialty is the TRULY IMPORTANT ONE, and it MUST be in charge." I have heard this from programmers, DBAs, project managers, "architects", product managers, graphic designers, UI designers, business analysts, process consultants, engineering managers, and executives of every stripe. (I think the only people I haven't heard it from are the secretaries and administrative assistants. Probably because they know they are already in charge.)

My simple rule: anybody who says their specialty must be in charge has instantly disqualified themselves from being in charge.

That's not to say that those people, yourself included, are useless. They can be excellent, within the bounds of their specialty. It's just that they (and sorry, you) have too narrow a view of what's going on.

Re:ORM still broken?

[Ilan Volow]

When you as a DBA use anything other than a surrogate primary key, you are making the exceptionally dangerous assumption that the client has the correct understanding of what their model entails, that there will be no exceptions to the rules of that model, and that the model they gave you will never, ever change.

Borrowing from your SSN example, let's say that your client tells you the main way they identify customers is through the SSN, and you go by that, and then there's a case of identity theft and the customer's SSN number has to be changed? Now you've got potentially thousands of records with a bad primary key that you have to change (and mitigate constraint issues as well). What if privacy issues require the company dropping SSN's as an identifier, and now the company will be forbidden from asking customers their SSN's? You'll no longer be able to generate primary keys compatible with the same ones used before.

What truly separates a good DBA from a bad one is the good DBA's ability to anticipate change, design for change, insulate existing stuff from change, and basically save the client from any flaws in their own conceptual model (while making it look like they've followed the client's conceptual model to the letter). A bad DBA simply trusts whatever his client says and believes it to be correct and forever immutable.

Re:ORM still broken?

[FooBarWidget]

Not. The. Point.

Okay, I'll replace "$FAVORITE_FRAMEWORK" with "$WHATEVER_YOU_HAPPEN_TO_USE". Better now?

My point still stands: that RoR is limited, and that being limited is exactly what boosts productivity and what makes it good.

Re:ORM still broken?

[dwarfsoft]

In VB you have to "re-write the entire class yourself"? What happened to inheritance and overriding methods? Or are you talking about the NEW AND IMPROVED VB 6? Not that I'd use VB for anything other than what is specified by my Uni, but clearly you do not understand the language as stated in your post.

Re:ORM still broken?

[dubl-u]

If you do most of the logic in your stored procedures, it makes it easy to bolt on new features written in various languages. If you decide to have a perl script for a cron job, you just call the same stored procedures your ruby app is calling. [...] Once you bury the database logic in the application code, you have to rewrite it for every application. It is, in a way, a very evil form of copy & paste programming.

That's a good point, but I think you're learning the wrong lesson from it.

Yes, duplicating your database schemas across multiple code bases is bad, as it makes it approximately impossible to update things. But pushing all the brains into your database leaves you with four problems. One, you're generally locked into exactly one vendor. Two, the variety and quality of development tools is poorer. Three, if there's some other storage technology you want to use, you're generally screwed. And four, your various code bases are still tied to specific stored-procedure calls, which last I looked didn't have much in the way of protocol versioning.

I think the better option is to follow the OO approach, where you keep behavior and data together. You make yourself a tidy service layer in some convenient protocol like RESTful HTTP with XML or JSON. (Rails has nice support for that, BTW.) Give it a little versioning, so that you can transparently extend your APIs. That gives you the same kind of isolation your stored procedures do, but a much wider range of tools for both client- and server-side development.

In my view, that gives you the same clean boundary and exactly one code base mucking with raw data, but a lot more flexibility over the long haul.

Re:ORM still broken?

[smackjer]

If you need high-availability disaster-recovery, or simply distributed databases, you can use GUIDs for surrogate keys instead of auto-incrementing integers. You lose a bit on the integer-is-faster-than-varchar argument, but a single varchar column is still better than a natural key (which might be subject to change, requiring cascading updates for foreign keys) and especially better than a composite natural key (which effectively requires de-normalization for foreign keys.. which you might do anyway to avoid JOINs for performance reasons).

Re:ORM still broken?

[EraserMouseMan]

Normalization is always good for a transactional system.

If you need to flatten the db structure for data mining or reports then take that normalized data and move it to a separate database in a denormalized structure.

Starting out with a de-normalized structure limits the flexability of what you can do later.

Re:ORM still broken?

[digitig]

Yes, I'd agree that it's perfectly reasonable for a solution to be specialised. I'm a strong opponent of the "I have a hammer so every problem is a nail" type development mentality, and believe that any competent developer needs a wide range of tools. Rails might be just the thing for lots of jobs, but it's also going to be a poor solution for other jobs. The good developer will pick the tool that's right for the job -- not, as some seem to have been doing, argue that if their pet tool isn't right then it must be the job that's wrong.

Re:ORM still broken?

[mweather]

I just use autoincrement_increment and autoincrement_offset for my MySQL nodes. I'm not familiar with other distributed DBs, but I would assume they have something similar.

Re:ORM still broken?

[Anonymous Coward]

Because performance in a data driven app is generally easy to optimize late if you developed according to a simple design. If you start off looking to improve performance from the beginning, the likelihood is that you're micro-optimizing and missing the point entirely. On the other hand, if you've created an application with a clean, simple design, you can measure accurately where performance isn't up to snuff near the end of the development cycle and concentrate on those areas, not bothering to waste time on code paths that aren't exercised.

Come on, man, you can't have developed for more than 2 or 3 years without realizing this.

Re:ORM still broken?

[jadavis]

In one of the apps I wrote, a user has many email addresses and an email address has many users

CREATE TABLE user (username TEXT PRIMARY KEY, firstname TEXT, ...);
CREATE TABLE user_email (username TEXT REFERENCES user(username), email EMAIL, PRIMARY KEY (username, email));

(I assume there's a type "email" that is the domain of all valid email addresses, but that's a separate issue).

So what's wrong with that design? It seems to be in 5NF to me, according to your stated business rules. I don't know what two designs you're comparing, but the above 5NF design seems like the logical (and obvious) one to me.

You say that a "correct" design must have a unique email column? Why?

Normalization is a formal process you undertake after formalizing your business rules. Some of those business rules are called "functional dependencies" and those are the primary business rules you care about during the normalization process. You never normalize in the abstract, without knowing the business rules, it's impossible.

And let me repeat: normalization is NOT a continuum. A relation is always in one of: 1NF, 2NF, 3NF, BCNF, 4NF, 5NF, or 6NF. If it is in one of the latter normal forms, it is also in all of the earlier (i.e. a 3NF relation is also in 1NF). So which is it?

Chances are, if your data is in 3NF, it's also in 5NF. In fact, chances are that many simple databases are in 5NF, because for simple databases, the 5NF is the obvious solution.

The formal process of normalization is useful because when the database is complex, the good design might not be so obvious, and the list of business rules might be too long to just use intuition and rules of thumb.

Re:ORM still broken?

[drew]

Maybe the Rails developers took a database design course from the MySQL developers?

Re:ORM still broken?

[EricTheGreen]

Guess you couldn't be bothered to research how AR works...

1. Scalar key column, non-autoincremented approach:

class SelfManagedKey ActiveRecord::Base

    self.primary_key = "whatever_your_key_column_is" ...and you set the value yourself prior to saving the record. Whatever you want to stuff into the field, have a ball.

2. Composite Key

Take your pick of a number of plugins. My preference is CompositeKeys.

Is there some other key specification case you feel AR doesn't adequately support?

Re:ORM still broken?

[EricTheGreen]

Er, for the syntax lawyers out there, make that:

class SelfManagedKey < ActiveRecord::Base

Re:ORM still broken?

[Anonymous Coward]

You don't even know, and you've started with the negative whining?
Your poetry must be dark.

Re:ORM still broken?

[Bill, Shooter of Bul]

If you are talking about designing an app from scrap, I'd agree sort of. yes everyone knows early optimizations, without a proper understanding of the problem space is a disaster waiting to happen. If we are talking about designing a data driven application, you should have a good idea of the relative sizes of the tables. You do a little prototyping and usage senarios with an eye towards growth. Its easier to abstract the complexity of the data design early in the applications design, rather than later.

Re:ORM still broken?

[F1re]

Yep, everyone knows you should use Guids for primary keys.

Re:ORM still broken?

[Xendarq]

... isn't a DBA paid to do his job? ...

Police are paid to do their job, too - does that mean we shouldn't complain when people rob banks? Developers who write code which accesses a database share a responsibility with their DBA to implement well performing, scalable, and supportable data models and access strategies. Frameworks such as RoR which do not provide datamodelers the flexibility to design a model the way they'd like to are by their nature limited. Sure, it many cases it's possible to work around these limitations but that's no reason not to point them out. It is certainly one of the reasons it's not caught on more broadly in enterprise environments where database performance is often paramount to rapid development.

Re:ORM still broken?

[Nevyn]

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.

[...]

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, [...] 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.

What you seem not to know about are: 1) CREATE VIEW. 2) Materialized Views. 3) HAVING. 4) Stored procedures. Also the "sub-queries are expensive" is an interesting assertion, given that your answer seems to be to change an insert into an select + update + insert (or at least update + insert, but that has very bad behaviour). Maybe you are using a crappy RDBMS, or it doesn't have INDEXes in the correct places?

Re:ORM still broken?

[qb001]

Oh crap, I have to test my app. Oh crap, I have to think about my domain. Oh crap, I have to fulfill requirements from the dba first. Dude, autoincrmenting primary keys in a databases? Geez, I wonder why ever frickin' database on the planet supports it. I guess we are all morons.

Re:ORM still broken?

[Anonymous Coward]

This is precisely the problem with these systems. They all suffer from "not abstracted here". Web environments have soo much working for them CSS/JS/DOM/HTML data tiers and middleware with rich powerful query languages.

Use a system that that allows you to leverage the strenghts of the environment not replace them with their own naieve theories of how everything needs to be.

Re:ORM still broken?

[Anonymous Coward]

I wonder if they still disallow proper database design by having a requirement of an autoincrementing number for the primary key

When's the last time you looked at Rails? I started using RoR with 1.2, and I never thought you needed an autoincrementing number for the PK. We've always used UUIDs as the primary key here. The only difference is that you have to create the ID column yourself (one line!), and then "include UUIDPrimaryKey" (a mixin which contains just one statement: "self.id = UUID.new") in the model class.

With RoR 1.2, there were 2 bugs with this (one affecting testing, one affecting performance), so you have to add a grand total of 2 lines of Ruby code to your project to fix them. It would be nice if they fixed these in 2.0, but if a complete newbie to both Ruby and Rails can find it with a few minutes of googling, it's not *that* broken.

There are valid complaints about RoR. This is not one of them. Stop spreading FUD.

Re:ORM still broken?

[qb001]

Frameworks such as RoR which do not provide datamodelers the flexibility to design a model the way they'd like to are by their nature limited. Sure, it many cases it's possible to work around these limitations but that's no reason not to point them out. It is certainly one of the reasons it's not caught on more broadly in enterprise environments where database performance is often paramount to rapid development. You're not serious are you? RoR provides incremental changes, testing, rollback, data transformation, syncronization of code with data elements, automatic performance metrics, and reporting out of the box. RoR and other progessive , testable, verifiable frameworks already live inside banks, trading houses, insurance companies, large internet service providers, telecoms and (dare I say it) large database vendors. Rails is just one framework that supports this type of disciplined developement which includes databases as part of the stack.
It's a big bad world out there, but it's not that scarey.

Re:ORM still broken?

[Allador]

I'm a little confused by your comment.

What is it that you see in having unique, opaque, identity keys that prevents proper normalization of a database?

In my experience, its usually the amateurs who love to make the 'name' or 'code' of a record the unique key, or several combined columns of such. This then of course creates havoc down the road when you need to change one of these 'keys'.

I dont think they strictly have to be autoincrementing .... just so that they're numeric and unique (parts of RoR would be funky if you used GUIDs for your identity values, as an example). Of course, maybe I'm wrong about RoR having to be auto-incrementing ... but I sure havent seen that yet.

Re:ORM still broken?

[Allador]

Even in VB if you want to do something else with let's say the date/time class that it can't do, you have to re-write the entire class yourself. Why?

Just create a MyDateTime class, and delegate all the built-in methods of the native date-time to the native date-time, and then add your own custom extensions. Then use your MyDateTime.

That way you dont have to re-write the entire class, just some wrapper methods and your unique extensions.

Now mind you, I've never done that particular thing in VB, so maybe there's a technical gotcha there I cant see. Please yell if so.

Re:ORM still broken?

[Allador]

Ahh, I see. So your concern is that you cant use GUIDs or some other globally unique, replication friendly key?

Thats true, but its also a pretty niche issue.

Even read-only replication doesnt require GUIDs on most systems IIRC, so its only an issue where you're using a web front end on a multi-master replication configuration.

Thats pretty unique/rare ... and doesnt strike me as the best of all possible designs, at least for what I can think of why you'd do that.

Re:ORM still broken?

[Allador]

If the client says that "orders have order items, numbered 1,2,3,4..." then your model should have (ORDER#, LINE#) as the compound key for order items. If the client says "customers are identified by an arbitrary customer number", then it's okay to use an artificial ID. If the client says "customers are identified by SSNs" then that's your key. I hate to feed the cowards, but I just cant let this go.

You are completely incorrect.

If your domain model describes the way an actor finds an entry is by Order# and Line#, that should in no way, shape, or form decree what your technical artifacts look like.

The correct thing to do in that case is to have a unique, opaque, identity key (numeric or guid, just so long as its unrelated to the record data, and has no additional meaning beyond the unique value of that record).

Then you can also add unique constraints or indexes to the composite key, and/or you can enforce that unique constraint in the application. Or both, for the smart ones.

But you need to have a unique way to identify the record THAT IS NOT SUBJECT TO CHANGE. In your example, you could re-order the lines, or one line could have been a mistake and you need to move it to a different order.

If you've used composite keys on order# and line#, then you've got alot of cleanup work to do after your change.

If you've used proper opaque identity keys, then you just change the data, and there are no side effects.

Since in that case your joins are also done on the identity keys, your relatinoships are stable even when you change order# or line#.

The SSN one is even worse. I can guarantee you that if you do that, someone will have the wrong SSN, and it will need to be changed in your data.

If you've used SSN as the primary key, then its a pain in the ass, and you have to do data integrity cleanup.

If you've used a proper opaque identity key, then you just change the SSN, and there are no side effects.

This is stuff you learn the first time you write an app as a junior developer without a mentor, and use SSN as a key. A year or two later you come to regret it, and the lesson is learned for a lifetime.

Re:ORM still broken?

[Allador]

I don't use RoR at all, but these comments saying that co7mposite primary keys are useless are simply insane. They're a fact of life ... They're only a fact of life when you inherit a schema from a bad dba or designer.

There are very very few cases where composite keys AS the primary keys are a good idea. In fact, I cant think of any.

Now thats not to say that there wont be natural composite keys in your data. And if so they probably should have unique constraints on them.

But they should not, ever, be the primary key for a table. They are candidate keys.

But you want a one-column, fast-indexed (ie, numeric where possible) opaque identity key as your primary key.

I'd love to hear some compelling cases where natural composite keys as the primary key make sense, as I cant think of any, and in 10+ years have never seen one.

The only reason I've ever heard to favor composite keys is that it makes it 'easier' for the dba to read the data directly. Which is fairly pathetic.

Re:ORM still broken?

[Kristoph]

You most certainly can use a UUID in Rails as a key. I've done it many a time.

]{

Re:ORM still broken?

[Allador]

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. Subqueries are no more expensive than joins, and many query planners/optimizers will end up doing the exact same internal approach to both.

There is only one type of database where subqueries are expensive, and that is older versions of MySQL. And thats why, for many, many years, you didnt use MySQL if you needed a proper database, and not just a fancy ISAM indexed text file.

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. And thats fine until the second application starts modifying data in that DB. Then what if that developer didnt know about that rule? Since the db wasnt configured to guarantee data integrity the other developer has to somehow know that thats something the application must enforce to ensure integrity.

Thats not a good idea.

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. See above. Thats only a valid defense so long as your app is the only one modifying that data. If your app is successful, and survives more than a couple years, then in most enterprises you can almost be guaranteed that other apps will start working with it too.

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. I'd agree, with an additional qualification that you also have to consider maintenance and data integrity for the lifetime of the application, where other apps may modify the data, or your original app may be completely replaced by another (but the data lives forever).

In that domain is where the whole 'its okay, cause my app does the data integrity, so I dont need to do it at the db-leve' argument falls down.

The data is separate from the app.

The lifetime of the data will be 2-10 times the lifetime of the app. Think about this carefully. This means that the data and schema will keep on being used long after the app you've written is abandoned or replaced.

Given that, its almost never appropriate to do data integrity in the app. That will almost certainly guarantee lack of data integrity at some point down the line in the data.

Re:ORM still broken?

[Allador]

Excellent, thanks for the pointer.

My thinking in saying (in an earlier post) that it may cause problems is because it gets fairly ugly to replace this: /persons/15

with: /persons/{123H4-D838-AD23284849-2238}

but it would probably work, or could be made to work.

Re:ORM still broken?

[Allador]

Actually no I am not talking about compound keys (although yes that is very, very important). I was talking about:

CREATE TABLE foo (company_name text PRIMARY KEY)

Which as I understand it, Rails is too stupid to understand. For that last sentence, I think you mean to say: "Rails is too smart to encourage you to do."

Your deisgn is a terrible choice, which you will regret within a year of production usage (probably sooner).

Company names change. Company names get typo'd and need to be updated. Companies merge.

The correct choice is to do this:

create table foo (id long identity primary key, company_name text unique)

This way, your schema guarantees no two company's get in with the same name (assuming thats appropriate), and changes in company names dont break integrity with child or related tables.

You seem to be stuck on N indexes over N+1 indexes (differences between a natural key and a natural plus opaque identity key). If that is really a compelling issue for your database, then something else is probably wrong, because thats a minor issue underl normal circumstances.

If you're working so far out on the ragged edge of extreme, billions of inserts/udpates per table per day, then you're already having to deal with load. The tiny marginal load, storage, etc increases from these N+1 indexes per table is just not a big deal.

I dont know your specific situation, but in the vast majority of them, I'd say you have your priorities out of whack.

Re:ORM still broken?

[Allador]

There's also the chance that the surrogate key will be used by the query optimizer anyway, sometimes resulting in horribly inefficient joins. The surrogate key SHOULD be used for joins. It's the only column in common between the two joined tables.

Unless of course you've thrown data-integrity and normalization out the window by having redundant natural key data in the child/related tables too.

Re:ORM still broken?

[CodeMunch]

Once you bury the database logic in the application code, you have to rewrite it for every application. It is, in a way, a very evil form of copy & paste programming. Now every change in the database requires you to go into every single application and change something.

That is a VERY misleading statement. If you are building a system with an OOP language and you have designed your classes and relationships correctly you now have a reusable library that you can pick/pull from and use anywhere AND the logic goes with it. You don't need to worry about sending what ID numbers or values to which stored procedure, snagging any return values them and stuffing them back into some related object. You get a higher view of the system and can bend it to your will without having to be pestered with lower level DB stuff.

As you pointed out, Stored Procs aren't for everyone - especially entities building software for others (database agnostic) BUT for performing multi-statement mass data manipulation processes the quick/easy way, they are the way to go. Unless the application is smart enough to generate blocks of t/pl sql for database independence, SP's are here to stay but they are not the end-all be-all.

Re:ORM still broken?

[FooBarWidget]

"Subqueries are no more expensive than joins, and many query planners/optimizers will end up doing the exact same internal approach to both."

During the "database systems" lab sessions we had to write large queries with lots of subqueries, and some took a minute to run even though the data set is small (less than 200 rows in total). If you have subselect that depends on the parent:
    SELECT * FROM users u WHERE (SELECT * foo WHERE foo.bar = u.username);
then doesn't that force the database to walk through the entire users table?

"And thats fine until the second application starts modifying data in that DB."

The system has been in development for 2 months now. It's responsible for modifying all data in the DB and somehow it works just fine. Where did you get the idea that the app is not allowed or should not modify the DB directly?

"Then what if that developer didnt know about that rule? Since the db wasnt configured to guarantee data integrity the other developer has to somehow know that thats something the application must enforce to ensure integrity."

What if a developer doesn't know the programming language that the app is written in? What if the developer doesn't know how to breathe?
Simple: make sure that the developer does. Make sure that he does know the rule. That is what documentation and training is for, isn't it? The report and the UML class diagram specifically mentions this constraint.

Actually, the model class automatically enforces this rule. Upon saving the model class, it will automatically set the is_newest_revision of older revision objects to false. That is what abstraction and object oriented programming is for. It has only been around for, oh you know, 20-30 years?

Reading all this makes me think that people use stored procedures as a replacement for database model classes because their developers are too incompetent to write good SQL.

Re:ORM still broken?

[nettdata]

Maybe for small projects, but in my experience, if you follow that doctrine on any large projects and you'd be screwed.

FWIW, I've developed some incredibly large world-wide distributed databases for 3 of the top 5 online video game companies.

Re:ORM still broken?

[Allador]

If you have subselect that depends on the parent:
        SELECT * FROM users u WHERE (SELECT * foo WHERE foo.bar = u.username);
then doesn't that force the database to walk through the entire users table? This is functionally equivalent to:

select u.* from users u where u.username in (select bar from foo)

which is functionally equivalent to:

select u.* from users u inner join foo f on u.username = f.bar

Since they are functionally equivalent, any reasonable modern database system will perform them the same under the hood.

Given that, the only time it would walk through the entire users table (table-scan) is if there was no appropriate index on the table. Or if you were using an immature db system, like any version of MySQL prior to the current major ver.

When you were doing your multiple-minute query-with-subquery, what did the execution plan say was happening? Did it do a table-scan on users? Was this because there werent proper indexes?

Frankly, it sounds like you were using old versions of MySQL, which had an atrocious query planner/optimizer that couldnt deal with even mildly complex things like subqueries.

Where did you get the idea that the app is not allowed or should not modify the DB directly? I never said any such thing ... and I have no idea where you would get that.

What I was saying is that the app you're writing now wont be the only one to modify the db/data over the data's lifetime.

Actually, the model class automatically enforces this rule. Upon saving the model class, it will automatically set the is_newest_revision of older revision objects to false. That is what abstraction and object oriented programming is for. It has only been around for, oh you know, 20-30 years? I dont think you understood what I was saying. When I say the data will be modified by other apps, I mean by other apps. IE, not your app. Which means the model classes you have now are not the ones that will be used in the future.

In fact, the future data-modifying app will probably be written in a different language, whatever is fashionable then.

Which brings back to my point. The data and schema you design now will far outlast the application you design now. New apps will run alongside your app, and eventually your app will retire. But the data will live on, with new apps on top of it. Those are the poor bastards who will be inheriting your 'legacy' schema and complaining that the RoR-of-the-future doesnt support legacy schemas.

Reading all this makes me think that people use stored procedures as a replacement for database model classes because their developers are too incompetent to write good SQL. What do stored procedures have to do with anything? Did I at any point bring up stored procedures?

Re:ORM still broken?

[FooBarWidget]

What do views, HAVING and stored procedures have to do with this? To create a view I have to come up with a query in the first place. HAVING makes it possible to add conditions inside a group - but still, how exactly does this solve the problem without using a subquery?

The query would be derived as follows, by using mathematical set notation:

{ r:document_revisions | "r is the latest revision of the associated document" }
<=>
{ r:document_revisions | FOR ALL(r2:document_revisions | (r2.document_id = r.document_id) => (r2.created_on <= r.created_on)) }
<=>
{ r:document_revisions | FOR ALL(r2:document_revisions | NOT (r2.document_id = r.document_id) OR (r2.created_on <= r.created_on)) }
<=>
{ r:document_revisions | FOR ALL(r2:document_revisions | r2.document_id != r.document_id OR (r2.created_on <= r.created_on)) }
<=>
{ r:document_revisions | NOT EXISTS(r2:document_revisions | NOT(r2.document_id != r.document_id OR (r2.created_on <= r.created_on))) }
<=>
{ r:document_revisions | NOT EXISTS(r2:document_revisions | r2.document_id = r.document_id AND NOT (r2.created_on <= r.created_on)) }
<=>
{ r:document_revisions | NOT EXISTS(r2:document_revisions | r2.document_id = r.document_id AND r2.created_on > r.created_on) }
=>
SELECT * FROM document_revisions r
WHERE NOT EXISTS(r2:document_revisions | r2.document_id = r.document_id AND r2.created_on > r.created_on)
=>
SELECT * FROM document_revisions r
WHERE NOT EXISTS(SELECT * FROM document_revisions r2 WHERE r2.document_id = r.document_id AND r2.created_on > r.created_on)
=>
SELECT * FROM document_revisions r
LEFT JOIN documents d ON r.document_id = d.id
WHERE NOT EXISTS(SELECT * FROM document_revisions r2 WHERE r2.document_id = r.document_id AND r2.created_on > r.created_on)

And there you have it - a subquery that is dependent on the parent query. Expensive, forces the database to walk through the entire document_revisions able. How would you change this into something that doesn't need a subquery?
Compare this query to the one in which I introduced an is_newest_revision column. I spent 10-15 minutes on this one, the other one I could write with almost no effort and should be a lot faster to run too.

Re:ORM still broken?

[FooBarWidget]

"Since they are functionally equivalent, any reasonable modern database system will perform them the same under the hood."

Will it? The subqueries that I worked with are more complex than that, and PostgreSQL didn't seem to be able to transform it into something faster, even though some students were able to do it by hand. What is according to you "any reasonable modern database system"? Are they always able to find an optimal alternative within reasonable time?

I don't have the assignment anymore so unfortunately I can't show you the execution plan.

Re:ORM still broken?

[the_lesser_gatsby]

How is the join table different from the link table the AC described?

Re:ORM still broken?

[commanderfoxtrot]

Ordering within a group is certainly possible (ORDER BY gp, x); however, using LIMIT within a group is not.

Why do you think sub-queries are expensive???

Unless you are an incredibly good DBA (and I've met less than 10 in my life) on the specific DB you are using, then it's best to try it out and use EXPLAIN to see if it works or not.

I don't think it will be difficult to use a sub-query, nor performance intensive, so long as you have the correct indices.

I consider myself to have a good knowledge of DBs/SQL, but I use EXPLAIN all the time to try out new ideas and improve queries.

On the other subject of Rails and IDs- I use Rails myself, but I don't like the idea of publishing IDs. IDs should be fixed and internal - they should never be used for external use. Most people however don't really care and that's fine for them.

Re:ORM still broken?

[commanderfoxtrot]

Well said.

Record IDs should never change and they should be meaningless.

Re:ORM still broken?

[A Pressbutton]

Parent is correct.
Normalisation is (at helicopter level) a way of arranging information so that if you want to Create/Update/Delete one item of information in a database this can be done through one SQL statement.
This is a good thing.
All applications that use the DB can use one common simple interface.
This can make databases slow and complex in design.

The alternative is to have a simpler database and place some of the database design in the application. All applications that access that DB will now be more complex and will need to be amended if the database structure is amended.

My rule is

1 DB : 0 Applications accessing - who cares
1 DB : 1 Applicatons accessing - YMMV
1 DB : (n>1) Applications accessing - Normalise the database

Generally databases last longer and have less structural change than programs.

Re:ORM still broken?

[Anonymous Coward]

A rule of thumb about Rails gems: They do not support each other.
And as commercial bloatware db support (ie. Oracle) has been moved to gems, don't expect other gems to support that no longer - unless you're willing to make the port yourself :)

Re:ORM still broken?

[Anonymous Coward]

From my experience, 90% of the columns returned by stored procedures are never used. And most different applications need to join the data with something that the original procedure maker never thought of, so you need kazillion copy-paste variants of them procedures anyway to support just a couple different applications.

Well, unless you go the inefficient way of doing the join outside the db. Which you really shouldn't in general.

P.S. Oracle & DB2 stored procedures are the suckage I referred to above.
P.P.S. Don't even try to get me started on such flops as versioned binds...

Re:ORM still broken?

[Espectr0]

Can you explain what exactly it is that makes it a lot harder? (And isn't a DBA paid to do his job?)

I am not actually a DBA, but as a programmer i actually need to create tables and maintain our website's database over time. While i like auto increment id's for non-composite primary keys, i don't like them very much for those tables that need composite keys. Maybe i am just too lazy, since indexes get created automatically for primary keys, even when they are composite.

An example: i work at an insurance company. All insurance policies are grouped in branches, for example autos, medical, transportation... Each one of those have a number. So each policy on the database is formed by a composite key, namely branch-policy number, like 31-6100236. Each policy has a receipt number, that changes each year the policy is renewed, so a receipt's key is actually something like 31-6100236-596847.

Do you think using an autoincrement id which adds nothing of value to the table actually helps?

Maybe i am wrong, but that's the way we do it down here. I would appreciate the comments.

Re:ORM still broken?

[Anonymous Coward]

What do you mean disallow? It sounds like it may be possible for you to learn a bit about rails. The primary key can very simply be overridden.
Example from the rails documentation:

  class Project http://wiki.rubyonrails.org/rails/pages/HowToUseLegacySchemas

Re:ORM still broken?

[Anonymous Coward]

What do you mean disallow? It sounds like it may be possible for you to learn a bit about rails. The primary key can very simply be overridden.
Example from the rails documentation:

class Project < ActiveRecord::Base
    set_primary_key "sysid"
  end

Many of the rails assumptions can simply be overridden for existing databases.
See http://wiki.rubyonrails.org/rails/pages/HowToUseLegacySchemas

Re:ORM still broken?

[Sancho]

"And thats fine until the second application starts modifying data in that DB."

The system has been in development for 2 months now. It's responsible for modifying all data in the DB and somehow it works just fine. Where did you get the idea that the app is not allowed or should not modify the DB directly? That's not what was said.

Here's what the grandparent was talking about: you write a web application that does a lot of nifty, whiz-bang things. You realize that you want to perform some kind of maintenance on it every night, so you get your co-worker to write a script to do that while you continue to make the main application. Your co-worker doesn't realize that your application maintains data integrity, and could easily do something that screws it up.

Using the above example, perhaps your co-worker fails to update the "last revision" flag. Now your customers may get incorrect data when they ask for the most recent revision.

What if you weren't there? You've moved on, and someone else starts maintaining the application, and the new developer doesn't know about your efficiency trick. The documentation is lost, so you can't rely on that.

Simply put, the database is there to maintain data integrity. The application is not.

What if a developer doesn't know the programming language that the app is written in? What if the developer doesn't know how to breathe? Or more reasonably, what if the developer doesn't know the programming language that you developed in order to perform the task. It's not like a language that everyone knows--the schema and how the application interacts with it is going to be specific to every system.

But really, I think the issue is that you're just thinking too small. You've come up with this one simple example that undoubtably would be easy to document, and you have presented that as a good reason to not adhere to rules regarding data integrity. What if it was a more complex schema? A more complex application? If the database enforces all of the constraints, you never have to worry about the application forgetting to. For anything even moderately complex, this is essential.

Actually, the model class automatically enforces this rule. Upon saving the model class, it will automatically set the is_newest_revision of older revision objects to false. That is what abstraction and object oriented programming is for. It has only been around for, oh you know, 20-30 years? And if you need to interact with the data outside of Ruby? What then?

Re:ORM still broken?

[Anonymous Coward]

I was talking about: CREATE TABLE foo (company_name text PRIMARY KEY) Which as I understand it, Rails is too stupid to understand.

Would you mind citing a source for some of this stuff you're throwing around? This is pretty much what I have running in production right now, and I don't think anybody in my company had any idea it wasn't supposed to work!

I can go on and on. 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.

I've not seen a Rails project over about 2 weeks old that used any generated code. Scaffolds are useful for showing the 2-minute blog webcast, but nobody actually uses them in production.

Not to mention that Rails significantly reduces your ability to do really cool stuff such as stored procedures (yes you can break out and do it manually but then why are you using Rails?)

Stored procedures sound like a good way to become database-specific, and harder to test. But as you note, you *can* do that if you want. (How does it "reduce your ability"?) Why use Rails, then? Because Rails provides you a way to get started *right now* (start with nothing, have a web server running in 15 seconds), and can scale up to whatever you want -- including stored procedures, if you think they're useful. Most frameworks don't have that range.

Re:ORM still broken?

[Anonymous Coward]

Materialized Views

Just another way of having redundant data storage. Which, btw, ends up being a select+(update or insert), only done by trigger rather than by hand.

Needing the 'most [comparative operator] record' representative of a group of sets of records is common enough that postgres implemented a way faster than a subquery (eg,

where revision.id=(select max(q.id) from revision q where q.document_id=revision.id)"

): by using the "select distinct on (...)" form to return the first record of each group of records as defined by the distinct on parameters, so rather than executing one subquery for every single document, it executes one join query and discards the unwanted data:

select distinct on (doc.title, doc.id) doc.id, doc.title, rev.created_on, rev.author_id from document doc join revision rev on rev.document_id=doc.id order by doc.title, doc.id,rev.created_on desc;

"sub-queries are expensive" is an interesting assertion

select+update+insert being (relatively) expensive is an interesting assertion too. Perhaps the information you're missing is whether the database has more selects than inserts or the number of documents stored, each of which would execute a subquery to determine its most recent revision so even with a O(log N) index, your query is bounded by O(N*log(N*m)) with N documents and a maximum of m revisions each)

Nobody suggested that the obvious solution would have been most_recent_revision([idifyouhaveahardonforsuchthings,]document_id,revision_id) filled by a trigger on insert to the revisions table that does a delete+insert.

Also, from other threads re: converting a parent-dependent subquery into a join: this particular subquery is self-dependent in addition to being parent-dependent since it requires knowledge about the entirety of itself in order to look up a single piece of information. Who knows, maybe the query planner is smart enough to realize that it needs to materialize (select document_id,max(id) from revision group by document_id) as a table to join? (hey, that brings up another solution: a from-clause subquery to force materialization of that table:

...FROM document join (select document_id,max(id) as revid from revision) latest_rev on latest_rev.document_id=document.id join revision on revision.id=latest_rev.revid

)

I'm creating a test db on postgres 7.4 with 10000 documents and 9 revisions each, I'll get back to you with some real numbers on how each of these options perform.

Re:ORM still broken?

[Anonymous Coward]

CRUD

I know LAMP better so I have to ask if CRUD is up to the same tasks. Is it really equal? Oh and I'm familiar with CP/M, Roxio, and most dialcets of D, but what database is the "U" for?

Re:ORM still broken?

[Kristoph]

Well ...

First, you can use the compressed UUID form so ...

/users/123H4D838AD232848492238

... or you can use a more meaningful URL's in many cases like ...
/users/kristoph

... but if must have a short numerical id can create a 'reference' table which maps a numeric ids to a uuid (one table for all tables using uuid as a key). You can then simply check if you've been passed a valid uuid and, if not, run your query through a join to the reference table.

]{

Re:ORM still broken?

[Poltras]

People nowadays don't want to delegate. They want to inherit, enhance, add a couple of tucked legs and Voila! you've got Microsoft Office out of DateTime class... There really should be courses on How To Program, showing all concepts and their strength/weaknesses. Maybe someday I'll finally see an architecture that works more like Cocoa than MFC.

Disclaimer: I don't think Cocoa is perfect, but it's by far the best GUI (and OS interaction) framework I've worked with. I'm opened to learn a new one, but Gtk and MFC just don't blend.

Re:ORM still broken?

[Anonymous Coward]

OK, here we go, using postgres 7.4, 10k documents and 9 revisions each, with a vacuum analyze to prep the query planner:
doc (id serial primary key, name varchar)
rev (id serial primary key, doc integer references doc(id), date timestamp)
additional index on rev(doc)
(added after the 10K test set: index on doc(name) for sorting)

Note that the subquery and the materialization query assumes that you're using a monotonically incrementing id, if you got suckered into the UUID movement for whatever reason, hopefully you're at least using an incremental function to generate it, otherwise you'll want to index your date field and match against that instead.

select doc.id, doc.name,rev.date from doc join rev on rev.doc=doc.id where rev.id=(select max(id) from rev subrev where subrev.doc=doc.id)

is NOT materialized automatically, and is executed as a loop, requiring 4.2 seconds to execute [4.3 seconds with order by doc.name, doc.id].

select doc.id, doc.name, rev.date from doc join (select subrev.doc, max(subrev.id) as lastrev from rev subrev group by subrev.doc) last_revision on last_revision.doc=doc.id join rev on rev.id=last_revision.doc

will perform two hash joins and requires ~270ms [adding sort by doc.name, doc.id makes it ~780ms].

select distinct on (doc.name,doc.id) doc.id,doc.name,rev.date from doc join rev on doc.id=rev.doc order by doc.name asc, doc.id asc, rev.date desc

requires 1.7s, making it more efficient than a subquery, but less efficient than materializing the table.

To see how this scales, 20k documents, 20 revisions each:
subquery: 33s [33s w/sort] [33s w/sort+index on name]
materialized: 2.7s [2.9s w/sort] [2.9s w/sort+index]
distinct on (): 8.4s [8.3s w/index]

It's obvious that all of our choices are just not going to cut it.

Let's continue with the 20k document table, add rev.is_latest, and set it to 1 for the latest revision for each document:

select doc.id, doc.name, rev.date from doc join rev on rev.doc=doc.id and rev.is_latest=1

takes 460ms, 510ms with sort+index. With an index on rev(is_latest): 200ms, 300ms sorted

So now that there are numbers, which of the above do you want to use for your code? Is it THAT hard to create a trigger to update is_latest? I'd say that FooBarWidget did the right thing.

Re:ORM still broken?

[mabhatter654]

the problem is that not all databases have relative record numbers available. On IBM i5 for example, the file system itself keeps that to itself but it's there if you want it. The problem with composite keys comes when last name or company name is part of the key... have fun when a company changes names or an employee gets married.. and you've assumed you could use the entities given "name" as part of the key. Have fun with cascading updates then! Then you end up assigning numbers to things anyway... and when your customers buy each other so even customer numbers have to change?... sort of a damned if you do, damned if you don't thing.

Re:ORM still broken?

[Anonymous Coward]

For shits and giggles, I tried the other server I have available: PostgreSQL 8.1.9 on x86_64-pc-linux-gnu, compiled by GCC cc (GCC) 4.1.2 20061115 (prerelease) (Debian 4.1.1-21) (Other server was PostgreSQL 7.4.7 on i386-pc-linux-gnu, compiled by GCC i386-linux-gcc (GCC) 3.3.5 (Debian 1:3.3.5-13)) Note that these aren't similar hardware at all, and it's not relevant to compare the numbers between them beyond the obvious fact that 8.1's query planner still will not materialize the "id=(select max(id) from foo where foo.foreignid=foreign.id)" subquery on its own.

With all indexes, sorted results, and the 20k documents *20 revisions each code set, the numbers are
subquery: 34s
materialized: 3.2s
distinct: 6.9s
is_latest: 300 ms

If anyone cares to try this on oracle (I doubt it does distinct on(), that's nonstandard), I'd be interested to know if it can automatically convert the subquery into a table. Generating the dataset was pretty easy (convert pseudocode to language of choice):

for (x=1; x<=20000; x++) {
  insert into doc(id,name) values (x,x);
  for (y=1; y<=19; y++) {
    insert into rev(doc,date) values (x,'2007-01-01'::date+'y days');
  }
  insert into rev(doc,date,is_latest) values (x,'2007-10-10',1);
}

If it does, the results for the "materialzed" query and the "subquery" query should be nearly identical. Otherwise, the "subquery" query will be a lot longer as the database looks up the most recent revision for 20,000 documents, one document at a time.

Re:ORM still broken?

[mabhatter654]

because most apps people want rails for involve only dozens of users or maybe hundreds. My entire company with 6 locations only has 300 concurrent users tops. Speed of building an app and ease of UPDATING and app are more important than it being 100% perfect in use of resources or speed. Not that performance isn't important, but in most companies making the app do WHAT the people want, when they want is the more important feature... a second or two of performance time doesn't add up to the company budget as much as getting those new customer shipment requirements online in 2 weeks.. or you get the idea.

Re:ORM still broken?

[Qzukk]

Borrowing from your SSN example, let's say that your client tells you the main way they identify customers is through the SSN, and you go by that, and then there's a case of identity theft and the customer's SSN number has to be changed?

Changing SSNs is bad enough (actually, most databases would allow you to cascade such a change with the proper foreign key configuration), but what if the customer decides to do business with a Canadian or a Mexican?

Re:ORM still broken?

[TheSunborn]

That your database can't generate unique id values in that situation sounds like a problem with your database software, not with the concept of auto numeric keys.

Could you not just give each db a sequence from which to give out id numbers. So DB1 got from 0 to x and db2 got from x to y, and so on.

(I do asume that any software do not require the numeric keys to be increasing, just unique).

Re:ORM still broken?

[Lunzo]

Forget database structure, what parent gives 5 of their children the same first name?

Re:ORM still broken?

[Stamen]

All you're arguing is there should be a middle tier, to abstract out the business logic from the UI code. You won't get any arguments from any qualified developer.

However, I see no argument for why that middle tier should be stored procedures; everything you mention can be done in any number of technologies, including Ruby or Ruby on Rails.

Re:ORM still broken?

[doupatex]

Are you aware that you can redefine any method in any Ruby class (event the built-in), even at runtime ?

Obviously, you have to understand how the frameworks is organized, and Rails *is* a complicated piece of code. But because of the language used, it is much more flexible and adaptable than say, J2EE...

It seems that people really like to bash Ruby on Rails. Must be a reaction to the (over)hype. Still, it's very annoying that the average comment is completely ignorant of the language or the framework (I mean, more ignorant than the average slashdot troll)...

Re:ORM still broken?

[crayz]

Ahh sorry, I misread the GP. It isn't

Re:ORM still broken?

[mini me]

I've been working with Rails long before 1.0 and I don't recall it ever requiring auto-incrementing primary keys. It's just the default.

Re:ORM still broken?

[DragonWriter]

I wonder if they still disallow proper database design by having a requirement of an autoincrementing number for the primary key....

Rails does not now and never has had such a requirement, it does have a default of an autoincrementing integer primary key. It does require a primary key, and it does require that its simple (not composite), but it doesn't require that it be an integer, and it certainly doesn't require that it be autoincrementing (which seems to be the main problem for DBA's in certain use cases.)

And, for that matter, there is at least one open-source third-party extension to ActiveRecord that supports composite primary keys.

Re:ORM still broken?

[DragonWriter]

If you are working with a redundant distributed DB (where the satellites don't always have connection so the data is mirrored) trying to integrate added data among the nodes is a nightmare with an auto incrementing numeric key.

So? All that Rails requires (barring use of third-party extensions which allow composite keys, as well) is that the table have a primary key, and that it be a simple key. It doesn't require that it be an integer, and it doesn't require that it be autoincrementing (which seems likely to be the real source of problems in a distributed DB.)

Sure, the default in Rails "convention over configuration" approach is to use an autoincrementing integer primary key, but defaults aren't the same thing as requirements.

Re:ORM still broken?

[TheSkyIsPurple]

Something cultural apparently... they use their middle names for everything, and it didn't map over very well when they came to this country. Kinda like another guy i knew in high school whose first name was Nguyen, because that's how the original paperwork was done, and it's too hard to fix.

Re:ORM still broken?

[DragonWriter]

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.

While the specific example doesn't make much sense (what is in the "numbers" table?), isn't the whole point of features like views in an RDBMS to allow you to properly normalize your base tables but then allow queries to be written against a schema that is friendly to the way that the database is used? Applications SQL queries shouldn't be harder to write or maintain or more complex because they are written against a database where the base tables are fully normalized, because commonly needed views of the data should be implemented as, well, views.

(OTOH, the database itself will take more work to develop in the first place if it is properly normalized, which is the real cost issue: and since that's going to happen while your are building your app, especially the first app against a database, it is a serious issue that there is often an incentive to compromise on. OTOH, poor normalization is a source of lots of downstream problems in writing new applications, or extending existing ones, against a database.)

Re:ORM still broken?

[Slashdot Parent]

Have you ever worked on a properly normalized database schema? I have, and it is a dream. I have also, and it was dog slow.

And that's even after asking the DBAs for help writing the queries. About a dozen query optimizer hints didn't yield acceptable performance, they eventually were forced to denormalize the schema.

Thank god.

Re:ORM still broken?

[cbart387]

Borrowing from your SSN example, let's say that your client tells you the main way they identify customers is through the SSN, and you go by that, and then there's a case of identity theft and the customer's SSN number has to be changed?
Agreed. There's an error that's even simpler, a mistake by the user in entering something. When I've done db table design for projects, I have always used a primary key generated by the database. Anything that can change, external from the database, doesn't seem smart (to me) to use as a primary key.

Re:ORM still broken?

[DragonWriter]

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.

Have you heard of views? Simplifying queries is a really bad reason to cut normalization short. (Performance, OTOH, can be a good reason, even if, arguably, in the long-run "design it properly and throw adequate hardware at it to deal with performance issues" is often a better solution.)

What part of "phone_number has many digits" is a good thing?

Well, none, since a phone_number isn't an unordered collection of digits as that description would imply. OTOH, if you identified a phone number as having, say, both a country and an ordered collection of digits, that would both be accurate and facilitate substring searching, automated dialing applications that using the db that adapted to the country of use, etc. Of course, most practical DBs have a "string" type that can be properly constrained and that are a better choice than using another table to record certain types of an ordered sequences.

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.

No, ideally you'd create a view which did all that for all documents in the first place, and then query that by the primary key of the document you are interested in.

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.

IIRC, the databases that support factoring out subqueries with a WITH before the SELECT also do a better job at optimizing those that are factored out that way. I think both Oracle, DB2, and at least one or major database allow that (though Oracle won't let you make recursive queries that way).

In Oracle, you can also use KEEP DENSE RANK (FIRST | LAST) ORDER BY (...) to do this, I think (I've done queries that do essentially the same thing using it).

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

Why the application? Since its a fundamental feature of the data model, shouldn't this be done by a trigger in the database, not by the application? (I agree that there may be a good cause to do this for performance reasons, though not to simplify queries.)

Re:ORM still broken?

[DragonWriter]

What do views, HAVING and stored procedures have to do with this?

Views eliminate entirely the "complex applications queries" problem; the view is part of the interface of the database and the application is programmed against the views it needs, not the base tables except when the two are identical.

Stored procedures (specifically, triggers) eliminate having the application update the latest revision flag, etc. Its fundamental to the structure of the DB, and shouldn't be handled in application logic.

Re:ORM still broken?

[Anonymous Coward]

You make some of the most pathetic arguments I've ever seen.

Re:ORM still broken?

[mini me]

but what if the customer decides to do business with a Canadian

Ask for a SIN (social insurance number)?

Re:ORM still broken?

[Eivind Eklund]

You are assuming that the database is to be defined before the app, and that the way to access the database is through the ORM mapping. This assumption works against the way a lot of us work - for the way I personally work (and the ways most of the companies I've dealt with over the last 5 years works), each app mostly owns a database. If you want access to a "foreign" database, you use a web service.

The other kind of situation - the one you describe - has also happened, of course. However, in my experience, that's a much less common situation. Maybe a 10% situation. Of course, what's likely is that we work in different kinds of environments - I mostly work with fairly small or fairly young companies, or supplying new systems.

My point is just that there is a "good living" to be made for a web framework in that area. Enough so that Rails don't need to support the other kind of app to be useful and thrive. (Heck, even the web framework we use at work thrive, and that's maintained by just two people on a part time basis, and does much of the same as Rails. Plus compound keys. Knowing the entire codebase well is a grand plus :)

Eivind.

Re:ORM still broken?

[Eivind Eklund]

You are assuming that more than one app - using more than one language/framework - is going to touch the database.

Beep. You're not allowed to touch my database. My database is owned by the set of classes lying just above it. This is the ONLY allowed interface, because it allows me to keep my application code - like what you are writing in those stored procedures - in a more reasonable language.

So, there is no repetition. And for some of those apps I may even get the proper relational model, instead of SQL, because my personal little ORM implements it for me ;)

Eivind.

Re:ORM still broken?

[aevans]

What have you done? Bah! Back in my day knowitall DB weenies could link directly to Codd, even if they'd never read him.

Fresh Meat!

[TechyImmigrant]

Fresh Meat, full of bugs, for the hackers to hack.

If you desire a secure system, do not place a large, immature body of code in the line of fire on the internet.

Re:Fresh Meat!

[Anonymous Coward]

I haven't seen one post by a Slashdot subscriber yet that was anything other than pure bullshit. I suppose I shouldn't be surprised, anyone that would pay a dime to visit this shithole obviously doesn't have a clue. Allow me to try and give you some of the education you desperately require.

I suppose that security through obscurity is the better solution to you, mmm? Let the exploits stay out there in the wild while the company producing the OS takes months (if not a year) to produce a patch for a vulnerability they'll never likely explain to the public. It'll just be another "critical Windows Update" #Q1234567. How well has that been working out for Microsoft so far? Not so well, evidently.

How about all those subversion and cvs repositories out there for open source projects? Any mean, nasty hacker can look at the code, so why aren't we seeing myriads of Linux backdoors, remote exploits and the like? They exist alright, usually in the form of some proof of concept or script kiddies' tool. Thing is, everyone has access to the source code. Take Firefox for example; if a serious security problem is found then it's usually fixed and stable within a couple of DAYS, not months, and meanwhile there's a myriad of possible vulnerabilites that are being patched before they can even be used. How about on the Mac? There's been a few here and there, but Windows is keeping the antivirus industry alive, and you'd have to be a fool to try and deny it.

Is that enough for you to think about, or are you done trolling for the day? Maybe you should put the keyboard and your dick down and polish that subscriber * off a little, it's been tarnished by your idiocy.

Re:Fresh Meat!

[TechyImmigrant]

Actually I was arguing from the standpoint that security in online systems comes through reduced complexity in trusted code. Thus affording effective review and analysis. If you structure your online application such that you have to trust the whole codebase, you're screwed. Make sure you only have to trust a tiny bit of code, then polish that turd well.

The two properties I warned against were 'large' and 'immature'. I mentioned neither 'open' nor 'closed'.

Thankyou for educating me. I'll file it with all the other security advice I get on Slashdot.

Re:Fresh Meat!

[Anonymous Coward]

full of bugs

If you know of said bugs, please report them. If not, your post is lies and FUD.

Too bad I just switched to Python

[Anonymous Coward]

This new antigravity feature is astounding.

I don't understand the fuss.

[Russ Nelson]

I don't understand the fuss behind Ruby on Rails. Ruby is a programming language. Rails is a framework. Frameworks are a dime a dozen. Is RoR all that wonderful or are we being marketed-to?

Re:I don't understand the fuss.

[JudicatorX]

You are, or at least so far as hype == marketing.

Re:I don't understand the fuss.

[FooBarWidget]

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.

Re:I don't understand the fuss.

[jonadab]

> 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.

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.

Re:I don't understand the fuss.

[FooBarWidget]

"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.

Re:I don't understand the fuss.

[Anonymous Coward]

you forgot performance, the performance in your application is shit now.

Re:I don't understand the fuss.

[pestilence669]

"Web guys" will never understand the hype behind RoR. For the average PHP coder, RoR is slower and more restrictive... A hindrance. To a software engineer, however, RoR's great use of design patterns and best practices compliments what they should be doing already. Just as an example, if you're not writing unit tests, then you aren't very serious about your software to begin with. RoR's test facilities will bore you and nag you death. What Rails does is force you to consciously decide to not do something you should probably be doing, like testing. If MVC and encapsulation mean nothing to you, then RoR can't help you much. You still need you own discipline, or you can still write abominable code. RoR embodies many practices from how the big boys write software, few from the basement hackers.

Re:I don't understand the fuss.

[imbaczek]

comparing php to anything isn't worth the keyboard wear.

Re:I don't understand the fuss.

[CastrTroy]

Yeah, but PHP is one of the least productive environments there is, at least as far as web development goes. You could switch to .Net, and you would increase your productivity 10 fold. That is, if you stick to the .Net way of doing things. You're application might not scale that great, and you might not have any idea what's going on under the hood, and you might have a 20K viewstate submitted with every form, but you will be really productive in the sense that you can turn out a lot of features in a very small amount of time. Comparing raw PHP to rails isn't really something you should be comparing. Make your own custom framework in PHP, that fits the needs of whatever project you are working on, and you can probably turn out features extremely quickly. And your own framework will actually need what you need it to do, instead of you having to make compromises for the shortcomings of the framework.

Re:I don't understand the fuss.

[FooBarWidget]

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.

Re:I don't understand the fuss.

[CastrTroy]

But you could do the same thing in PHP. The fact that most people don't doesn't really say anything bad about PHP, but just bad about people who generally use it. A lot of people who write PHP leave SQL injection problems. That doesn't mean that it can't be used properly. A lot of people use screwdrivers to stir paint, that doesn't mean that the screwdriver is a terrible tool. You can do unit testing, MVC, and encapsulation all that other recommended stuff in PHP. Just because most people don't, doesn't mean it's a bad tool. If you need a tool to hold your hand and force you to adhere to best practices, then you aren't a very good developer.

Re:I don't understand the fuss.

[MarkRose]

It's good for rapid development, but bad if you want to run a high performance site. It's keen on the active record pattern, which is brutal on database servers in many situations.

Re:I don't understand the fuss.

[FooBarWidget]

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.

Re:I don't understand the fuss.

[Anonymous Coward]

ahhh, so you are a student working for the university maybe Rails is good for you, one question, you are a student in liberal arts?

Re:I don't understand the fuss.

[Tomy]

Sure, having a nice language like Ruby helps. I'm sure a Rails-like framework could be developed in any language that supported class metaprogramming, specifically some way to either add methods to a class at runtime, or fake it with something like "method_missing" (Smalltalk, Objective C, Ruby, etc) or __getattr__,__setattr__ (Python).

To me the important features of Rails are:

- Convention over configuration. Follow some simple naming conventions and your class to table mappings come practically free.

- Very good enforcement of MVC. Not that you're 'forced' to do MVC, it's just that the framework is designed to make MVC programing easy and natural. There is very clear separation of business logic from control and presentation, and it is easy to refactor when you do get it wrong.

- Easy to split parts of the app out into separate services when you need to scale to multiple machines.

- Rails' "migrations" is definitely the easiest way I've found to manage schema evolution.

- Ruby wrappers for a lot of AJAX-y stuff, you can stay in Ruby-land and still take advantage of js libs like Prototype and script.aculo.us.

- Emphasis on getting something up and functional quickly.

I built a Build/Release/Deploy application with complete integration with subversion in two days. It had functional parts in the first hour, including dynamic 'select', i.e. select the package you want to set up for nightly or continuous integration builds, and the drop down for branch selection would change to reflect the branches for that package without a page reload (without writing a single line of Javascript). Now this app is still pretty ugly looking, since it uses a lot of default scaffolding that Rails can generate, but it is easy to incrementally replace the scaffolding, and let the CSS Beauticians work in parallel.

This last point just seems mesh well with how I like to work. Get the pig up and running and we can slap lipstick on it later. In the early development phase, I want to concentrate on function and work flow.

Re:I don't understand the fuss.

[pestilence669]

PHP is a language, not a framework. Cake, Akelos, Symfony... Those are valid comparisons. Sure, you can use the raw facilities of the language to build a site, install libraries and tools (PhpUnit, PhpDoc, xdebug, prototype.js, ADOdb, etc.) If you are already building good software, Rails gives you a nice toolbox and prevents you from perpetually reinventing the wheel. Its the layer you should be writing for every project. PHP doesn't provide anything out of the box. In fact, it even discourages best practices. Global variables? Magic quotes? Goto statement (its coming... Really)? And no, there is never any reason to use goto or "register globals." just making them available reduces software quality globally.

Re:I don't understand the fuss.

[crayz]

Please just try Rails for a little while. While Rails has its flaws, overall it's a highly productive framework - and much of the credit for the terrific code clarity goes to Ruby, which is much more powerful and dynamic than almost any other mainstream language(other than maybe Javascript)

Some things to read about and try within Rails:
* ActiveRecord's ability to introspect the DB schema at runtime. e.g. autocreating the method to allow: User.find_by_name('Joe')
* ActiveRecord's magic-fields, e.g. created_at/updated_at
* the ActiveRecord associations, and the easy DB queries that come with them, e.g. @user.posts.find(:all, :conditions => {:status => 'pending'})
* the scope_out plugin, which provides some nice additions to 'with_scope'. e.g. in the Post model you could do scope_out :pending, :conditions => {:status => :pending}, and then be able to change the previous example to:
@user.posts.pending
* ActiveRecord callbacks and the controller before/after filters
* the RESTful routing and easy links that come with it, e.g. link_to(@user.name, @user) will create a hyperlink to the correct URL for that user record's 'show' page
* the form/field helpers which also integrate with the routing, so you can now do just form_for(@user) - it will create a proper form tag for hitting either the create or update method for that @user, depending on whether the record has already been saved to the database - the form_for/fields_for block syntax is also very powerful, especially when you add your own form helper methods
* all the convenience methods provided by active_support, like 5.minutes or 1.month.ago
* Ruby itself - Ruby is simply a joy to code in. even if I were going to dump Rails, I would now strongly prefer to find a new Ruby framework(like Merb) than using another language

I'd strongly urge you to pick one or more of the PHP MVC frameworks to look at while you read about Rails. Most of them are copies or at least inspired off Rails to some degree, so they often use similar conventions. You'll see the difference between what's possible in PHP and Ruby - PHP doesn't come out looking too good at the end

Re:I don't understand the fuss.

[Tablizer]

I don't understand the fuss behind Ruby on Rails. Ruby is a programming language. Rails is a framework. Frameworks are a dime a dozen. Is RoR all that wonderful or are we being marketed-to?

Gives me a youtube idea: Ron Paul on Rails.

Re:I don't understand the fuss.

[smackjer]

But you could do the same thing in C. The fact that most people don't doesn't really say anything bad about C, but just bad about people who generally use it. A lot of people who write C leave memory leaks and buffer overrun problems. That doesn't mean that it can't be used properly. A lot of people use screwdrivers to stir paint, that doesn't mean that the screwdriver is a terrible tool. You can do unit testing, MVC, and encapsulation all that other recommended stuff in C. Just because most people don't, doesn't mean it's a bad tool. If you need a tool to hold your hand and force you to adhere to best practices, then you aren't a very good developer.

Re:I don't understand the fuss.

[Peter La Casse]

and much of the credit for the terrific code clarity goes to Ruby

Parenthesis in function calls are optional! That's not what I would call "clarity".

My impression after using RoR for a few months is that "what seems logical" to Ruby's creator is not what seems logical to me.

Re:I don't understand the fuss.

[crayz]

Things like this sound silly until you understand the cases where they make code much cleaner and more readable. For instance, creating an association within ActiveRecord:

has_many :authors
belongs_to :publisher, :class_name => 'Company'

The second example, rewritten with more rigid syntax:
belongs_to(:publisher, {:class_name => 'Company'})

Or making a link within an ERB template:
<%= link_to @book.name, @book %>

Ruby's 'loose' syntax in certain places allow framework/API designers to give their users cleaner, more declarative code. Most places in Ruby you will use parentheses for method calls, but it's nice that when you don't need to - you don't need to

Re:I don't understand the fuss.

[digitig]

Sure, but that's because Ruby is a real VHLL. Hmm. And is there a full version for MS Windows yet? [checks] Nope. Because OS dependency is hard wired into the language. Which I suppose is one way a language can be high level.

Re:I don't understand the fuss.

[FooBarWidget]

Read what 'crayz' just replied to you.

Furthermore, unlike Perl, Ruby will warn you about ambiguous parenthesis. If you write:
  foo bar "hello", "world"
then you could mean foo(bar("hello", "world")) or foo(bar("hello"), "world"). Ruby will print a warning and tell you to use parenthesis.

Re:I don't understand the fuss.

[marcello_dl]

High level means that you can open the "hard wired" class after it has been defined, override the "hard wired" method and adapt it to your toy...er.. fave OS.

Re:I don't understand the fuss.

[SilentBob0727]

I truly enjoy writing Rails applications, and Ruby is my preferred *nix scripting language. I've even written a few desktop applications in Ruby.

That said, the kind of evangelism you get from some Ruby on Rails supporters really kind of bugs me. For one, all the "feel-good" language that doesn't really mean anything. You don't HAVE to write RESTful, DRY code in RoR if you don't want to. It's also not the only framework in the world. You *CAN* develop equivalent applications in ASP, J2EE, LAMP, or what have you (see Church-Turing Thesis), sometimes just as easily, sometimes more easily.

Honestly, it's the right tool for the right job. Sometimes it's a case of all you have is a hammer and everything looks like a nail. Then you get a power screwdriver and feel totally liberated over how much more productive you've become. Suddenly all those nails start looking suspiciously like screws and you think to yourself, hmm, I wonder.... and while you're busy either pounding in the nail with the back of the drill or etching a makeshift screw drive into its head and threading it with a soldering iron, your opponent is running circles around you hammering nails in with that hammer you are so quick to decry.

An experienced developer can write well-designed apps in any framework. An inexperienced developer can royally fuck over, yes, even a Rails app.

Re:I don't understand the fuss.

[arevos]

But you could do the same thing in PHP. To an extent. The problem is that PHP is a pretty shitty language. Ruby has it's flaws, but it's object model is well designed, and its syntax is extremely flexible. PHP frameworks that attempt to emulate Rails are invariably limited by their language.

Re:I don't understand the fuss.

[digitig]

So Ruby apparently isn't high level then, because it seems that it can't be fully adapted to the OS I have to work with if I want to keep my income coming in. Actually, I'd suggest that your definition of high level is too restrictive, because I do think Ruby is a high level language, but with some unfortunate design choices for anybody wanting to develop cross-platform apps. Fair enough: all languages have compromises, and that's one that Ruby has chosen.

Re:I don't understand the fuss.

[Billly Gates]

Unlike perl which prides itself that there is more than one way to do it. Parenthesis, no parenthesis, do whatever you want.

Re:I don't understand the fuss.

[CastrTroy]

You're right, you could use C. If only it somehow hooked into the webserver and had a library of functions that could be used to access different parts of the web request, and send HTML to the output stream. I imagine that it wouldn't be too difficult. Except that string manipulation is extremely cumbersome in C, so maybe that's why it's not too popular on the web, which seems to involve a lot of string processing.

Re:I don't understand the fuss.

[CastrTroy]

None of what you said refutes the fact that .Net is a very productive environment. Sure you are tied to the IDE, and IIS, and Windows, etc. However, that is what has made everything so productive. I'm not saying that .Net is the best web development environment, although it's what I use for work. By abstracting everything away, you can get a whole lot of work done in a very small amount of time. However, most of the developers I see using .Net, including us at work, stay very far away from their abstraction-drag-and-drop-viewstate-i'm-programming-but-don't-know-what's-going-on-under-the-hood methodologies because it always seems to be limiting you in some way, and is great for small little quick crud apps, but really hurts when you need to do any kind of enterprise development.

Re:I don't understand the fuss.

[koko775]

Check out Pylons. I tried RoR and loved Rails; hated Ruby (but that's just my opinion). Pylons has everything I liked about Rails. YMMV.

Re:I don't understand the fuss.

[smackjer]

My point wasn't that you should use C instead of PHP. It was that PHP isn't the be-all-end-all of web development. Ruby on Rails has a lot of selling points other than "look what I can build that can be built with anything else". However... You can "hook into the webserver" pretty easily with CGI programs written in C. That's how they did it (along with Perl) before PHP and every other web framework. http://en.wikipedia.org/wiki/Common_Gateway_Interface String manipulation isn't much more cumbersome in C than any other language. Just use a library if you can't figure it out for yourself. http://bstring.sourceforge.net/

Re:I don't understand the fuss.

[Chandon Seldon]

Yea, and everything you can do in PHP you could hand code in assembly. And everything you can do with a wood saw you can do with a screwdriver and a hammer. It'll just take longer and end up being crapper in the end because you didn't have the time to do everything right.

The whole point of a tool is to make it as fast and easy as possible to do the task well. For the task of writing web applications, Ruby + Rails accomplishes that better than PHP.

Re:I don't understand the fuss.

[Breakfast Pants]

"Global" is bad, but thread local is perfectly fine for things like error conditions recent regex matches, etc..

Re:I don't understand the fuss.

[Chandon Seldon]

Oh come on - you're complaining about which parens are required?!?

Have you ever used a programming language that didn't descend from ALGOL?

(if (you-want 'parens) (go write 'lisp) (try 'ml))

Re:I don't understand the fuss.

[Chandon Seldon]

Make your own custom framework in PHP, that fits the needs of whatever project you are working on, and you can probably turn out features extremely quickly. And your own framework will actually need what you need it to do, instead of you having to make compromises for the shortcomings of the framework.

That's what every well written non-trivial PHP program has ended up doing. And none of them made any of the same design decisions. So whenever someone asks me to make some simple change to a PHP program, the first step is figuring out how this new (usually undocumented) unique framework that the developers wrote works. I'm a programmer not an archaeologist, damn it.

Re:I don't understand the fuss.

[Peter La Casse]

Perl's even worse in that respect. They don't call it "write only" for nothing.

Re:I don't understand the fuss.

[Chandon Seldon]

You *CAN* develop equivalent applications in ASP, J2EE, LAMP, or what have you (see Church-Turing Thesis), sometimes just as easily, sometimes more easily.

The Church-Turing thesis says that these things are computationally equivalent, but makes no guarantee that real programmers will be able to produce results of the same quality in the same amount of time.

Choice of programming tools matters - see this classic article.

Re:I don't understand the fuss.

[Chandon Seldon]

The sort of optimization needed to fix that shouldn't be terribly difficult. It's definitely no harder than the issues with trying to make PHP sessions work in a cluster.

Re:I don't understand the fuss.

[Serious Callers Only]

String manipulation isn't much more cumbersome in C than any other language.

From the readme for the library that you just linked :

* Substantial mitigation of buffer overflow/overrun problems and other failures that result from erroneous usage of the common C string library functions
* Significantly simplified string manipulation
* High performance interoperability with other source/libraries which expect '\0' terminated char buffers
* Improved overall performance of common string operations
* Functional equivalency with other more modern languages

Why would this library even be necessary if string manipulation in C wasn't more cumbersome than other languages??!?!

To pick an example at random from that library

/* int bReverse (bstring b)
  *
  * Reverse the contents of b in place.
  */
int bReverse (bstring b) {
int i, n, m;
unsigned char t;

        if (b == NULL || b->slen mlen < b->slen) return -__LINE__;
        n = b->slen;
        if (2 > 1;
                n--;
                for (i=0; i data[n - i];
                        b->data[n - i] = b->data[i];
                        b->data[i] = t;
                }
        }
        return 0;
}


Is "Reverse me".reverse in ruby (I didn't have to look it up, just tried it and it worked as expected). There are many other examples, and that's not even getting on to regular expressions. I'm sure most can agree that PHP isn't the best language for web apps, but C would come way down my list. String manipulation is one of its weakest areas. Ruby's weak native support for UTF-8 counts against it here though.

Re:I don't understand the fuss.

[SavedLinuXgeeK]

Um, how can you compare a C implementation of a function to a Ruby invocation. For all you know the Ruby implementation could be almost identical. The actual comparison from above would be "Reverse me".reverse against (possibly, I know nothing of what a bstring is) bReverse("Reverse me"). I agree C's string manipulation can be atrocious but at least compare apples to apples.

Re:I don't understand the fuss.

[smackjer]

This is why we use libraries, frameworks, and higher-level languages, and why Ruby on Rails is better suited for many web apps than PHP, which was my original point.

Re:I don't understand the fuss.

[SilentBob0727]

I don't think I implied platform choice doesn't matter. In any case, programmer aptitude can go a great deal towards making up for a poor platform choice. My point is Rails is not a silver bullet despite the ravings of ardent Rubyists.

Re:I don't understand the fuss.

[Anonymous Coward]

But you could do the same thing in PHP. The fact that most people don't doesn't really say anything bad about PHP, but just bad about people who generally use it. A lot of people who write PHP leave SQL injection problems. That doesn't mean that it can't be used properly.

So PHP developers still need to write SQL? Rails developers don't: it's abstracted out. No wonder PHP has injection problems.

A lot of people use screwdrivers to stir paint, that doesn't mean that the screwdriver is a terrible tool.

Pete's House Painting doesn't actually have any paint stirrers, so you have to use a screwdriver here. I know when you worked at Robby's they had paint stirrers, and even those fancy electric paint can shakers, but we don't. But that doesn't mean we're *bad*! We just do things differently, and if you screw up (pardon the pun), it's your fault, not the fact that we don't have any of those nice tools you're used to.

Re:I don't understand the fuss.

[marcello_dl]

Your "income coming in" is an important factor to you, yet irrelevant for the definition of a high level language. For your definition of "high level" I suggest you go the gcc route.

Re:I don't understand the fuss.

[digitig]

Your "income coming in" is an important factor to you, yet irrelevant for the definition of a high level language. As is the question of whether it's my favourite OS, which you brought up.

For your definition of "high level" I suggest you go the gcc route. Or Python. Or OCAML. Or even C# if I could trust MS not to stomp on Mono.

Re:I don't understand the fuss.

[Serious Callers Only]

The parent said C is no more cumbersome for strings than other languages, so comparing a verbose implementation of reverse in C (which is not built in) to the built in function in another language is salient; it doesn't matter how Ruby does it internally, Ruby (for example) is a far better language to work on strings in than pure C, because the standard library already includes many useful string functions you don't have to import libraries or write them yourself. I was addressing the specific claim : String manipulation isn't much more cumbersome in C than any other language.

Re:I don't understand the fuss.

[Chandon Seldon]

In any case, programmer aptitude can go a great deal towards making up for a poor platform choice.

Poor programmers or poor tools (compared to the best options available) won't actually ensure failure, but that doesn't make crippling your project a good business decision. Trying to make up for poor tools with good programmers is no better than trying to make up for poor programmers with good tools - it's better than nothing, but it's still bad.

Re:I don't understand the fuss.

[doupatex]

What do you mean by full ? The Ruby one-click-installer has all the standard libs that you have on Linux/*BSD, plus the Windows-specific libs (it has some OLE stuff and an example about MS Excel remote-control, though I have to admit I don't know much about Windows Scripting).

And it's the second Google result for "windows ruby installer", the first will redirect you to the new page. You didn't try very hard, did you :-)

It's also trivial to install new packages using the (soon to be built-in) "gem" command.

There are some libraries that are *NIX specific (etc for example), but it's a very minor part of the standard distribution.

Re:I don't understand the fuss.

[marcello_dl]

As is the question of whether it's my favourite OS, which you brought up.

Yep, it's irrelevant what your fave OS is, it's significant you can reopen a ruby class to adapt it to whatever it is.

For your definition of "high level" I suggest you go the gcc route.

Or Python. Or OCAML. Or even C# if I could trust MS not to stomp on Mono.

You'd forfeit the PDP-10 OS(es) compatibility, that way.

Re:I don't understand the fuss.

[digitig]

You'd forfeit the PDP-10 OS(es) compatibility, that way. Dang, I was planning on using FOCAL as an IL, but I'm not sure that was ever implemented on the PDP-10.

Re:I don't understand the fuss.

[DragonWriter]

But you could do the same thing in C. The fact that most people don't doesn't really say anything bad about C, but just bad about people who generally use it. A lot of people who write C leave memory leaks and buffer overrun problems. That doesn't mean that it can't be used properly.

Of course C can be used properly. In fact, since Ruby code (other than JRuby or, if it were usable, IronRuby) is running on C, any doing it right in Ruby is dependent on doing it right in C.

C is lower-level than Ruby, though, so in lots of cases it will take a lot more source code, and a lot more time, to do it right in C from scratch compared to doing it right mostly in Ruby and then doing only the parts that really require C, for performance or other reasons, in C.

Re:I don't understand the fuss.

[smackjer]

"it will take a lot more source code, and a lot more time" That was my point, although in respect to Ruby vs PHP instead of C.

Compound Keys

[Anonymous Coward]

I like to use whatever functionality my database engine offer, including compound keys, in ruby on rails 2.0 my databases with compound keys are still "legacy"?

Re:Compound Keys

[poet]

I doubt it.. Rails has never been known for actually using the database for more than a flat file... One of the reasons it can't scale.

Re:Compound Keys

[Anonymous Coward]

I doubt it.. Rails has never been known for actually using the database for more than a flat file... One of the reasons it can't scale.

That sounds like FUD to me. Would you like explain exactly how Rails isn't able to scale and in comparison to what? Can you give an example where a Rails based project that has failed specifically because of poor scaling?

Off the top of my head Twitter and 37Signals apps seem to have scaled. Do you have something bigger in mind?

Re:Compound Keys

[Enahs]

Hey, aren't you the same "authoritative" person I responded to earlier? Second comment, and I'm hoping you're just trolling. Hell, you can even use raw SQL with Rails, so, well, either you're trolling, or you're an idiot. Which is it?

RRN?

[raftpeople]

Back when I was a young whippersnapper, we called that thing a relative record number!

Re:RRN?

[skoaldipper]

Why in my day we called that a hanging chad in a group of punchcards.

Sites Moved to Rails?

[markmcb]

OmniNerd.com, a site I do hobby development for, is running on Rails 2.0. We switched over from PHP this fall and site maintenance has been a dream since. Our site has even survived a few Slashdottings and Diggs since the switch, which used to murder it before. (Granted, the PHP code wasn't the best.) I've heard the "doesn't scale" debate a million times, but I'm curious if there is anyone out there who has recently moved a project from one language/framework to Ruby/Rails and whether you're glad you did or if it's been a nightmare. We're a medium-to-low traffic site with big surges every few weeks and it's worked well for us.

Re:Sites Moved to Rails?

[stuartrobinson]

There is some discussion of this issue here: http://www.radicalbehavior.com/5-question-interview-with-twitter-developer-alex-payne/ and also here: http://glu.ttono.us/articles/2007/06/21/powerset-to-launch-front-end-on-ruby

Re:Sites Moved to Rails?

[Bonus_Eruptus]

I built Too Many Secrets as an excuse to learn Rails, and haven't experienced any problems yet, thanks to caching. Unfortunately, since it's slightly personalized depending on whether or not you're logged in, I had to use fragment caching instead of page caching, so it still needs to hit Rails, but I've been able to keep the amount it needs to do to a minimum. I suppose if I actually sit down and think about it, I can figure out a solution and move to page caching.

How is Rails 2.0 speed-wise compared to 1.2?

Re:Sites Moved to Rails?

[robinw]

I wrote a web based game in RoR http://www.forumwarz.com/. It's running of a single dedicated server and it seems to be handling a lot of requests just fine. During peak periods, we've got multiple requests per second and I've never had any complaints about the performance.

Ruby gets a lot of flack for being slow. The truth it, it is slower than other languages. However, it's rarely a bottleneck for web applications. I'm fairly active in the local Rails community and I've yet to meet someone who had to backpeddle on rails for performance reasons.

In most web applications the database is your big bottleneck. Since Rails is process-based you can always buy another server or two and increase your performance that way. Let's face it, servers are cheap and developers are expensive. Rails allows you to get done stuff faster.

Re:Sites Moved to Rails?

[mali_iz_rs]

The site that I administer, has recently passed from slashcode(perl) to ruby on rails (custom web site code). After the switch, intel dual core 2.6ghz with 2gb of ram is dying. So, because developers like the 'programming on the fly' method, the owners of the site will pay more money for the server administration, and for few more servers so the site can handle the peaks. As far as I see it .. it's a programming language (with framework) which is created not to scale better, but because everyone wants to finish things faster, which is not neccesarily better. IMHO.

Re:Sites Moved to Rails?

[Tablizer]

OmniNerd.com, a site I do hobby development for, is running on Rails 2.0. We switched over from PHP this fall and site maintenance has been a dream since.

It's just a blog. I don't see it testing the complexity of say business forms with complex validation.

Granted, the PHP code wasn't the best.

If you compare bad PHP to good RR, of course RR will win. Plus, you have the learning experience of the first (bad) try to make the next deal with the issues you didn't know about the first round.

Re:Sites Moved to Rails?

[Anonymous Coward]

Do you know how awesome it would be if that site was Slashdotted? :)

Re:Sites Moved to Rails?

[soliptic]

So if you're second, who's first?

Re:Sites Moved to Rails?

[Anonymous Coward]

Next time consider including some info on the search query that caused issues.

Otherwise, someone might assume that you're just an idiot troll who generated the failured message by throwing garbage into the URL's query string.

Nice job undermining your own argument!

Re:Sites Moved to Rails?

[Anonymous Coward]

It's great to see this sort of report with a well-known major site.

I've done work converting a fairly high-traffic site to rails, but the rails-ness was never advertised because it was irrelevant to the client, and the work was done under NDA so we couldn't write up an article touting the success. After all, they didn't want to tell their competitors how it was that they cut costs, whether that's a justified fear or not.

There are a lot of things I don't like about Rails, but scalability isn't one of them.

Re:Sites Moved to Rails?

[Anonymous Coward]

They have no freaking idea what they are talking about. I run sites for a network of radio stations that is all rails, and we have the fastest, most stable sites of any competing media in our markets at least. Looking around, I'm always comparing our sites to the big dogs in New York and LA, and we still destroy them on content and speed.

The thing is, it takes a lot of planning and a ton of benchmarking to make it work. Fragment caching, more efficient queries, and not picking up every associated item will get most people 50% there. Most rails guys seem more interested in getting the flashy crap figured out and not enough time with optimization. They give all Rails devs a bad name because their crap is unstable and slow.

[logansbro@gmail.com]

Re:Sites Moved to Rails?

[Davorama]

11,000 requests in one second.... wow, that's huge!

How many did the system respond to?

Re:Sites Moved to Rails?

[OverlordQ]

Status: 500 Internal Server Error?

If throwing random crap to the script causes that, then yes, you have a serious problem.

Re:Sites Moved to Rails?

[bill_mcgonigle]

Thanks for posting this. It's a great boost of confidence for me on a project I'm working on.

If you have anything to say that sounds like, "squid in front of apache in front of mongrel" that would also be interesting, but I understand if you're not permitted to do so.

So, just cough twice if that's the case. ;)

Re:Sites Moved to Rails?

[bill_mcgonigle]

Thanks. /me has some reading to do.

I hope the linked site isn't running it

[sof_boy]

I am like the 10th comment and it is already slashdotted!

Re:I hope the linked site isn't running it

[Anonymous Coward]

Well it has also been Digged as well

http://www.digg.com/programming/Riding_Rails_Rails_2_0_It_s_done

Re:I hope the linked site isn't running it

[Anonymous Coward]

In what way are you similar to the 10th comment?

Re:I hope the linked site isn't running it

[crayz]

Well it's funny, because I believe weblog.rubyonrails.org is using Mephisto, which creates a static HTML cache of posts after they're hit the first time, and only updates the cache when the post changes. So the vast majority of requests to the post should be getting served straight from the webserver without even running any Ruby/Rails at all. The slow site would be more attributed to a lack of hardware resources than anything involving Rails

Re:this is fantastic

[calebt3]

Moderator obviously didn't read GPP.

You don't have to use ActiveRecord

[Anonymous Coward]

You could make a web app without ActiveRecord. You could write your own ORM framework or whatever. The whole philosophy is to have easy to use, quick to program, etc frameworks by default. If you want to chart your own course beyond that, there is nothing holding you back. Sorta like any other framework.

Re:You don't have to use ActiveRecord

[Bill, Shooter of Bul]

Yeah, and thats what I don't really like about frameworks in general. They have all of these awesome cool fast easy to use things built in. But sometimes you discover that your needs are too complex for the framework, and someone instantly replies " you don't have to use feature X". Well sooner or later you aren't using many of the cool features of the framework anymore. So why are you using the framework?

Re:You don't have to use ActiveRecord

[K. S. Kyosuke]

Maybe it would be a good idea to acknowledge that many application frameworks simply work for often quite large groups of people, but none of them is a one-size-fits-all solution. Hey, it's the same as with programming languages - maybe it's just natural. ;-) Even though I like and use C, Lisp, Ruby, Python (sometimes - it's good that many apps have adopted Python as a scripting language, it's just convenient) and Bash, I just fail to see why I should stop using X just because a few things are easier in Y. That said, I think that DHH and the Rails folks are doing awesome work - even though some people just won't like Rails, I think it wouldn't be fair to dismiss their work just because it fails to work for my application, while many other people seem to be happy with it. (And I'm not suggesting that the parent is doing this - that's just a general thought.)

OK, back to work now. :-)

Re:You don't have to use ActiveRecord

[smackjer]

I agree. That's why I build all of my computers by hand with raw transistors and whatnot.

Re:You don't have to use ActiveRecord

[Bill, Shooter of Bul]

Yeah, I do too. I think its very worthwhile for anyone in IT to actually build circuits from time to time, just to understand how. I understand the criticism you're making and its somewhat valid. I'm not trying to espouse the Not invented here syndrome. You have to make a real world decision in every non trivial application what existing tools can be used, and which ones will have to be created. I like the idea of libraries, and thats what I think a good "framework" should be. Sort of a scaffolding, where there is a well defined interface between components, allowing you to easily replace part of the "framework" with a different one, without introducing any bad hacks, and allowing all of the logically distinct parts of the "framework" to continue working with your replacement part.

Re:You don't have to use ActiveRecord

[Jugalator]

The problem with that analogy is that a manufactured CPU can still execute code regardless if it's using the Ruby framework, or any other framework, or a custom software API.

Re:You don't have to use ActiveRecord

[SilentBob0727]

I found this was very true of J2EE. As soon as I figured out I didn't have to use the XML-heavy and error-prone EJBs to access the database or my business logic, or route all my HTTP requests through brittle JSF calls, I stopped doing so and quadrupled my productivity.

I actually found RoR very liberating in this regard. In the majority of cases, the framework actually makes it easier for me to do my job, and if I need something the framework doesn't do, someone has almost always written a plugin to do what I need. This frees me up to write code specific to the problem domain instead of wasting sometimes days writing repetitive glue code.

Re:You don't have to use ActiveRecord

[Anonymous Coward]

That's the point of the Catalyst framework. The only problem most people have with it is that it is perl.

The only "cool features" is the ability to drop in other stuff you need, and its fantastic dispatcher.

Oh, and built-in server. And easy test harnesses. And support for fastcgi and mod_perl.

I guess it does have cool features, but trying to replace PHP isn't one of them.

Re:You don't have to use ActiveRecord

[3p1ph4ny]

I don't think you really understood his point. A manufactured CPU is limited only to the instructions that the manufacturer provides. The framework is limited to the operations that the framework provides. His point was that in some cases (not all) that's enough.

Re:You don't have to use ActiveRecord

[jozeph78]

Yeah, and thats what I don't really like about frameworks in general. They have all of these awesome cool fast easy to use things built in. But sometimes you discover that your needs are too complex for the framework, and someone instantly replies " you don't have to use feature X". Well sooner or later you aren't using many of the cool features of the framework anymore. So why are you using the framework?

Spring is the only framework flexible enough to get around the corners that things like rails back you into. If you find their JDBC classes not useful, you might still find their transaction management useful. However, their JDBC classes have helpers ranging from give me an object and I'll generate the SQL to having classes which allow your SQL to be ran with their improved exception handling. The really nailed the framework in the sense it provides some level of support no matter how complex your case may be.

Re:You don't have to use ActiveRecord

[DragonWriter]

The problem with that analogy is that a manufactured CPU can still execute code regardless if it's using the Ruby framework, or any other framework, or a custom software API.

And Rails can still run web applications that don't use ActiveRecord in the Model part of the MVC design. In fact, Rails comes bundled with a different base for models, as well (ActiveResource), as well as being usable with models that aren't built on Rails-supplied bases (though, of course, that's more work on the model side than using the Rails-supplied bases, if your use case is close to what those bases are designed for.)

so where's the problem with the analogy?

Re:this is fantastic

[Anonymous Coward]

And why exactly are you doing here, then?

Re:this is fantastic

[Anonymous Coward]

No, they just noticed that you responded to a troll, which is exactly what you're not supposed to do, and modded you accordingly. Personally I hope you get modded into oblivion, you deserve it. It's ignorant fucks like you that keep reacting to the trolls and keeping them coming here. You deserve what you get. Maybe you should just be a man and accept that you made a mistake, if you're even capable of being a man.

Scaling matters if you're Digg. Are you Digg?

[patio11]

While Rails might not be my first framework of choice to implement Digg in, I prefer to build sites which actually, you know, make money by solving problems for paying customers. When you do that, you don't really have to worry about scaling to infinity and beyond, but you do have to worry about expressiveness, maintainability, and time to market. (If you have too many customers relative to servers, heck, easy solution there -- the engineer in me says "just throw up more boxes", but the businessman in me says "pay somebody to worry about it so I can go back to counting my benjamins".)

I have a Rails site, my first (hopefully of many) for my small business, which plugs along at about 20 requests a second in tests. If I could saturate those 20 requests a second, I would quit my day job on the spot. Scaling? Eh, who cares.

(P.S. Day job is writing enterprise level crud apps for Japanese universities on the J2EE stack. They worry a bit about, e.g., getting hit with 8k users signing in simultaneously during class registration. You know what we do? Exactly what I'd do for a Rails app in the same situation ("don't do anything stupid like an n+1 queries loop, cache the important stuff, and buy enough hardware for the job"). Only difference in Rails is I have never wanted to poke my eye out with a spoon while writing it.

Re:Scaling matters if you're Digg. Are you Digg?

[pestilence669]

Ever notice how those most "concerned" about scalability tend to have never profiled or benchmarked their own code? ... or understand why you want to scale horizontally, rather than vertically? Whenever I build services that can handle 120,000 requests/sec., they usually just end up being 99% underutilized. Everyone likes to think THEY will be the next MySpace, with no server budget apparently. I highly doubt that any who argue Rails can't scale has ever had to deal with real distributed clusters. The database cluster will have many more scalablity issues than the webservers. This is such a non-issue, I cannot believe it. If you can scale JAVA!!!... You know what I mean.

Re:Scaling matters if you're Digg. Are you Digg?

[Fnkmaster]

Ruby makes me wanna poke my eyes out. J2EE is the abortion of the Java universe, unfortunately.

Re:Scaling matters if you're Digg. Are you Digg?

[FooBarWidget]

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.

Science

[Cache22x]

Okay, all I see on here is negative comments, what ever happened to the concept of "the right tool for the job"? Ruby on Rails is a gem (excuse the pun) in the realm of bioinformatics and chemical informatics. I don't need to be concerned with "scaling" when I am building a site with a maximum of 10 users. For labs and small companies everywhere needing to create and support small or large databases, RoR is fast and easy. It also has major industry backing from the likes of IBM and Apple. It may be a bigger problem for high-volume sites, but I have found it extremely useful. I am using it on the backend (for data management - the data is exported from the database to the legacy perl system daily) for sites like http://www.drugbank.ca/ http://www.hmdb.ca/ and on the frontend for sites like http://hmdb.med.ualberta.ca/foodb/.

I guess they didn't fix the scalability issues

[ThinkFr33ly]

Perhaps a web development framework's web site should be designed in such a way that it can handle a burst of traffic from Slashdot.org and Digg.com.

Otherwise, one might think that RoR doesn't scale.

Re:I guess they didn't fix the scalability issues

[abigor]

That's why I'm curious as to why Django (Python framework) doesn't get more press. It's fast and, unlike Rails, it's been proven to scale (ie washingtonpost.com). The languages have more similarities than differences, so it can't be that. Better marketing/hype, maybe?

Re:I guess they didn't fix the scalability issues

[ibbie]

That's why I'm curious as to why Django (Python framework) doesn't get more press. It's fast and, unlike Rails, it's been proven to scale (ie washingtonpost.com). The languages have more similarities than differences, so it can't be that. Better marketing/hype, maybe?

I think you hit the nail on its head. Django fricken rocks, in my experience, in both speed and usability.

It just doesn't have the hype engine going for it the way RoR does. It's for this reason that I'm hoping the Perl on Rails thing that the BBC wrote gets some momentum - the MCV/MTV approach is a Good Thing, for web-based development. It's not a change in language, so much as a change in how it's laid out. One must note that CGI::Application (found here) has existed for Perl for quite some time, and yet very few people (even Perl programmers) know about it, in comparison to RoR.

I do have to note that, having had experience with both Perl and Python, Ruby isn't bad at all. It's different in some ways, yeah, but so is Java, or C++, or C#. It's more a matter of taste, for a developer.

And scalability. (:

Re:I guess they didn't fix the scalability issues

[smackjer]

Ironically, I believe the rubyonrails.org site was built with PHP.

Re:I guess they didn't fix the scalability issues

[abigor]

Yeah, it's not so much a language thing either - yes, Ruby is slow, but Django also has sophisticated caching support, for example, which is a framework design issue that is language agnostic. I just think the framework itself, all talk of language aside, is really well designed. I like how you define your db scheme in Python (of course, it's possible to introspect an existing db to create the Python model classes as well), the loose coupling of urls, and so forth. The whole thing feels very practical and geared towards real-world usage.

Re:I guess they didn't fix the scalability issues

[RAMMS EIN]

``I do have to note that, having had experience with both Perl and Python, Ruby isn't bad at all. It's different in some ways, yeah, but so is Java, or C++, or C#. It's more a matter of taste, for a developer.''

I am not sure how you intended this to be taken, but if you meant to imply that the differences between all the languages you mentioned are just a matter of taste, I must disagree.

The languages you mentioned differ on features that have a very real impact on productivity, reliability and maintenance. I would say that goes beyond being a matter of taste.

One example I would like to mention is metaprogramming. Metaprogramming is, basically, letting a program write your program for you. It is very useful, because it can eliminate repetition in your code, which allows you to be more productive and introduce fewer bugs (the alternative to metaprogramming is usually "copy, paste, adapt", which is a rich source of errors).

As a Lisper, I am very sensitive to this issue; my hands itch each time I recognize a repeating pattern in code, and I resent sometimes having to leave the repetition there.

Now, of the languages you mentioned, Ruby is pretty strong on metaprogramming and Java isn't. I think Java actually offers some metaprogramming, but all Java code I've seen and written is full of things like "this.x = x; this.y = y; ..." and "x.setFoo(y.getFoo()); x.setBar(y.getBar()); ...", "public static void oogle(...) throws A, B, C { ... } public static void boogle(...) throws A, B, C { ... } ..." and other stuff that makes my skin crawl.

On the other hand, Java has static typing, which catches many errors at compile time, whereas Ruby has dynamic typing, which lets type errors slip until the wrong code actuall gets executed, which Murphy's law dictates will cause your program to blow up when an important customer is doing something critical.

On the gripping hand, having come back to Java development after years of blissful absence, I see that more and more Java code is being replaced with XML, throwing overboard the type checking and run-time performance advantages of Java...

Re:I guess they didn't fix the scalability issues

[abigor]

1. Really? Can you name some high-traffic sites where it's in use? I wasn't aware of this.

2. Yes, it does have more momentum, and my original post asked why, in case you didn't read it.

3. Django doesn't emulate Rails, as you imply. It's been around for years and is quite distinctively different. There are some good Django vs. Rails comparisons online if you want to read up on it, since you don't seem to know much about it.

Re:I guess they didn't fix the scalability issues

[FooBarWidget]

It proves that the people who complain that Rails can't scale are just that - complainers.

Re:I guess they didn't fix the scalability issues

[FooBarWidget]

Rubyonrails.org is written in PHP. If anything, this "proves" that PHP doesn't scale.

One might now be tempted to attack Rails for using PHP. Keep in mind that rubyonrails.org is a simple and "dumb" website with only some static content (except the blog). For that kind of small stuff, PHP is best.

Re:I guess they didn't fix the scalability issues

[the eric conspiracy]

The compile time static type checking in Java vs. dynamic typing in Ruby / Python is really the fundamental difference between using these languages. Java isn't as easy to write or as fun to write, but once you do write it the type checking makes the testing process in Java much faster and more robust. Factor in the Java runtime performance advantage and it becomes fairly obvious that Java is not going to be replaced by Ruby / Python anytime soon.

I really enjoy coding in Python, and write all my personal stuff in this language. But for teams over 3-4 people I think I'd rather use Java.

Re:I guess they didn't fix the scalability issues

[dubl-u]

But for teams over 3-4 people I think I'd rather use Java.

I feel the same way. For small projects, I love dynamic languages like Ruby. In Java, you have to be painfully explicit, whereas RoR has a lot of excellent magic, and things practically happen on their own.

The problem with magic, though, is that it's magical. When I'm the wizard, that's fabulous. When I'm trying to get my head around the code of somebody who isn't here anymore, RoR is not so good for that. Suddenly, Java's annoying redundancy and its demand you keep stating the obvious comes in handy, as you can actually tug on something and find what it is connected to.

Re:I guess they didn't fix the scalability issues

[VGPowerlord]

I'm not that familiar with either framework (I've tried both for short periods), but I've got to ask this question:

3. You complain that frameworks copy Rails, but when the GP says Django doesn't do that, you then ask if it has Rails features?

Please make up your mind whether copying Rails is a good thing or a bad thing.

Re:I guess they didn't fix the scalability issues

[pavera]

I prefer django over RoR hands down. I drank the RoR cool aid about 8 months ago, started working on a couple projects... after the initial "oh wow, that was easy to get started" RoR got significantly more difficult, I didn't find the documentation particularly helpful, and things that I thought intuitively would work and made sense were "not allowed" because the RoR conventions forbade them.

Enter django. Wow, all the power, none of the "Hansson said this is how it should be, so no other way is possible" handcuffs.

To me django is a much better designed framework, it has in my opinion a much more powerful database abstraction layer, it is more intuitive too. working in Rails for > 4 months I still had to look up the syntax for doing activerecord queries every single time. django's query syntax just makes sense to me, and is much more intuitive. And what can I say, I've never enjoyed making HTML forms more than using the newforms library that builds them for you (oh yeah, and validates them for you, and marshals form input into objects automatically...).

Also, the simplicity of setting up a production django server is so much easier than RoR. Sure, once you start having lots of traffic, building a fully scalable system is probably going to be similar. But to set up a single server for a low traffic site, or a small company intranet, apache+mod_python is great. mod_ruby has huge performance issues, ror+fastcgi in apache is atrocious, mongrel can be ok.. but then you still have to set up apache in front of it, and its not a simple apache set up as you have to configure all the proxy stuff...

Besides the fact that python is ~10 times faster than ruby (just at the interpreter level) and you've got yourself a nice little powerful system with django.

Maybe once django hits version 1.0 they'll get a bit more hype, but I've actually seen more posts on this story saying "check out django" than I've seen people saying they absolutely love rails.

Re:I guess they didn't fix the scalability issues

[drew]

I'm not so sure I agree. As somebody who's moving from JScript on the Server side to C#, I have yet to be convinced that using a compile time typed language makes testing and debugging any easier than using a run time typed language. While we are excited about the move for a number of reasons, they mostly involve performance (the tricks we've had to pull to get our ASP classic sites to handle are traffic load are ridiculous to say the least) and having a built in template / code behind system. None of us is excited about switching to a compile time typed language, though. If we could continue to use JScript (for all it's warts) as the code behind language and still get the same performance and SOC benefits, I think that we would in a heartbeat.

I have yet to encounter a case where a compiled language's type system has saved more work in testing than it created in writing the code in the first place. The kinds of bugs that compile time checking catches just aren't that hard to debug (for me at least). And the bugs that come from having to jump through ridiculous casting hoops (e.g. with system defined delegates) are often worse than their equivalent in an interpreted language.

Besides, in my opinion, a team of more than 3 or 4 people is a problem in any language. My solution would always be to switch to a smaller team before switching to a new language...

Re:I guess they didn't fix the scalability issues

[Breakfast Pants]

That question mark is the equivalent of saying "say waaaaah?"

Re:I guess they didn't fix the scalability issues

[VGPowerlord]

No, he's referring to the "but I've got to ask this question:" that I put.

He has a point. I changed part of it without going back and correcting the first part.

See, I should have just tacked "WTF?" at the end.

Re:I guess they didn't fix the scalability issues

[DaTroof]

One might now be tempted to attack Rails for using PHP. Keep in mind that rubyonrails.org is a simple and "dumb" website with only some static content (except the blog). For that kind of small stuff, PHP is best.

In that case, was the infamous screencast where David slams out a Ruby on Rails weblog in 15 minutes inaccurate, pointless, or both?

Re:I guess they didn't fix the scalability issues

[Wiseman1024]

For a large project, I'd have even more of a reason to use a dynamic language instead of Java. Static typing without even type inference is a nice way to shoot your foot by limiting yourself (build left-handed hammers without leaving the possibility that your hammers could be used in ways you didn't initially think of) and waste time defining everything. And the language feels like a toy. No builtin lists and dictionaries (hash tables), no first-class functions, no lambda-expressions, forced OO, yet single advanced OO features such as function properties, message passing traps or applicable objects, ... You have to deal with huge inheritance trees, interfaces, generics, and all sorts of mechanisms to overcome the language's massive shortcomings, and define all sorts of classes for nothing. It's better to have 5 useful classes with 50 functions that work on each, than to have 50 classes with 5 functions that work on each. On top of that, the language and its environment have serious issues, part of which have been resolved, but the overneingeered, ludicrously bloated standard library stays and grows even worse every day.

Java is one of the things I don't do without getting paid, and if getting paid, I start looking for other jobs once I'm back home.

Re:I guess they didn't fix the scalability issues

[FooBarWidget]

What does that have to do with rubyonrails.org being written in PHP?

Re:I guess they didn't fix the scalability issues

[ESqVIP]

Actually, it lies mostly in the languages. Rails makes heavy use of Ruby's metaprogramming abilities to perform magic, turning the whole thing into domain-specific languages.

And about scalability, I'm not sure if Rails is as much a problem as is Ruby. Still, people managed to build websites like Twitter and Yellow Pages on RoR, and afaik neither of them even resorted to JRuby, which on v1.0 already performs slightly better overall than Ruby 1.8 for Rails apps, and with the soon-to-be-released v1.1 shows considerable performance gains, beating even YARV (Ruby 1.9) on some specific tests.

Re:I guess they didn't fix the scalability issues

[jilles]

It's not only type checking but tool maturity is what really bugs me. The development tooling for dynamically typed languages is complete crap and quite literally many years behind to what Java developers are used to. I had to do some python django coding recently and sure it is a nice framework for simple stupid stuff that wasn't so hard anyway. But damn it, I'm fixing stuff all the time that normally eclipse points out when I'm typing it in Java. Stuff like "this identifier is nowhere to be seen on the imports, shall I fix it for you?". It's trivial to fix of course but it just sucks finding it out at runtime, having to fix it manually and never knowing for sure if you've covered all the code paths. When doing java development in eclipse, I just ctrl+1 + enter, or ctrl+shift+o (organize imports), or ctrl+s (I have organize imports automatically run on save). I don't actually have to think about importing stuff. That's just one example. Of course I'm using the python plugin for eclipse but it seems to be quite buggy and it only half works.

Amazingly, many python programmers settle for seventies style tools (editor + console) and completely rely on the interpreter & reality to point out what they did wrong this time. That is just stupid.

I've been going through a edit, restart django, hit F5, analyze the stupid shit it throws at me this time cycle non stop for weeks now. I haven't had to do that in years, and it isn't fun. It makes me waste shitloads of time typing stuff I usually ctrl+space and running into whole categories of bugs and issues that I'm normally stopped from introducing. It doesn't help of course that all exceptions fall through forcing you to first experience problems before you fix them. And of course most exceptions take some very specific circumstances which is why the web is full of web pages that were clearly the result of some uncaught exception.

Additionally, I miss all the goodies that come with (or can be plugged into) a good Java IDE like static code analysis (metrics, common bug patterns, bad practices), good refactoring support (PDT has some but it is buggy), code templates (like generate a nice for loop on this array or put a nice try catch around this line with all the right exceptions caught) quick fixes, guaranteed executability if the IDE doesn't complain (not the same as correctnees of course). And that's just the stuff I actually use regularly. There's also things like debuggers that you can attach to a server, remotely; monitoring and management tooling built into most decent Java application servers, profiling tools that tell you where the bottlenecks are in your running software, etc.

For me the only real value of languages like python and ruby are the expressiveness provided by functional programming like constructs you don't have in Java (currently). These are kind of nice to have. Programming the same stuff in Java takes a few more lines and extra lines of code are more bugs (statistically bugs / LOC is more or less constant so more LOC = more bugs). Java programs are measurably larger in terms of LOC compared to python or ruby, just like they are measurably much smaller when compared to C/C++. This difference in size means you get better productivity and less bugs. But the tooling just needs to catch up with this century. If dynamic typing is the reason that can't be done: fix the bug and remove it already.

Smart tools mean more time for the real work. If I need to do real work, I use something like Java or something with similarly capable tooling (technically that is more and more a hypothetical language, you might argue C# has some of the goodies here).

BTW. I'm aware of progress being made here. I played around with ruby in netbeans 6.0 a few days ago and it was looking quite good. It even automatically upgraded railse to 2.0.1. Nice. All on top of JRuby of course :-).

Re:I guess they didn't fix the scalability issues

[the eric conspiracy]

As soon as you mentioned type inference I knew you are inexperienced. Use of this technique always requires some other limitations to what the language can do, c.f. the attempts to implement it in Python. FC functions look like fun - until you try to implement them portably. As far as lists and dictionaries, Java's collections classes are just about the best you will find. Far superior to what is available in Python or Ruby.

You have to deal with huge inheritance trees, interfaces, generics, and all sorts of mechanisms to overcome the language's massive shortcomings, and define all sorts of classes for nothing,

There is a long tradition of over-use of inheritance in OOP. Fortunately that practice is dying out. It has nothing to do with the structure of Java, but rather how programmers were taught OOP 10-15 years ago.

Java is one of the things I don't do without getting paid, and if getting paid, I start looking for other jobs once I'm back home.

Unfortunately for you that really limits the amount of work you will be able to get.

Re:I guess they didn't fix the scalability issues

[DaTroof]

It has to do with the reason for choosing PHP. The reason you gave doesn't seem to jibe with the hype surrounding Ruby on Rails.

Re:I guess they didn't fix the scalability issues

[Wiseman1024]

I prefer plain dynamic typing (as long as it's strong typing), but type inference systems found in some functional languages such as MLs or Haskell would be better than a type nazi preventing you from appling a perfectly valid function to a new object you hadn't previously thought of. They did attempt to implement such a thing on Python? Why? The language doesn't need any better treatment of types than it already has.

Regarding Java's collections, no, they're not barely as useful as those in Python, and probably Ruby's too. For starters, last time I checked Java didn't have dictionary literals, nor any advanced slicing operators, nor operators played on them or operator overloading on subclasses of them. You can add hash tables to C if you want, but they'll never be as comfortable as they are in a language that supports them natively and properly.

Overuse of inheritance, as well as general overengineering and a love for bloat is a common practice in OOP-forced worlds, and it does have something to do with Java - its standard library is full of it. It's my favourite example of bloatware. It's bloated to the point sometimes I found myself wondering whether I should use a standard library feature, or implement it myself in a decent way.

I know not doing Java limits jobs for me, so does not doing COBOL, Fortran, or mopping floors. But as long as I can get away with it, I prefer to have fun at work and use as much functional, generic and meta-programming as I can.

Re:I guess they didn't fix the scalability issues

[FooBarWidget]

The reason is that PHP is a "Hypertext Preprocessor". It even says that for its name! PHP is perfect for simple websites in which all pages have a shared header and footer. Rubyonrails.org doesn't even access the database. As soon as your web app has more than 500 lines of code and accesses the database, Rails will become very attractive.

It all boils down to using the right tool for the right job. Do you use a hammer to repair your TV? "OMG they don't use Rails for their own static content website that doesn't even access the database, therefore Rails must suck!" is just an excuse that people use to mod down Rails. It has got nothing to do with its merits.

Re:I guess they didn't fix the scalability issues

[Anonymous Coward]

Who the fuck modded this as interesting I wonder. Let me get this straight:

You say, Python is 10 times faster than Ruby at interpretor level. Forget about micro benchmarks, but did you at least see this:

http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=ruby&lang2=python

Python is 2 to 4 times faster on average. But above benchmark is still quite synthetic and may fool you.
Real code, is another story, do you realize that?

" mongrel can be ok.. but then you still have to set up apache in front of it, and its not a simple apache set up as you have to configure all the proxy stuff..."
Oh oh.. I mean you got to be real retard to say something like this. I am not using apache these days, but with 2.2, it was dead simple to configure.
I use nginx these days and you can configure a new machine with nginx in front and mongrels in back within few minutes. You said, for small websites, it pain, blah blah.
Heck, you can go ahead and run just mongrel there for a small website and it will work fine. How about that?

I am not baffled by your comments, which clearly show, but I am just pissed at general internet crowd.
Thank you.

Re:I guess they didn't fix the scalability issues

[pavera]

well, I'm glad that you ruby guys have changed your recommended web server AGAIN! (from apache to nginx I guess?)

Seriously if I had deployed a production site on Rails 1 year ago, to stay current with the "recommended" solution I would have had to change my entire web architecture 4 times (apache+fcgi, lighttpd+fcgi, apache+mongrel, now nginx+mongrel). That my friend is the definition of instability.

Alternatively, I set up apache+mod_python 1 year ago... and what do you know, I haven't had to make any architecture changes or update anything in my production setup and it just keeps cranking along and its still the recommended solution. It is widely supported, well documented, and dead simple to set up (2 lines in httpd.conf)

yes, benchmarks are dangerous, sure, they aren't the end all be all. But it is widely accepted that python is faster than ruby. Sure YMMV and maybe your code sits perfectly in one of ruby's few sweet spots where it shines performance wise (by shines I mean it is almost as fast as python, and therefore almost useable). Besides these benchmarks which show 2-4 times speedups for python, I have seen other specific real world code benchmarks which show huge performance problems in Ruby (I'm talking 2 orders of magnitude 100x's speedups using python over Ruby). I've seen a few benchmarks where Ruby is at or slightly faster than python, but I've never seen a single benchmark that shows Ruby massively faster than Python, and I've seen many the other way around. I know that the next version of Ruby shows some improvements in performance, but I still prefer the django framework over rails. The database layer specifically is much more powerful and intuitive to me. Maybe Rails has improved since I dropped it 4 months ago, but Django does a much better job of fully supporting legacy databases. It doesn't mandate "build your DB this way or Rails won't be happy". Django's built in admin is scaffolding on steroids, with full on data validation built in automatically. It is true DRY as you build your model class and DB at the same time in the same file (as opposed to Rails where you build your database in a file, and then go to a different file to define validation and write convenience functions, and trust rails to introspect your DB to build your models). Rails had as of 4 months ago nothing that could touch Django's newforms library which makes building and validating HTML forms a dream and a breeze.

Maybe I'm retarded, probably I am, but I don't want to be learning/implementing a new web architecture every 3 months. I don't want to be beating my head against some brain dead "convention" when a properly set up "configuration" system will more powerfully and flexibly achieve the same thing. I don't like the way Rails tries to dictate the end all be all of project design. Sometimes the right choice is to cut a corner or not explicitly follow MVC. With Rails I constantly felt like if I wanted to do something differently or in any way strayed from the "Hansson way" that I was in a narrow canyon with 500ft shear cliffs on either side. With Django those walls are gone. Sure, everything I write might not be the best, and maybe I make some bad decisions, but, on the whole, I can get more done, and I can refactor things and get things into a sane setup when the need arises. In rails you do it right or you don't do it, which is great if all your coders are braindead monkeys, but if you're just trying to prototype something in a hurry, I don't want to have to explicitly follow MVC to a T, I want to get something up in front of the customer ASAP.

Re:I guess they didn't fix the scalability issues

[pavera]

I find your argument at least somewhat misleading. I'm not a RoR fan, prefer Django, but this argument is the same in both.

I have worked on large J2EE projects and I absolutely hate going through other people's code in java, especially in a J2EE stack where you've got a class structure 15 layers deep, so you have to jump through 30 function calls to get back to the base class that is actually causing some problem, or which is actually performing the action. The whole J2EE system to me is completely over engineered and clunky. making changes is so horridly difficult as you have to understand exactly what this whole tree of classes is doing before you can safely make a change, and it seems like at least 90% of the class structure is just there to comply with the J2EE/EJB standards. Lots of busy work not much actual working code.

RoR and Django both induce much nicer code to read and understand. As I stated I've got more experience with Django, but I work daily with 3rd party django apps written by other people. It is trivially easy to look at the code, figure out what it is doing, and fix/extend/whatever. None of the J2EE apps I've worked with has had this property.

Now Django is probably a little more explicit than RoR. You actually define your model class members (as opposed to RoR which introspects this directly from the DB, the magic you mention). But, because all of this backend infrastructure type stuff is hidden from you, the only code you see is the code which is ACTUALLY DOING SOMETHING. Whereas, in Java, you get to wade through thousands of lines of code that is doing absolutely nothing but keeping the environment happy.

Re:I guess they didn't fix the scalability issues

[dubl-u]

[...] I absolutely hate going through other people's code in java, especially in a J2EE stack where you've got a class structure 15 layers deep

No argument here. When I find that crap, I rip it out. But I think that pathological code in any language should just be thrown out and rebuilt. I was more thinking of non-worthless code bases.

For those, I think Java's strict, static typing makes it relatively easy to run down mysteries when you compare it with, say, somebody redefining the Ruby methods on Array and String. Or doing run-time code generation, a popular Ruby trick that makes me all stabby.

Now that I think about it, though, my main preference is not to take on scruffy code bases at all. Here's to hoping that when this tech bubble pops, it's gentle enough that we can all avoid that kind of work.

Re:Scaling matters if you're Digg. Are you Digg?

[crayz]

What language do you use that's more readable and expressive than Ruby?

Re:Scaling matters if you're Digg. Are you Digg?

[crayz]

Exactly. The fact is, Ruby is slow. Rails is slower. This is a very accurate complaint about Rails as a web framework, although in the real world it's generally not much of a problem. Somehow though, people have confused speed with scalability, and start claiming the Rails isn't scalable. In fact Rails tends to encourage or at least make fairly easy a shared-nothing architecture which allows a trivial "throw more servers at it" solution to scaling

That said, because of Rails speed, you will wind up needing to scale it sooner and larger than you would a site written in Django, say. If people want to complain about the hardware costs of running a real-world Rails site, I encourage them to do so and put up real numbers regarding the money they spend on developer time and other company expenses vs. server costs, and how Rails being so CPU-hungry is killing their bottom line. So far I've seen none of that, just uninformed whining

Does it still require Mongrel?

[ibbie]

Or rather, since I haven't been keeping up with the development process, perhaps I should ask, is there a viable apache 2.x module for ruby that allows one to run RoR sites without relying on mongrel/other web servers?

Because, frankly, if it can't be run on apache 2.x, I (and the company I work for) won't touch it. We have already seen the scalability nightmare that RoR was, of course, so obviously we're a bit skeptical about performance optimizations. (:

Note: I have nothing against using new technology, even if it requires learning a new language, but when one has a hundreds of sites that require web server A, and a framework requires the shoehorning of web server B, well, the aforementioned framework loses its appeal.

Re:Does it still require Mongrel?

[smackjer]

http://www.fastcgi.com/

Re:Does it still require Mongrel?

[lisany]

Apache's only role in any Rails setup is mod_proxy_balancer to feed requests to a pack of mongrels.

To others:
As for not scaling? Load of bollocks: Share an application root on NFS, configure rails and mongrel to log to a machine specific directory and just keep popping app servers into your cluster as needed. Or make extensive use of built-in caching or custom caching with memcached. It won't scale itself. Don't be lazy, people.

Re:Does it still require Mongrel?

[Anonymous Coward]

RoR never required mongrel. There is mod_ruby to tie Ruby directly into Apache, or it is very simple to use it as cgi or fcgi through Apache. It's just that nobody who knows what they are doing would use mod_ruby or cgi because the performance is abysmal and harder to scale (note I'm using the correct terms in that scalability != performance) than using fcgi (still hard to scale) or the fairly new technique of mongrel clusters (excellent performance and incredibly easy scalability).

Re:Does it still require Mongrel?

[Anonymous Coward]

pack of mongrels

Fucking faggot.

Re:Does it still require Mongrel?

[esconsult1]

Nope. There are other alternatives. For a long time we used apache + mongrel. Now we ditched apache and just use Litespeed, which is fabulous with rails.

At this point...JAF

[sigzero]

RoR is just another framework now. Almost everything has caught up to it. The biggest question to ask yourself is "Do I want to program in Ruby?". If the answer is "no" then meh who cares about this.

Re:At this point...JAF

[CarpetShark]

The biggest question to ask yourself is "Do I want to program in Ruby?". If the answer is "no" then meh who cares about this.

The other one is, "can ruby perform well enough for any reasonably loaded webapp?". So far, most of the answers I've heard amount to "no", or "well, if it gets to that stage, you can always buy a cluster".

Re:At this point...JAF

[sigzero]

Maybe, but if you like Ruby you are probably going to find "ways" around those issue even if those "ways" are the best ones. I would probably do the same.

Re:At this point...JAF

[Anonymous Coward]

For those who feel too old to learn new languages, there's even Perl on Rails now. It sounds like an abomination though. People should learn Ruby. Not only is it Perl Done Right, it helps you think better.

The server's...

[Vthornheart]

Apparently the server's done (like Nixon, not like Dinner).

Re:Scaling matters if you're Digg. Are you Digg?

[slaingod]

Every time a RoR article hits Slashdot, there is a scale/speed question that gets raised. Realistically, there are a ton of things you can do to get performance where you want it to be. The first is to dump mongrel and use FastCGI or similar. FastCGI is 3-5x faster than mongrel. Mongrel is great for low traffic sites, and for dev, don't get me wrong.

The upper limit I see with RoR/FCGI is around 2500 requests per sec, for a 'is the server alive' ping, that simply returns 'Yes'. Typical, results are in the ~100 requests per second range with moderate db access, and rendering to xml or html. 100 requests per second was enough to handle a 24 hour media buy on the frontpage of myspace for example (100,000k unique visitors-ish).

Moving your static assets off of your server and on to S3 or another CDN is obviously a big help here, so your server/bandwidth is only taken up with requests that need/affect the db. From the example above, with the MySpace media buy, the total for that day was $20-30 I believe in bandwidth costs, and this was a site with a video mixer that had tons of images/video/mp3 and large flash objects. Obviously, mongrel shouldn't be delivering your assets locally anyway, apache/lighty etc should be.

Ultimately it comes down to design and caching when it comes to getting that top performance out of it. My 100 requests/sec wasn't using MemCached or fragment caching, and the mysql db was local. Caching in Rails is a little less than helpful for highly customized for each user sites, but there are plugins that extend it like extended_fragment_cache(ing?), that allow you to templatize things like ID's, etc. Think of say a forum topic listing, where only the topics change as you paginate. With extended fragment caching, you basically draw the page once, and then pass in a hash of the variables that replace the placeholders each time you draw a new page.

Another big thing with ajax sites, is to use link_to_remote with the :update => 'some_div', rather than using the rjs/render :update stuff in the controller. escape_javascript is one of the BIG performance issues in Rails, as it is basically just multiple gsubs. Designing around that is a big win. A native C escape_javascript should be a high priority for the rails/ruby devs, with optimization for the memory allocations (ie. scan the string to see how much it will grow, allocate, and just do one pass to expand).

Scalability

[RAMMS EIN]

Having worked on web sites using Rails in a previous job, I have to say I love many things about the framework. Like Ruby, it gets a lot of things right, and a few things very wrong. On the whole, I found it great to work with.

Recently, a friend told me that scalability was a major concern with Rails. I am not aware of any issues with that with the sites I worked on (which are pretty high traffic), but I left the project before the sites went live, so I can't say for sure that there weren't any issues. Can anyone here chime in on whether that has ever been a problem with scalability in Rails, what the causes of the problems are, and whether Rails 2 does anything to fix them?

Re:Scalability

[smackjer]

It depends. There have been cases (such as Twitter) where Rails apps have run into problems at high load. However, there are always solutions. Twitter's problem wasn't caused by Rails, it was caused by how they were using Rails. Their bottleneck was actually in the database, and Rails doesn't support multiple databases. Within 2 or 3 days of the issue becoming public a plugin was released. The nice thing about Rails and Ruby is that they are flexible. The dynamic nature of Ruby makes it easy to extend, and Rails benefits greatly from that.

Re:Scalability

[Anonymous Coward]

Right.. Let me rephrase that for you: Are there any professionals out there who would like his ineptitude be the center of attention for a few glorious posts as the All Star RoR Dream Team tears any semblance of confidence from the hapless victim and sends him Quasimodo style hulking back to php?

No really. I want this to happen
just as much as the next guy.

But just to be safe, I'm posting
Anonymous

Re:Scalability

[Anonymous Coward]

It might, with database query caching and client-side session storage. The big performance boost will come with Ruby 1.9 and YARV, though. Apparently Rails 2 is pretty close to Ruby-1.9-ready.

It's new tech for people who weren't aware of...

[CarpetShark]

You're absolutely right: Rails is just a framework on top of Ruby, and neither are very special. Except in that a lot of people were still using crap coding techniques like mixed PHP and HTML, until frameworks like RoR and Django introduced them to MVC, ORMs, templates, and Unit Testing --- AND the speedups and elegance that go with those things, once you have an actual framework that does the boilerplate for you.

There's nothing special about RoR, no. But compared to tools like PHP, it's a godsend.

It is a pity ...

[jopet]

that one cannot simply deploy RoR on Apache. That is what remains the big advantage of perl and especially PHP-based solutions and frameworks.

apache

[Anonymous Coward]

There are multiple deployment options available.

The preferred option currently is multiple mongrels proxied by nginx.

But by all means, you can use apache & fast-cgi to run rails apps (even a sane php setup should use php-fastcgi with apache, not mod_php).

Comment removed

[account_deleted]

Comment removed based on user account deletion

Re:this is fantastic

[calebt3]

I was making a joke, cutting and pasting his sentence and changing a few words to turn it around. Apparently nobody found it funny. All well..

Maybe you should just be a man and accept that you made a mistake. OK, so feeding the trolls is not a good idea. No need to be rude about it. Has ignoring them ever been successful?

Re:Scaling matters if you're Digg. Are you Digg?

[smackjer]

Great post, parent. Wish I could mod you up!

Stored prodcedures can improve performance

[Knetzar]

Stored procedures can improve performance by reducing the amount of data that needs to be returned from the DB. Instead of getting a ton of data from the DB, the application can make a call and only get the data it wants. This simplifies application development and improves performance. You can think of things like MAX, MIN, etc... as stored procedures (I don't know if they are or not)

I have been at places were the DBAs have found very expensive calls to turn into stored procedures and the net result has always been an increase in performance and resulted in a simpler application.
Example:
Get all shoes
for each shoe {
    get all skus for that particular shoe type (these would be different sizes/colors)
    calculate the minimum and maximum price of the skus that are in stock
}
return shoe name, shoe desc, price range
(This might be a bad example, since good SQL and a good DB might be able to speed this up...but I'm not an expert)

Note: I am an (C/C++/Java) application developer, not a DBA

Re:Stored prodcedures can improve performance

[cbciv]

Stored procedures can improve performance by reducing the amount of data that needs to be returned from the DB. Instead of getting a ton of data from the DB, the application can make a call and only get the data it wants. This simplifies application development and improves performance. You can think of things like MAX, MIN, etc... as stored procedures (I don't know if they are or not)

I have been at places were the DBAs have found very expensive calls to turn into stored procedures and the net result has always been an increase in performance and resulted in a simpler application.

Example: Get all shoes
for each shoe {
get all skus for that particular shoe type (these would be different sizes/colors)
calculate the minimum and maximum price of the skus that are in stock
}
return shoe name, shoe desc, price range

(This might be a bad example, since good SQL and a good DB might be able to speed this up...but I'm not an expert)

What you're talking about can be easily done in a simple query:

SELECT shoe_name, shoe_desc, MIN(shoe_price), MAX(shoe_price) FROM shoes WHERE shoe_group = 3 GROUP BY shoe_name, shoe_desc

The large performance gain comes from using a query instead of ruby/perl/whatever code to iterate through a table, not from using a stored proc. Of course building a query like this in code can open the door to SQL injection, so it would be better to use a stored proc (though the same thing can be accomplished with parameterized queries, if the DB API supports them) for security reasons.

Any potential performance gains specifically related to a stored proc (as opposed to an ad hoc query) are likely to be due to the DB engine's ability to precompile or cache the stored proc, rather than in the size of the dataset sent back to the client.

Comment removed

[account_deleted]

Comment removed based on user account deletion

Why the hate?

[devjj]

Seriously.. why does Ruby on Rails get so many people so fired up? If you don't like it, don't use it. If you do like it, feel free. There's no one-size-fits-all solution, but for many people Rails comes pretty close. If you're not one of those people, there are plenty of other frameworks and languages.

Why do people in any kind of IT have such huge egos? It's counterproductive and at the end of the day, if you're making the client happy, and that makes your boss happy, you've done your job.

Re:Why the hate?

[Anonymous Coward]

It's easy.

RoR is so over hyped by the zealots that use it and make mythical, false claims. Have you ever noticed how they spit back quotes straight from the site or books or whatnot? If I had mormons and jehovah's knocking on my door daily, I'd be pissed off at them too.

Why the backlash? False promises lead to adoption and shift job markets. Hype convinces the non technical to make technical choices. Don't any of you remember all the Java hype of yesterday?

Unfortunately it's not so easy to just ignore and go about your life programming in your language of choice. If you're a perl coder, python coder, php coder, etc and you web develop, then RoR is your enemy. Maybe python should be getting all the attention and hype and the majority of php coders should be moving up not down. Then we'd have better scaling systems anyway. Is python/django so much harder to user than RoR? I'm not convinced that it is. I know for a FACT that it's damn faster.

Re:Why the hate?

[Anonymous Coward]

It's not that people hate Ruby on Rails (although some probably do); it's that it is completely overhyped. Ruby on Rails is to Slashdot as Ron Paul is to Digg.

Re:Why the hate?

[iggymanz]

it's not damn faster for me, I find all scripting languages on the front end waiting for back/middle tiers to go chunka chunka chunka. I do notice some web methodologies tend to sell hardware, like j2ee.

Re:Why the hate?

[devjj]

I can't take you seriously when you claim that all Rails developers are "zealots." You wear your bias on your sleeve.

As a Rails developer myself, I know for a fact I'm not out there making "mythical, false claims." When I develop solutions for clients, I sell them just that: solutions. I don't sell them Ruby on Rails solutions. I just sell them solutions. My experience is unless a client has a specific desire to use a particular framework or language (.NET and J2EE are popular requests), they don't really care. So long as the finished product does what they ask, the actual technology behind it doesn't seem to matter. I certainly see that for the not-Rails coder that Rails is your competition, but if the only reason you don't like it is because it gives someone else an opportunity, perhaps what you should be doing is picking up a book and learning what it's actually about, instead of pointing fingers.

My experience with Rails developers is that they're excited about the framework because they feel it delivers on a lot of its promise. That's certainly how I feel, although anyone who's used it for any kind of professional work will know that it isn't the be-all-end-all and that you still have to do a lot of work to get a product you're happy with. That's true for most good frameworks. They make the job easier; they don't do it for you.

Rails almost certainly isn't the first challenge of its kind you'll have faced, and it isn't going to be the last. You can't expect to code PHP and have PHP be the be-all-end-all for the rest of your career. It just doesn't work that way. New things come out, and some people adopt those things. Fighting your competition with name-calling isn't going to get you anywhere. At the end of the day, Rails hasn't seen the kind of adoption it has solely because of good marketing. At the end of the day, product actually matters, and Rails has chops.

Re:Why the hate?

[JAlexoi]

Have you been on the moon when RoR hit the hype peak?
J2EE got the most hitting, PHP got some also, basically RoR came into existence because they hated EVERYONE!
Thankfully people grow up and get smarter.

Re:Why the hate?

[devjj]

Rails was borne of a production application: Basecamp. It didn't come into existence because they "hated EVERYONE!" The application had already been built in Ruby, and DHH saw that there was a lot of the system that could be reused. He packaged it up, and released it under the name "Ruby on Rails."

Rails has gotten hyped, no question, but the level of rhetoric leveled against it has gotten to the point where people are unwilling to acknowledge that it is a capable framework. Great marketing only gets you so far, and like so many other wildly popular "products," at the end of the day people tend to use what works for them. There aren't many examples - open-source or closed - of things that get lots of acclaim without deserving any of it. Your dislike of Rails has nothing to do with Rails itself, but rather how you perceive it to be portrayed. We all remember the Java hype. We all remember the .NET hype. Hype surrounds everything new, and Rails is new. The hype will die down, and when it does, what you'll find is that it will settle into its own area of web application development, right alongside all of the other great frameworks, languages, etc. Java didn't really revolutionize the world the way we were told it would. It did, however, become a very capable branch of application development, and thousands of developers make an excellent living doing it.

Sure, we sometimes joke about Ruby on Rails being "better" than the alternatives, but for professional Rails developers it's more about having a good time than anything else. It might even happen to have something to do with so many of us liking Macs - we Mac-users are a rather devoted bunch. Sometimes it's easy to read too much into it, and I think that's what has happened here. I attended RailsConf this year, and for the most part the people I met were enthusiastic developers who were making web applications and having a pretty good time doing it. If the work you're doing with not-Rails is working, there is little reason to believe that the existence of Rails or even the current enthusiasm for it is going to translate into competitive pressure you won't be able to handle. If you're good at what you do, and already have development tools and practices that work for you, none of that is going to change, and that doesn't mean you don't stand to benefit from it. Just take a look at CakePHP.

Any negative impact Rails has will be felt by the people on the fringe. Those who don't really know how to develop applications, and are ill-suited to the tasks with which they are currently tasked. Every time something comes along that attempts to elevate the discussion, there will be those unable to keep up.

That does not mean that you stop innovating. That's simply the nature of competition. If you have confidence in your work, you have nothing to fear, and more importantly, no reason to hate.

To everyone harassing rails..

[August Lilleaas]

..use something different. I don't care what you use, or why you use it, as long as it works for you. And read this blogpost by Gilels Bowkett, which should tell you a thing or two about personal preferences. There will never be an agreement on this.

Re:To everyone harassing rails..

[Anonymous Coward]

"To everyone harassing rails....use something different."

What a brilliant idea. How come nobody thought of that, huh?!

Comment removed

[account_deleted]

Comment removed based on user account deletion

Re:this is fantastic

[Anonymous Coward]

Replying to trolls with something like that just lowers you down to their troll status. Moderation has worked admirably, this time.

Re:this is fantastic

[Anonymous Coward]

instead of sucking linux dicks

What kind of dicks would you recommend then? I once tried sucking a windows dick but I wasn't satisfied with the uptime, and whenever I find an OS X dick there's already another man sucking it. I've honestly been quite satisfied with linux dicks over the years and see no immediate need to start sucking something else, but if you have any good suggestions I'm willing to listen.

Rails 2.0 Guide in English and Spanish

[muchawi]

I've published a guide to Rails 2.0 written by prominent Rails blogger Ryan Daigle. It's available in both English and Spanish as a DRM-free PDF.

Ruby is interesting, but the syntax is awful

[Millenniumman]

Ruby looks interesting in a lot of ways, but the syntax is rather painful. Is there something similar with a more smalltalk like syntax?

Re:Ruby is interesting, but the syntax is awful

[K. S. Kyosuke]

Is there something similar with a more smalltalk like syntax?

Of course there is. Have you ever tried Smalltalk, for instance?

Re:Ruby is interesting, but the syntax is awful

[Millenniumman]

Smalltalk, at least that I've seen, is not a normal programming language. Instead of just typing code in files and compiling/running them, you have a "virtual machine" with its own bizarre gui system.

Re:Ruby is interesting, but the syntax is awful

[K. S. Kyosuke]

Ever tried Smalltalk/X with its pretty efficient Smalltalk->C compiler and a good deal of Unix feel? ;-)

Re:Ruby is interesting, but the syntax is awful

[DrEasy]

You can definitely program in Smalltalk using emacs (or vim or whatever you like), but why would one want to do that? The IDE is part of what made Smalltalk revolutionary in the first place. I don't know if Eclipse has support for Smalltalk, but its ancester, VisualAge, certainly did, and actually contained some Smalltalk code inside. As for frameworks similar to RoR in Smalltalk, there is indeed one. I think it's called Seaside, but I haven't tried it myself (yet).

Re:Ruby is interesting, but the syntax is awful

[Anonymous Coward]

Smalltalk maybe?

Re:Ruby is interesting, but the syntax is awful

[Anonymous Coward]

Try Seaside. It's smalltalk and easier than Rails IMO if you actually understand OO programming. Better yet, there is no crazy dogma and buzz words shoved in your face. Basically, you just code and if you need help, there are people to help you. Novel idea.

It can use a relational database, but why would you? Use an object oriented database, there are many free and commercial that work great with Smalltalk. No more SQL, just Smalltalk 100%. Decades of tested, stable code that other languages try to mimic. It's hilarious to watch all the big announcements about stuff that has been in Smalltalk before many of these Rails guys were born.

Python on Rails... instead..

[zukinux]

I really just prefer Python on Rails as a framework instead of Ruby.
Here's a nice article I've encountered while searching about this on Google few minutes ago :
No Rails For Python

Re:Python on Rails... instead..

[pavera]

Check out django. As that article mentions MVC efforts can become overly restrictive very easily. If you ask me, Ruby on Rails has already crossed that line. django is mvc as well so someday might go down this path, but it hasn't yet.

django provides all of the ease of Ruby on Rails, it is powerful, it provides even more tools than Ruby on Rails in my opinion specifically for web work. And I don't feel like I have handcuffs on when I'm developing in it.

I started building 2 projects in Ruby on Rails ~8 months ago. These were existing PHP systems which had become overly cumbersome and were in serious need of a redesign/rewrite. Rails seemed to provide everything I needed, began porting... got about 30% done and started running into serious roadblocks that were there by design in Rails.... I aborted the porting, and started looking for another framework, found django... the 2 projects are now 100% ported (took less than 1 month each).

django was also significantly easier to set up for production than my experiences with rails (apache? lighthttpd? mongrel? the recommended web server for rails changes every week...) modpython+apache is dead simple to set up and rock solid (apache+rails requires fastcgi which was constantly crashing, unstable, and basically doesn't work)

obviously I'll get flamed for this as RoR has way too many fanboys, but as far as a concise, powerful, well documented, easy to use, flexible, and enjoyable development experience nothing gets close to the last 2-3 months working with django.

Re:Python on Rails... instead..

[randomc0de]

Don't forget the built-in admin... I set our site up as a Django app, and have 2-3 professors able to add/modify content. It took about 2 weekends. And, it's in Python, a far easier language to just pick up and go with than Rails.

Re:Python on Rails... instead..

[clamothe]

I had the same experience as you did, coming from Rails to Django.

Django supports both mod_python, fcgi, scgi, and ajp1.3. Although you're endorsing apache + mod_python, I have found lighttpd + SCGI (use a threaded python instance) to have the best overal performance in single server deployment. I've benchmarked most apache or lighttpd +django hosting scenarios to come to this conclusion :)

Re:Python on Rails... instead..

[pavera]

I'm not surprised that there is a more performant solution, my point was simply that a workable production environment is very easy to set up using standard things that are installed on almost any linux server.

In rails, a production server MEANS jumping through hoops and compiling things and testing, and having things totally broken for days... At least this was my experience.

My main reason for endorsing apache+mod_python is because I know apache pretty much inside and out, I've spent 10 years working with apache web servers, I understand apache. I haven't spent the time to feel comfortable with lighttpd. As I said, I'm sure there is a more performant solution, but there is a basic production level setup that is a couple of apache config lines away. You can't find that in Rails.

So what scales...

[msimm]

For all the talk about ROR's questionable scalability I'm personally interested to hear what people do consider a highly scalable framework? The company I work for uses Fusebox (we are weening our application code off Coldfusion) and are likely going to move to Zend's framework. But I'm looking at working on a personal project and would like a framework that balances accessibility (I'm a fairly new to PHP, I do systems work) with scalability.

I started doing my own research this week so I was excited to see the ROR discussion and hoped it might be enlightening. I know the BBC uses Ruby on Rails at least internally (and apparently a custom Rails-like Perl MVC externally?) and the community support for ROR is excellent (I've been reviewing documentation to help narrow my decision).

Since from what I've read the Zend Framework isn't as accessible (and the documentation seems a bit more high-level) I've been mainly reading about Ruby on Rails, CakePHP, Django, Code Igniter and most recently Symfony.

If Ruby on Rails isn't considered particularly scalable, what is?

Re:So what scales...

[pavera]

I don't think RoR has scalability issues. People say it does, but scaling isn't the issue, it is raw performance that is lacking. And, it isn't Ruby on Rails fault, it is simply Ruby. the Ruby interpreter is slow (2-5 times slower than perl, php, or python interpreters (its about 50-100 times slower than java or c++, but then so are the rest of the interpreted languages).

That being said, a RoR application will need 2-5 times the power behind it to serve the same number of users that a perl, python, or PHP app can handle.

Sure you can set up a RoR app in a cluster and you can make it scale, just like you can with a perl, php, python, java, or c++ app. You're just going to have to do it much sooner with RoR because of the performance issues of the ruby interpreter.

Obviously this isn't an exhaustive comparision, but over at the language benchmark game http://shootout.alioth.debian.org/, there isn't a single benchmark where ruby is faster than python, perl, or php that I could find.

Re:So what scales...

[K. S. Kyosuke]

It might get a bit better quite soon: http://shootout.alioth.debian.org/gp4sandbox/benchmark.php?test=all&lang=yarv&lang2=php

Re:So what scales...

[Anonymous Coward]

Since you ask:

I find Wt (http://www.webtoolkit.eu/wt/) to scale very well, offering a level of abstraction that is vastly higher than most web frameworks, since you do not need to deal with AJAX, a separate comet daemon for server-push, most of the JavaScript mess, XSS troubles and annoyances like fixing browser history and bookmarks when using AJAX or graceful degradation to non-JavaScript browsers, etc...

It hides those details in the same way that Qt hides de details of Win32 or X Windows programming.

Sure, it's C++, but if you are serious about web applications (not just dynamic web pages that consult a database), and given that you are a systems guy, you surely will like it !

Comment removed

[account_deleted]

Comment removed based on user account deletion

Re:Scaling matters if you're Digg. Are you Digg?

[Anonymous Coward]

What an amateur worthless endeavor to build sites that don't scale? All I build is sites that can scale and use languages, databases that are known for scaling well. What do you do the day when you get flooded with visitors? You turn into Facebook or Digg? It is a fact that Ruby (the language alone... is very slow) which just adds to the misery that it doesn't scale well. I am not defending Perl or PHP, but only to give an example of the speed I'm talking about: In many well documented scientific benchmarks you can easily find all over the Internet, Ruby processes requests about twice as slow as both Perl and PHP. I use what ever is the best language for the job (Python,Perl, Java, JSP, PHP, C++, C, ASP,TCL,Awk, cold fusion...etc ) and YOU SHOULD ALWAYS use languages, architectures and technologies that are known to scale well. Otherwise, it can be very expensive to have experts such as OmniTI.com come in to FIX your site to scale. I can guarantee having worked with them before, that they will more than likely throw Ruby out the window and have to recode your app from scratch.

"Done"?

[chelsel]

Referring to software as "Done"... turkeys maybe... but software?!

Re:Scaling matters if you're Digg. Are you Digg?

[Anonymous Coward]

I know that many sites don't need to scale, and so the effort isn't worth it. You fit in that category.

I also appreciate that many sites are high traffic but largely have a read load, meaning many front ends and a bit of caching will be able to scale to thousands of requests per second. For those, Rails will also do fine, but that does not make it scalable.

But what about those few sites that DO actually get thousands of requests per second, and who have a high write load (think thousands of write queries per second). What about those sites that start small using Rails and get hugely popular? Can Rails split the database horizontally, not just add caching? This is what it means to be scalable.

A language is not inherently scalable or not scalable. There's no reason why any of Java, Ruby, PHP or Python are more scalable than the rest. Just some have better frameworks than others which make them more scalable. From everything I've heard, Rails is reasonably fast and can scale reads, but cannot scale writes, which is what matters.

Re:this is fantastic

[neonleonb]

My god I wish I had mod points. That's the funniest thing I've read all day.

Re:Scaling matters if you're Digg. Are you Digg?

[slaingod]

Errata:
Meant to say 100,000 not 100,000k for unique vistors.
This was on a single dual cpu server (2 ghz I think, whatever server beach gives us).

Storing sessions in the database also helps (Rails 2.0 wants to do it client side by default, but I'm not down with that). Memcached for sessions is an obvious big win. Putting 50k files in a directory is never good, is why you don't want to use the default.

We have used multiple servers (3-4) load-balancing before to handle high load, but that was back when we were still using Mongrel, tho it is fairy easy to throw a couple of more servers at the problem.

The value is the content

[heroine]

The language isn't much use if there aren't blogs to fill the websites with content. Don't forget the millions of blogs, diaries, instant messages, home videos, & home photos that really make the current languages valuable.

No

[Synn]

No, it still requires mongrel. And mongrel still doesn't know how to fork or thread.

Re:It's new tech for people who weren't aware of..

[JudicatorX]

That's strange, I remember reading about MVC long before anyone had heard of Ruby...

Comment removed

[account_deleted]

Comment removed based on user account deletion

Comment removed

[account_deleted]

Comment removed based on user account deletion

Slow

[Anonymous Coward]

but Ruby on Rails is not - and isn't intended to be - a framework for redundant distributed DB applications.

That is correct.

Ruby on Rails is a great framework for quickly coding slow websites.

Re:this is fantastic

[donnacha]

Sheer genius, funniest post I've read in ages.

The fact that no-one has modded this hilarious post up only goes to illustrate how broken Slashdot's moderation system is.

Are you building a database or web apps?

[alexhmit01]

If you are building a Web Application for which you have a database simply because you need persistent storage, what you are saying makes a lot of sense. In that case, flat files would also be fine, and your storage mechanism is all about speed, and if MySQL with a SQL front-end gives you speed, great.

If your core information is the database, the opposite is true. The basic CRUD tools that Rails beautifully scaffolds aren't really OO applications, they are basic data sets. You need sets of data, extracted via one or more tables with possible filters, SQL expresses that beautifully. The core of those systems are a set of data that aren't OO. Having a teacher from a set of teachers isn't OO programming just because you've made teachers an object instead of an array of teacher objects (or structs, or whatever).

If you are doing e-commerce sites, the tools for the CRUD administration are WAY more complicated than showing the objects on the site, which may mean that different languages serve the purpose here.

Your issues with DB business logic vs. web layer business logic assumes a single application, and as you scale up, it's not so simple. While object reuse gives a reason to do so, Rails is so tied to it's build your data models with persistence with almost no code that sharing the objects doesn't get you very far. Basically, if you put the logic in Rails land than if you need to build a third party solution that can't be Rails code for whatever reason you have to share out your objects through some web interface. That's not a horrible solution, but it's of questionable value vs. just having it talk to the database. It's one extra layer to monitor and debug.

Regarding vendor lock-in, that's REALLY overstated in databases. The fact is, switching databases for major data applications is non-trivial regardless. For open source "applications" with a data store, the ability to switch from MySQL -> PostgreSQL and back is important, but that's the trivial case... no data in the system, no need for fancy integrity maintenance. If you have even a few dozen gigabytes of data in a PostgreSQL or MS SQL database you can move the data from one to the other, but you'll have to manually update logic.

Once performance matters, you need to optimize for the database that you are in, and flexibility here is over rated. Changing your database schema in a production environment is rather difficult and best to avoid, but people talk about lock-in as though they want to swap databases regularly. Even if you data environment has 200 Stored Procedures, a large number for a small-medium sized database, even if those procedures average 1 man-hours each to rewrite and debug (which is probably reasonable if most are trivial methods to get some abstraction away from the tables), you're still ONLY talking 200 man-hours, which would be 5 man weeks. Even at 10-50 man weeks, it's still less than one quarter for a small DBA team or 2-5 people. So even in the case of vendor lock-in, the rewriting of the procedures, if documented, isn't THAT big a deal, and certainly not a justification for losing ALL the advantages that they can give you.

I'm busy doing a database cleanup operation. Since everything talks directly to the DB tables, through a Rails (though poorly implemented Rails) system, migrating on the live system to something that we want is turning out the be a nightmare. The most likely course of action is going to be building and testing a live transaction that moves ALL the existing tables to another schema, creates views for them in the old schema, with PostgreSQL rules to talk to the new tables, JUST so that chunks of the database can be rebuild at one time.

Had a lot of these trivial operations been done in stored procedure functions, the migration would be pretty painless, because we'd create new tables, rewrite the sprocs to talk to the new tables, then bring the data in behind us.

The tools for the Web Apps are better, but that depends on the environment being suitabl

Re:PFFT!

[Wiseman1024]

Albeit with a shitty syntax and a total lack of style, Ruby's semantics are very similar to LISP. It's the toy languages with toy abstractions that force specific paradigms up your ass, such as Java, what you should be bashing, fellow Knight of the Lambda Calculus.

Please, not Zope

[Wiseman1024]

Zope is Java for Python. It turns an agile, powerful, abstract programming language into a "best-practices enterprise-grade mission-critical turnkey low TCO early ROI scalable five-nines availability professional business solution".

If you're doing Python, for good or for bad you have a wide range of frameworks available. From the lower level ones, like web.py or just using CGIs, to the Rails-like ones such as Django and TurboGears, including less common ones such as CherryPy and Quixote. There's no need to get "ENTEPRISE" in Python.

Re:Please, not Zope

[rbanffy]

I too feel Z3 is a bit too much on the configuration over convention side.

Grok seems promising - it makes debeloping Zope 3 stuff quite fun. You really should try it.

And Django is very interesting, but it has that "relational thing" Zope has not, at least not in the ZODB. I like the object nature of the ZODB when objects make more sense. You know, there is more to life than tables.

Wrong. Not anymore.

[Qbertino]

Rubyonrails.org is written in PHP. If anything, this "proves" that PHP doesn't scale.

It was running on PHP until about 6 months ago. Now it's driven by Rails. So, if anything. RoR Org folding proves that Rails doesn't scale. But it actually doesn't prove that much. Maybe the Rails folks run it on an old 286?

To be honest: I think PHP has a better chance of scaling well than Ruby, because it's more mature, has more options for acceleration of server-side code and usually runs as Apache mod which gives it yet more options for runtime performance optimization. Yahoo Bookmarks (built with Symfony(PHP)) handles the load quite well. I don't know of a Rails site of that size.

Then again, if you're really interested you can get any FW to handle large loads, once you've optimized it's bottlenecks. But there PHP has another advantage: An existing bunch of mature tools for profiling and debugging, at least half of them Open Source. Which is why I prefer it over Ruby or even a more interesting Python, which has the most sane syntax of all. Imho.

There's a more generic saying on this:

[Qbertino]

"If you have a scaling problem, you don't have a problem."

Which basically means if you've got 200 000 hits a day and your existing setup is folding under the load, you've found a glory hole on the webbernet. And you're likely to find the funding required to scale the site - even if that means moving to an entirely new technology alltogether.

RoR 2.0, Web 2.0, Hype 2.0

[jdickey]

Rails is fine if you want to do another Basecamp or similar 37signals-type project. It's even better if you want to whip out an amazing number of structurally identical, common-organization Hype 2.0 apps. But just ask the folks at Twitter how well its database access scales to meet demand - it almost put them out of business. Several times. Rails is a poster child for the perils of an application-specific language being used as a general-purpose one.

A lot of things that I read obout it remind me of Python in the early days - but I don't recall Guido van Rossum being so Great Leader-ish, and there's also the difference that Python actually can be used for an amazing range of applications. Ruby can too; it's a beautiful language - until you cut its balls off with Rails.

Re:RoR 2.0, Web 2.0, Hype 2.0

[DragonWriter]

But just ask the folks at Twitter how well its database access scales to meet demand - it almost put them out of business.

Or, as the case may be, not. See, any of the later discussion of the issue after the first round of back and forth, such as this piece. Scaling is a problem, period, but there is little indication from the experience Twitter had (once they diagnosed their problems) that Rails is a particular source of the problems they were having.

A lot of things that I read obout it remind me of Python in the early days - but I don't recall Guido van Rossum being so Great Leader-ish

How, precisely, is whoever you are comparing GvR too (DHH?) being "Great Leader-ish"?

A lot of things that I read obout it remind me of Python in the early days - but I don't recall Guido van Rossum being so Great Leader-ish, and there's also the difference that Python actually can be used for an amazing range of applications. Ruby can too; it's a beautiful language - until you cut its balls off with Rails.

How, exactly, does Rails limit what you can do with Ruby? There are certainly things that you can do with Ruby that Rails doesn't make any easier, but that hardly merits your rather hyperbolic description.

Merb?

[corifornia2]

Maybe you should give MErb a try? Merb, more ruby, less rails

Re:Scaling matters if you're Digg. Are you Digg?

[evil_breeds]

I love seeing numbers like this attached to a real use case. Have you written this up somewhere, or do you have some links that identify other best practices in Rails? A thought-out, tested look at Rails best practices is sorely missing from the RoR scene.

You have it backwards.

[Anonymous Coward]

"web guys" are the only ones interested in rails. For the average PHP coder, rails provides structure and best practices that they are too inexperienced to use otherwise. To a "software engineer", rails is just a poorly documented, buggy, slow implimentation of the normal code structure they have been using all along. We see rails and say "so? My code was always MVC, and its much cleaner than rails, who needs rails?".

Perl is not simple to deploy on Apache either...

[gwolf]

Of course, if you mean the occasional CGI, I agree with you. But some time ago, I wrote a quite large conference management system in Perl, using mod_perl. And... Well, I'm starting a complete rewrite in Rails. Why? Because, while it works, adoption was practically nonexistant. And I do want more people to use it.
It is far simpler to install a Rails application on Mongrel and redirect/proxy to it from Apache (or even to use FCGI, which I don't really like) than to set up a mod_perl app.

Re:Scaling matters if you're Digg. Are you Digg?

[Slashdot Parent]

This is such a non-issue, I cannot believe it. If you can scale JAVA!!!... You know what I mean. This is actually a pretty severely ignorant statement. The year is no longer 1998, and modern JVMs perform very similarly to native code for most applications.

True story: a client had a perl script to slice and dice a lot of log file data. This is bread and butter for perl, exactly what it was meant to do. The problem was, the amount of data was growing, and the perl script was taking too long to complete.

I rewrote the perl script in Java using the exact same logic, regular expressions, everything. Just translated statement by statement from perl to Java. The Java program completed 10 times more quickly than the perl script, and that was with zero performance optimization.

Welcome to 2007.

Delegation and static typing?

[tepples]

Just create a MyDateTime class, and delegate all the built-in methods of the native date-time to the native date-time, and then add your own custom extensions. Then use your MyDateTime.

So what interface does MyDateTime implement? Can an object of type MyDateTime be passed to methods that take a native date-time as an argument?

This sort of delegation works wonderfully in Python and other languages with a duck type system, where an interface (or "protocol") is just a set of method names and the behaviors expected of them. But in languages with static typing, classes must state by name that they implement an interface, and there is often no way to state that a class happens to implement the same interface as another class unless the interface itself is given a name and other methods are aware of the interface. For example, in the Java language, java.lang.String is final so your classes can't extend it. But like several other aspects of the design of Java, this presents a roadblock because methods throughout the Java class library require exactly a java.lang.String object and will not accept an instance of any other class that implements java.lang.CharSequence.

Chinese generation names

[tepples]

what parent gives 5 of their children the same first name?

Chinese parents.

But seriously, even if you invert the name from Chinese order (last first middle) into Western order (first middle last), you'll find that often, what corresponds to the Western "first" name is shared among siblings. See "Generation name" on Wikipedia.

Re:Scaling matters if you're Digg. Are you Digg?

[Fnkmaster]

Expressiveness is not the same as readability, to me, in fact it's almost antithetical to it. Perl is very "expressive" in that you can accomplish a huge amount in a very terse chunk of code, but it's highly unreadable if you do so.

In general, @-signs make me want to puke. I don't like sigil-weirdy things in front of variable names. What's wrong with just using "this" if you really need to clarify scope? Frankly, you should be writing code that *doesn't need* scope clarification so often that shortening scope-resolution to a single character seems like a good idea.

Basically, I just prefer Python or PHP aesthetically to Ruby, especially if I have to read somebody else's code. Or Java, which while often overly verbose, is very readable, though not terribly expressive. The upside of that is I've almost never seen Java source code that I couldn't pick apart pretty quickly, or a Java library that I couldn't pick up and use immediately, because the language just is not terribly dense in information content.

I've only given Ruby a cursory look-over, so I might feel differently if I spent some time with it, but it just doesn't "look" right to me.

Comment removed

[account_deleted]

Comment removed based on user account deletion