On Nov 14, 2013, at 2:19 PM, Benoit Chesneau <bchesn...@gmail.com> wrote:
> I have examples in prod that shows that not anyone is sharing the same > opinion as you ;) There are plenty of example where lists and shows can be > used. I’m sure there are. They’re just not particularly useful when the database is embedded inside the app. The kind of postprocessing list/show functions do is useful when the client and server are widely separated since it saves you a lot of round-trips and can massage data into the form a client expects. That’s not an issue when the app and db live within the same process. > Where > the use of lists and shows, the fact that you can replicate them (which is > possible when you use ios and android outside the app store in entreprises > or private events) is a huge advantage. You can implement list/show functions outside the database. You can even put them in a library function in your CouchApp and replicate them that way. They’re just handy utilities, not actual database functionality. > Why some person are using > SQL? Because they can query the data. Why woud you like to have shows and > lists or any feature like this? Because you eventually build your own way > to query your data. I’m not saying the ability to postprocess query results isn’t useful. I’m just saying that list and show functions are a hacky way to do it. They remind me of old CGI programs that painstakingly assembled HTML by string concatenation, instead of using something like a template language. And the fact that they’re manipulating the results in text form makes them inefficient and prone to errors. Ideally you’d transform the data directly as objects instead of having to convert them into text that then gets parsed by something else. —Jens
