3 ms·

I tend to insist that database tables are collections of global variables, and the worst kind of global variables because they're persistent (reboot won't fix t

I tend to insist that database tables are collections of global variables, and the worst kind of global variables because they're persistent (reboot won't fix them), they often affect multiple application instances at once, and application compilers can't help you verify them because they're usually in strings. Stored procedure languages have a little bit of an advantage here, but there are so many disadvantages that it's hard to recommend them. Your best bet when writing SQL in strings is make it "greppable". Naming a table "user" is very convenient until someone asks, "What will be affected by this change to the user table?" and you're stuck with needles in a haystacks. Tossing in a tiny prefix e.g. "tblUser" will annoy some people but then your signal-to-noise is ideal. But yeah, concatenating bits and pieces of text together into queries can rapidly escalate out of control without a conservative/judicious approach.

_a_a_a_ 3y ago
> I tend to insist that database tables are collections of global variables, and the worst kind of global variables because they're persistent (reboot won't fix them), they often affect multiple application instances at once, and application compilers can't help you verify them because they're usually in strings This is so ridiculous it hurts > Tossing in a tiny prefix e.g. "tblUser" will annoy some people but then your signal-to-noise is ideal. just no.
- kerblang 3y ago
  Note the lack of supporting argument
  - _a_a_a_ 3y ago
    If you can explain to me how these 'global variables' can be somehow made local or somehow more restrictive and still be useful, I'd be interested. If you can equally explain to me why you want the database to clear the variables on reboot (i.e. destroy all that useful information which databases are designed to preserve, the 'D' in ACID), please do. If you can explain also how they can not "often affect multiple application instances at once" and yet be useful to multiple application instances at once (this being a central part of database functionality) I'd be interested.

_a_a_a_ 3y ago

> I tend to insist that database tables are collections of global variables, and the worst kind of global variables because they're persistent (reboot won't fix them), they often affect multiple application instances at once, and application compilers can't help you verify them because they're usually in strings This is so ridiculous it hurts > Tossing in a tiny prefix e.g. "tblUser" will annoy some people but then your signal-to-noise is ideal. just no.

kerblang 3y ago
Note the lack of supporting argument
- _a_a_a_ 3y ago
  If you can explain to me how these 'global variables' can be somehow made local or somehow more restrictive and still be useful, I'd be interested. If you can equally explain to me why you want the database to clear the variables on reboot (i.e. destroy all that useful information which databases are designed to preserve, the 'D' in ACID), please do. If you can explain also how they can not "often affect multiple application instances at once" and yet be useful to multiple application instances at once (this being a central part of database functionality) I'd be interested.