4 ms·

>>Queries have to be passed over the wire as strings, so your application will spend a significant chunk of its time building them... or else you get to deal wi

>>Queries have to be passed over the wire as strings, so your application will spend a significant chunk of its time building them... or else you get to deal with the db-specific and per-connection quirks of prepared statements... Or you could use stored procedures. Think of it as making your RDBMS into a microservice, if you like. >>I don't know why there aren't RDBMSes without better query languages and schema definition languages Huh... I always thought SQL was pretty straightforward for most cases. It only gets really arcane when you get into advanced cases (eg, recursive queries) and/or vendor extensions. It does take a bit of a mental shift, but no more so than imperative-style to functional-style, IMO. There are certainly tradeoffs to using an RDBMS. But I think a lot of people jump to the conclusion that they have a big-data situation when they really don't. I also think a lot of people underestimate the value of very easy ad-hoc querying and already-solved backup/restore.

lmm 10y ago
> Or you could use stored procedures. Think of it as making your RDBMS into a microservice, if you like. The trouble is testability, versioning, deployment, and SQL just not being a pleasant language for expressing business logic. And the lack of a library ecosystem. And poor IDE support. And...
- breischl 10y ago
  >>SQL just not being a pleasant language for expressing business logic No kidding - don't do that. Sprocs are great to present a query interface and avoid sending queries over the wire every time. They can be handy to decouple the actual storage architecture from the query interface, so you can do tricky stuff in SQL without screwing up the clients. That doesn't mean you should stick your business logic in there. >>testability, versioning, deployment... library ecosystem... And how would any of those problems be solved by using raw SQL strings or a document DB? That just moves the problems back into the schema or the data, where it's even harder to deal with. >>poor IDE support So your code editor has a better IDE for SQL? Or are we talking about a document DB? I haven't seen any of them that were anywhere close to SSMS.
  - lmm 10y ago
    > And how would any of those problems be solved by using raw SQL strings or a document DB? That just moves the problems back into the schema or the data, where it's even harder to deal with. I'm arguing for using a non-SQL interface. Either a structured binary query protocol (which leaves you shipping a lot of data around sure, but at least removes the constructing-and-parsing SQL overhead), or a map-reduce style setup where you can run your queries where the data is but in a first-class programming language.
    - breischl 10y ago
      It seems to me that you're advocating changing implementation details (binary query protocol instead of SQL, map-reduce queries instead of sprocs) and claiming that it is somehow fundamentally different. But I don't see how that would be the case. How is a binary query protocol fundamentally different than calling a sproc? How is a map-reduce job in Javascript any different on the attributes you mentioned than ad-hoc SQL or a sproc? Obviously map-reduce is a fundamentally different approach to data processing, but it seems to have similar traits in regards to source control, testability, etc.
      - lmm 10y ago
        Binary query protocol is just a tweak, but it's a tweak that most RDBMSes are missing, and it matters for some workloads. Switching to a model where you supply your own map-reduce or pipeline is a real shift, I think, from the DB as a framework that manages querying for you to more of a library/toolkit you can use to write your own computations. The indexed tables model is an incredibly effective compromise, but it's still a compromise - if you know specifically what you need to do, you can do it better. Running a first-class programming language with full support for usual programming language tools is a major difference for developability, testability, libraries and so on. Deployment model depends on the datastore - plenty of non-SQL ones have room for improvement here - but I think the traditional RDBMS still has the worst of it.
        breischl 10y ago
- dragonwriter 10y ago
  > > Or you could use stored procedures. Think of it as making your RDBMS into a microservice, if you like. > The trouble is testability, versioning, deployment, and SQL just not being a pleasant language for expressing business logic. Most of those, to the extent they are valid, are trouble with using stored procs in SQL for that purpose, but most RDBMSs support stored procs in languages other than SQL.
  - lmm 10y ago
    Testability, versioning, deployment, IDE support and library support are still very much issues with non-SQL stored procedures.

lmm 10y ago

> Or you could use stored procedures. Think of it as making your RDBMS into a microservice, if you like. The trouble is testability, versioning, deployment, and SQL just not being a pleasant language for expressing business logic. And the lack of a library ecosystem. And poor IDE support. And...

breischl 10y ago
>>SQL just not being a pleasant language for expressing business logic No kidding - don't do that. Sprocs are great to present a query interface and avoid sending queries over the wire every time. They can be handy to decouple the actual storage architecture from the query interface, so you can do tricky stuff in SQL without screwing up the clients. That doesn't mean you should stick your business logic in there. >>testability, versioning, deployment... library ecosystem... And how would any of those problems be solved by using raw SQL strings or a document DB? That just moves the problems back into the schema or the data, where it's even harder to deal with. >>poor IDE support So your code editor has a better IDE for SQL? Or are we talking about a document DB? I haven't seen any of them that were anywhere close to SSMS.
- lmm 10y ago
  > And how would any of those problems be solved by using raw SQL strings or a document DB? That just moves the problems back into the schema or the data, where it's even harder to deal with. I'm arguing for using a non-SQL interface. Either a structured binary query protocol (which leaves you shipping a lot of data around sure, but at least removes the constructing-and-parsing SQL overhead), or a map-reduce style setup where you can run your queries where the data is but in a first-class programming language.
  - breischl 10y ago
    It seems to me that you're advocating changing implementation details (binary query protocol instead of SQL, map-reduce queries instead of sprocs) and claiming that it is somehow fundamentally different. But I don't see how that would be the case. How is a binary query protocol fundamentally different than calling a sproc? How is a map-reduce job in Javascript any different on the attributes you mentioned than ad-hoc SQL or a sproc? Obviously map-reduce is a fundamentally different approach to data processing, but it seems to have similar traits in regards to source control, testability, etc.
    - lmm 10y ago
      Binary query protocol is just a tweak, but it's a tweak that most RDBMSes are missing, and it matters for some workloads. Switching to a model where you supply your own map-reduce or pipeline is a real shift, I think, from the DB as a framework that manages querying for you to more of a library/toolkit you can use to write your own computations. The indexed tables model is an incredibly effective compromise, but it's still a compromise - if you know specifically what you need to do, you can do it better. Running a first-class programming language with full support for usual programming language tools is a major difference for developability, testability, libraries and so on. Deployment model depends on the datastore - plenty of non-SQL ones have room for improvement here - but I think the traditional RDBMS still has the worst of it.
      - breischl 10y ago
dragonwriter 10y ago
> > Or you could use stored procedures. Think of it as making your RDBMS into a microservice, if you like. > The trouble is testability, versioning, deployment, and SQL just not being a pleasant language for expressing business logic. Most of those, to the extent they are valid, are trouble with using stored procs in SQL for that purpose, but most RDBMSs support stored procs in languages other than SQL.
- lmm 10y ago
  Testability, versioning, deployment, IDE support and library support are still very much issues with non-SQL stored procedures.