6 ms·

Totally with you on the DB encryption but I'm not sure about your comments on prepared statements >That is an extraordinarily inefficient and costly way to dev

by xupybd 10y ago

Totally with you on the DB encryption but I'm not sure about your comments on prepared statements >That is an extraordinarily inefficient and costly way to develop. The correct way to protect against SQL injection is to use a framework/driver which guarantees escaping and to be cautious about what you allow into queries. I've always found using only prepared statements is feasible and justifiable. What is about using them that adds to cost and inefficiency? Prepared statements are not a silver bullet. Somethings like limit statements in mysql are very hard to do with prepared statements but for the most part it's a good rule of thumb.

sho 10y ago
My apologies - my brain focussed on "stored procedures" and that's what my rant was addressing. Prepared statements are great and I'd use them whereever possible - totally agreed.
- ams6110 10y ago
  Nothing wrong with stored procedures. Like anything else, they might not be right for every application.
  - cookiecaper 10y ago
    The image of sprocs continues to suffer from "store all application logic in the database" syndrome, which was all the rage in the early and mid 00s before APIs started to take off. There's nothing necessarily inherently wrong with that approach, but most people have gravitated away from it. DBA/dev split probably had something to do with it.
    - e12e 10y ago
      I'd venture the real reason is many devs know too little of normalisation, data structure and structured data. Somehow a mess of structures/data objects paired with functions working on these objects - with only ad-hoc ways of enforcing foreign key relationships are seen as "easier", and "better for maintenance" than leveraging an actual (relational) database management system. Sure it's more fun writing functions than thinking about data integrity - but the vast number of applications are concerned with managing structured information: from scenes in a game that could be interlocking state-machines to the more mundane user/message pairs or similar. Design is eschewed for prototyping - but then the prototype is kept as the production system, rather than as a basis for design of a better (simpler) system.
      - cookiecaper 10y ago
        If document databases like MongoDB have taught us anything, it's that developers hate any sort of data organization, which is ridiculous and ironic since most of their day-to-day is about manipulating data. Mongo is popular because it allows the developer to stuff a value without thinking about its structure and role, generally leading to utter disaster further down the road. I do think the biggest problem is that it brought everything into the DBA's turf, and made it too difficult for devs to do their jobs without meddling. As long as there is a dev/DBA organizational dichotomy, there will have to be a structural dichotomy in the software (cf. Conway's Law).
        e12e 10y ago
        I wonder how many developers would consider using the filesystem as a document store bad practice, but at the same time be happy using mongodb. It's odd that with the rise of solid, free rdbms' like postgresql (and the current generation of mysql forks) - the general reaction among developers hasn't been to realize that 99% of systems are/should be data-first/data centric - but rather a stubborn struggle to pretend their language supports transaction-guaranteed persisted runtime/memory -- without actually using a real object database like zoodb (for python) or gemstone.
  - Terr_ 10y ago
    IMO you should either (A) avoid customizing the database and treat it as a relatively commodity data store or (B) treat it as its own service with its own developers (DBAs) that just happens to use an SQL connection as its network interface. Some of the most horrible systems are when people just went half-way, and you've got logic randomly scattered between two systems with two programming languages etc.
- wglb 10y ago
  Stored procedures offer no inherent protection.
  - flukus 10y ago
    Often they will make the problem worse if you're doing string concatenation to create dynamic queries in a stored proc.
cookiecaper 10y ago
Most (good) ORMs/drivers will be transparently using prepared statements anyway. It explicitly informs the DB "this is unsafe user input" instead of trying to approximate that message with escapes.

by xupybd 10y ago

sho 10y ago

My apologies - my brain focussed on "stored procedures" and that's what my rant was addressing. Prepared statements are great and I'd use them whereever possible - totally agreed.

ams6110 10y ago
Nothing wrong with stored procedures. Like anything else, they might not be right for every application.
- cookiecaper 10y ago
  The image of sprocs continues to suffer from "store all application logic in the database" syndrome, which was all the rage in the early and mid 00s before APIs started to take off. There's nothing necessarily inherently wrong with that approach, but most people have gravitated away from it. DBA/dev split probably had something to do with it.
  - e12e 10y ago
    I'd venture the real reason is many devs know too little of normalisation, data structure and structured data. Somehow a mess of structures/data objects paired with functions working on these objects - with only ad-hoc ways of enforcing foreign key relationships are seen as "easier", and "better for maintenance" than leveraging an actual (relational) database management system. Sure it's more fun writing functions than thinking about data integrity - but the vast number of applications are concerned with managing structured information: from scenes in a game that could be interlocking state-machines to the more mundane user/message pairs or similar. Design is eschewed for prototyping - but then the prototype is kept as the production system, rather than as a basis for design of a better (simpler) system.
    - cookiecaper 10y ago
      If document databases like MongoDB have taught us anything, it's that developers hate any sort of data organization, which is ridiculous and ironic since most of their day-to-day is about manipulating data. Mongo is popular because it allows the developer to stuff a value without thinking about its structure and role, generally leading to utter disaster further down the road. I do think the biggest problem is that it brought everything into the DBA's turf, and made it too difficult for devs to do their jobs without meddling. As long as there is a dev/DBA organizational dichotomy, there will have to be a structural dichotomy in the software (cf. Conway's Law).
      - e12e 10y ago
        I wonder how many developers would consider using the filesystem as a document store bad practice, but at the same time be happy using mongodb. It's odd that with the rise of solid, free rdbms' like postgresql (and the current generation of mysql forks) - the general reaction among developers hasn't been to realize that 99% of systems are/should be data-first/data centric - but rather a stubborn struggle to pretend their language supports transaction-guaranteed persisted runtime/memory -- without actually using a real object database like zoodb (for python) or gemstone.
- Terr_ 10y ago
  IMO you should either (A) avoid customizing the database and treat it as a relatively commodity data store or (B) treat it as its own service with its own developers (DBAs) that just happens to use an SQL connection as its network interface. Some of the most horrible systems are when people just went half-way, and you've got logic randomly scattered between two systems with two programming languages etc.
wglb 10y ago
Stored procedures offer no inherent protection.
- flukus 10y ago
  Often they will make the problem worse if you're doing string concatenation to create dynamic queries in a stored proc.

cookiecaper 10y ago

Most (good) ORMs/drivers will be transparently using prepared statements anyway. It explicitly informs the DB "this is unsafe user input" instead of trying to approximate that message with escapes.