2 ms·

I wrote this post for beginners and most of them never read the docs before hacking on production code. Lazy querysets aren't dangerous but it's always best to

I wrote this post for beginners and most of them never read the docs before hacking on production code. Lazy querysets aren't dangerous but it's always best to evaluate them before rendering anything in order to avoid secret SQL queries. Many developers never run EXPLAIN, so these extra queries go unnoticed until your server crashes during Black Friday. I don't see why your database table needs to encapsulate the app's name. Most apps get rewritten at some point but databases can live for centuries. Why couple code with your data? Maybe I should be more humble to please sensitive people like you but no thanks. If a simple blog post hurts your feelings then you need to professional help.

Nextgrid 5y ago
> I don't see why your database table needs to encapsulate the app's name. Because Django assumes that in most cases your DB will be primarily (only?) be used by the Django app. In my experience that is true of most startups and early-stage projects, and the default names have never been a blocker even when you start giving others access to that database (hopefully with a read-only user account). > Most apps get rewritten at some point but databases can live for centuries. You can rename tables when this becomes needed. I don't think it's worth wasting time doing so at the beginning (you could equally argue that whatever name you pick manually isn't going to be suitable in the future either, so a rename will be needed either way). > Why couple code with your data? Renaming tables doesn't realistically address that coupling by any means.