naelyn

> I suspect most users copy/paste anyway.

Some forms disable the paste action in the second box to force you to type it again (to avoid copying an error).

github: naelyn

Coupling queries to the database (stored procedures) instead of to the code that uses them (inlined queries) seems like a recipe for deployment headaches. Especially if you're deploying new code (with new queries) every 2-4 days without downtime.

This approach only makes sense in one of two situations:

1. Ivory Tower DBAs run your company and tell developers "no" at every turn. (sad)

2. Your engineering team makes changing queries hard because they can't hire any developers who know anything about your underlying database platform internals. (also sad)

So you're recommending writing a stored procedure for this?

SELECT COUNT(*) FROM tblposts

I don't agree with prefixing tables with "tbl" to distinguish them from views, but I do agree with the general notion of using the prefix for any "table-like" entity in a database.

If you work with a growing codebase that slowly falls into the (popular) antipattern of DatabaseAsIntegrationPoint, you will end up with dozens of programs spread out over multiple repositories all interacting with some shared tables (not ideal, but it happens).

If you named your tables something like "posts" then I _guarantee_ that if you grepped your entire repository for "posts" that you are going to find an awful lot of false positives in variables and class names. OTOH if you named it "tblposts" then it's far more likely to be a globally unique string identifier.

Why would you need to grep the codebase for a table name you ask?

* prerequisite to a non-additive table ALTER that might have unintended side effects

* prerequisite to trying to undo the carnage of DatabaseAsIntegrationPoint