Re:The SQL Trap
by patio11 on Monday June 22, 2009 @10:25PM
(#669752)
Coming from a Java & Rails background, with my SQL being non-existent as of 2 years ago and only fair to middling today, I'd have to disagree with that for anything but trivial one-day apps. (And with SQLite around as an option I'd be reluctant even then.)
You can use Rails for simple apps without learning SQL or worrying about your database's internal black magic. It is about as simple as @user = User.find(id) -- you don't have to worry about what poor animal had to have its entrails removed to get that record.
You also didn't have to:
1) implement a parser (which is going to break the first time you add an I-can't-believe-its-not-a-column)
2) write a migration framework (so that you can port your data files when you break your parser)
3) deal with simultaneous access (which, lets be honest, you're going to either ignore or whip up an implementation of locks which is exactly as buggy as every other programmer's implementation of locks which is why locks are right up there with crypto in the pantheon of Here Be Dragons, Use The Library)
4) build your own structure for separating your I/O from your application logic (which will asymptotically approach ActiveRecord, except with less features and more suck)
5) do a rewrite and/or significant rearchitecturing when you eventually are forced to move up to a database
You can use Rails for simple apps without learning SQL or worrying about your database's internal black magic. It is about as simple as @user = User.find(id) -- you don't have to worry about what poor animal had to have its entrails removed to get that record.
You also didn't have to:
1) implement a parser (which is going to break the first time you add an I-can't-believe-its-not-a-column)
2) write a migration framework (so that you can port your data files when you break your parser)
3) deal with simultaneous access (which, lets be honest, you're going to either ignore or whip up an implementation of locks which is exactly as buggy as every other programmer's implementation of locks which is why locks are right up there with crypto in the pantheon of Here Be Dragons, Use The Library)
4) build your own structure for separating your I/O from your application logic (which will asymptotically approach ActiveRecord, except with less features and more suck)
5) do a rewrite and/or significant rearchitecturing when you eventually are forced to move up to a database