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