4 ms·

There's nothing terribly complicated about recursive queries and common table expressions, and for the use cases in which they're commonly used (hierarchical da

There's nothing terribly complicated about recursive queries and common table expressions, and for the use cases in which they're commonly used (hierarchical data being one of those) they perform significantly better than all of the popular SQL alternatives in almost every case.

btilly 13y ago
I was referring to putting business logic in your database, and not any particular query technique.
- jeffdavis 13y ago
  Sometimes it just saves you huge amounts of time and code to do something in the database though. For instance, if you need to join against a remote data source, you can: 1. Write a bunch of code to pull the data from both sources and join it in the application. You have to pick a join algorithm at the beginning, and if your data changes you may need to rewrite it later. 2. Add a remote table in the database and just do the join there. The database can use statistics to pick a join algorithm for you. I'm sure there are cases where you'd pick #1. But in many cases, the database offers a feature that allows you to implement a solution and call it "done" in minutes or hours where an application-based solution would drag on for days or weeks and carry a larger maintenance burden.
  - btilly 13y ago
    Please go to https://news.ycombinator.com/item?id=5934136 https://news.ycombinator.com/item?id=5934136 and look at the final paragraph. Yes, I'm well aware of what databases can do for me, and have made a good living getting them to jump through hoops to do their thing. However part of knowing how to use a tool well is knowing its limitations. And from what I've learned, a web-based CRUD application is usually better off with business logic in the web layer, and not in the database. Also I have absolutely no idea why you brought up joining against remote data sources. However I've had to do it against multiple databases over the years. And in my experience with Access, Sybase, Oracle, PostgreSQL and MySQL, I found that for all but the simplest cases, #1 was preferable. For each of those databases I can name a case where I started with #2 with clear issues, and wound up with #1 working well. Why? Because if you understand query performance, you can make #1 work well. And databases tend to do a horrible job of understanding what's going on with remote data sources and picking good query plans for them. Which can cause #2 to suck in hard to fix ways. (Plus with PostgreSQL specifically there were security issues that made the DBA unwilling to open up one database remotely to the other. He was willing to let my application access both, but didn't want to allow other applications to be able to do it.) That said, most people who need access to remote data are in a simple circumstance. And I know a lot more about query performance than your average software developer. So if #2 can work for you, you should go that route.

btilly 13y ago

I was referring to putting business logic in your database, and not any particular query technique.

jeffdavis 13y ago
Sometimes it just saves you huge amounts of time and code to do something in the database though. For instance, if you need to join against a remote data source, you can: 1. Write a bunch of code to pull the data from both sources and join it in the application. You have to pick a join algorithm at the beginning, and if your data changes you may need to rewrite it later. 2. Add a remote table in the database and just do the join there. The database can use statistics to pick a join algorithm for you. I'm sure there are cases where you'd pick #1. But in many cases, the database offers a feature that allows you to implement a solution and call it "done" in minutes or hours where an application-based solution would drag on for days or weeks and carry a larger maintenance burden.
- btilly 13y ago
  Please go to https://news.ycombinator.com/item?id=5934136 https://news.ycombinator.com/item?id=5934136 and look at the final paragraph. Yes, I'm well aware of what databases can do for me, and have made a good living getting them to jump through hoops to do their thing. However part of knowing how to use a tool well is knowing its limitations. And from what I've learned, a web-based CRUD application is usually better off with business logic in the web layer, and not in the database. Also I have absolutely no idea why you brought up joining against remote data sources. However I've had to do it against multiple databases over the years. And in my experience with Access, Sybase, Oracle, PostgreSQL and MySQL, I found that for all but the simplest cases, #1 was preferable. For each of those databases I can name a case where I started with #2 with clear issues, and wound up with #1 working well. Why? Because if you understand query performance, you can make #1 work well. And databases tend to do a horrible job of understanding what's going on with remote data sources and picking good query plans for them. Which can cause #2 to suck in hard to fix ways. (Plus with PostgreSQL specifically there were security issues that made the DBA unwilling to open up one database remotely to the other. He was willing to let my application access both, but didn't want to allow other applications to be able to do it.) That said, most people who need access to remote data are in a simple circumstance. And I know a lot more about query performance than your average software developer. So if #2 can work for you, you should go that route.