3 ms·

There are so many incompatible needs for databases that most DB wrappers of any kind rarely make sense except when prototyping. And database wrapper authors hav

There are so many incompatible needs for databases that most DB wrappers of any kind rarely make sense except when prototyping. And database wrapper authors have a tendency to cater to lowest common denominator of features so that they can treat all databases the same, which is going even further in the wrong direction. Choosing a database requires learning what your requirements are, learning what the candidates are, and when you pick one, learning how to use it correctly. People and companies rarely seem to do all of these steps.

ordu 7y ago
The "write-raw-SQL-with-raw-strings" approach has one serious issue -- sql-injections. Some people argue that it is not so hard to filter strings before concatenating them into sql-query, but I know also people who argue that it is not so hard to write C code and to not introduce bugs around NULL and wild-pointers, one just needs to be careful. I, personally, do not believe that strategy "be careful" can work reliably here. I cannot imagine work with SQL without query builder, which introduces type checks and conversions, and escapes strings when needed. ORM is an optional thing, but it is nice to have some layer that maps rows into structs and vice-versa. With dynamically typed scripts it doesn't matter: in any case you would get a hashtable (the only difference is a syntax used), but with compiled language and static typing I feel some uneasiness when using slow hash table mapping instead of blazingly fast struct field access. And the tooling can help to declare that structs statically.
- revvx 7y ago
  > The "write-raw-SQL-with-raw-strings" approach has one serious issue -- sql-injections. Nobody has advocated writing "raw SQL with raw strings" in years. The valid way of using Raw SQL is using prepared statements and parametrized queries. This method will protect you from SQL injection, will handle most issues with type/conversions and the queries are cacheable, so it's fast too. Parametrization is handled by the database itself (not the specific driver), so it is battle tested. https://stackoverflow.com/questions/8263371/how-can-prepared-statements-protect-from-sql-injection-attacks https://stackoverflow.com/questions/8263371/how-can-prepared...
  - ordu 7y ago
    > Nobody has advocated writing "raw SQL with raw strings" in years. It is an overstatement. Every time I look into some random PHP code I see there raw SQL with raw strings. Maybe it is just me being "lucky"? By the way, the thread starter comment was mentioned it, I got phrase from it.
    - philwelch 7y ago
      “Random PHP code” might be the operative phrase there.

ordu 7y ago

The "write-raw-SQL-with-raw-strings" approach has one serious issue -- sql-injections. Some people argue that it is not so hard to filter strings before concatenating them into sql-query, but I know also people who argue that it is not so hard to write C code and to not introduce bugs around NULL and wild-pointers, one just needs to be careful. I, personally, do not believe that strategy "be careful" can work reliably here. I cannot imagine work with SQL without query builder, which introduces type checks and conversions, and escapes strings when needed. ORM is an optional thing, but it is nice to have some layer that maps rows into structs and vice-versa. With dynamically typed scripts it doesn't matter: in any case you would get a hashtable (the only difference is a syntax used), but with compiled language and static typing I feel some uneasiness when using slow hash table mapping instead of blazingly fast struct field access. And the tooling can help to declare that structs statically.

revvx 7y ago
> The "write-raw-SQL-with-raw-strings" approach has one serious issue -- sql-injections. Nobody has advocated writing "raw SQL with raw strings" in years. The valid way of using Raw SQL is using prepared statements and parametrized queries. This method will protect you from SQL injection, will handle most issues with type/conversions and the queries are cacheable, so it's fast too. Parametrization is handled by the database itself (not the specific driver), so it is battle tested. https://stackoverflow.com/questions/8263371/how-can-prepared-statements-protect-from-sql-injection-attacks https://stackoverflow.com/questions/8263371/how-can-prepared...
- ordu 7y ago
  > Nobody has advocated writing "raw SQL with raw strings" in years. It is an overstatement. Every time I look into some random PHP code I see there raw SQL with raw strings. Maybe it is just me being "lucky"? By the way, the thread starter comment was mentioned it, I got phrase from it.
  - philwelch 7y ago
    “Random PHP code” might be the operative phrase there.