I think it's extremely hard to appreciate both the advantages and
disadvantages of a framework if you haven't done a bunch of stuff both with
and without one.  If you want to be a great developer you do need to know
how to do stuff at a low level, no question.  But for most developers and
most projects, I strongly believe you're better off using a framework even
if you are an expert.  Tim can be at least as productive writing PHP by hand
as I can using Django, but most of us can't be Tim.  Most of us need to
exploit every unfair advantage and shortcut we can find.

For a beginner/intermediate developer, not having to know or think too much
about SQL is a huge advantage, conceptually and practically.  It can
actually lead to *better* code.  You can be totally ignorant of SQL
injection issues and be just fine using Rails or Django.  That's certainly
not true if you're working at a lower level -- where you have to be both an
expert and very careful not to make a mistake.  And I'm unconvinced writing
SQL by hand teaches you about the limitations of MySQL any better than using
a framework -- writing SQL by hand does not automatically make you a good
database administrator.  (Heck, being a good DBA does not automatically make
you a good MySQL administrator).  In some cases if you're not an expert the
net result of doing it by hand may actually be worse, as I'm willing to bet
that the person that wrote the framework's database interface knows all
about the limitations of MySQL, and its code has been tested in the real
world by thousands of users.  It's all about getting people smarter than you
to write and test as much code as possible for you.

When there are performance issues, the process of dealing with them is
pretty much the same both ways -- look at the queries being run and figure
out where the troublesome spots are and optimize them.  A framework can
actually make that easier rather than harder -- you can log all the SQL run
on a page and how long it took by changing one config file and go from
there.

But concentrating too heavily on the SQL/ORM aspect misses all the other
things that frameworks do.  Even if you are a database expert, you should
still use a framework most of the time in my book.  Nobody can be an expert
on everything.  You shouldn't have to be an expert on XSS, CSRF or SQL
injection to be protected against them.  You shouldn't have to be an expert
on character sets and encodings to have your app handle them right.  You
shouldn't have to start from scratch to add standard boilerplate stuff like
an admin interface or RSS or comments or internationalization to your
project.

I'm not saying you shouldn't be wary of the things that a framework (or any
tool) hides from you, of course.  But in my experience the things that a
framework will save you from (like getting hacked because you forgot to
sanitize some input data in one tiny little place) far outweigh the
downsides, and the time you save by doing as little from scratch as possible
can be spent becoming a MySQL guru if and when you need to.  Or you can bail
on MySQL if it becomes a problem and switch to a better DBMS.  You can do
that without changing any of your code if you use a good framework because
the database layer is totally abstracted.  I wish we could do that at
LibraryThing.

But to answer the original question, I'd recommend Django.  Using Django to
supply a simple CRUD interface by no means rules out doing the interesting
part of the project however you want to [1].  We have stuff at LibraryThing
where the front end is PHP (written by hand) and the back end/admin
interface is Django.  It works great.  And Django (especially with the newly
revamped admin code) provides a far better and more powerful admin interface
than CodeIgniter or others, in my book.

--Casey

[1] http://jeffcroft.com/blog/2006/jul/14/django-admin-your-php-app/


On Wed, Jul 30, 2008 at 8:07 AM, Tim Spalding <[log in to unmask]> wrote:

    This gets religious quickly, but, in my experience, programmers who
    learn on a framework miss out on their understanding of database
    necessities. They may not matter much when you have a low-traffic,
    low-content situation, but as your traffic and data grow you're going
    to want an understanding of how MySQL optimizes queries, what's
    expensive and what's not, and so forth. Although anyone can learn
    anything, experience is the best teacher, and, in my experience,
    frameworks encourage you to avoid that experience.

    For example, the Ruby programmers I've worked with have been unaware
    that MySQL only uses one index per table per select, causing them to
    index far more than they need, how joins work across different MySQL
    data types, the advantages of ganging your inserts together, etc. This
    stuff adds up fast.

    Of course, the same arguments could be leveled against PHP in favor of
    C, against C in favor of assembly, etc.. Abstraction always has merits
    and demerits.

    Tim