Fwd: Sql join feature in persistent

2011/2/22 Антон Чешков
I want join its by some rule and take only first "N" results. In this case i do not want serve all datasets entirely. I would like to make as little as possible. I think this algorithms are exist.
Those algorithms exist indeed and have been implemented in last 25 years inside RDBMS as query optimizers. The question is, how much is that reasonable to re-implement in Haskell/Persistent? My 2 cent guess is that there are two viable options: 1) For Relational Backends, when scalability concerns raised by Max are not important, the approach of a monadic DSL a la HaskellDB is the best. Basically the library job is to build the SQL query and let the RDBMS optmizer do its job. 2) For NOSQL Backends, the solution is to code your hand rolled queries as it can be done with persistent now (the "do nothing" solution). That is the approach suggested for redis, for example... Paolo -- Paolo Losi e-mail: paolo@enuan.com mob: +39 348 7705261 ENUAN Srl Via XX Settembre, 12 - 29100 Piacenza

Of course using RDBMS directly will give the best results. Especially for
large data volumes.
But to have this feature in application layer is convenient.
Also i am sure that solutions "a la HaskellDB" must be too.
I see this solution as separate module. Developer must have choice.
2011/2/22 Paolo Losi
2011/2/22 Антон Чешков
I want join its by some rule and take only first "N" results. In this case i do not want serve all datasets entirely. I would like to make as little as possible. I think this algorithms are exist.
Those algorithms exist indeed and have been implemented in last 25 years inside RDBMS as query optimizers. The question is, how much is that reasonable to re-implement in Haskell/Persistent? My 2 cent guess is that there are two viable options:
1) For Relational Backends, when scalability concerns raised by Max are not important, the approach of a monadic DSL a la HaskellDB is the best. Basically the library job is to build the SQL query and let the RDBMS optmizer do its job.
2) For NOSQL Backends, the solution is to code your hand rolled queries as it can be done with persistent now (the "do nothing" solution). That is the approach suggested for redis, for example...
Paolo
-- Paolo Losi e-mail: paolo@enuan.com mob: +39 348 7705261
ENUAN Srl Via XX Settembre, 12 - 29100 Piacenza
_______________________________________________ web-devel mailing list web-devel@haskell.org http://www.haskell.org/mailman/listinfo/web-devel
-- Best regards, Cheshkov Anton Phone: +7 909 005 18 82 Phone: +7 931 511 47 37 Skype: cheshkov_anton

Hello,
Of course using RDBMS directly will give the best results. Especially for large data volumes. But to have this feature in application layer is convenient.
Fritz Henglein has done some recent, interesting work in this area. His WGP paper (http://www.diku.dk/hjemmesider/ansatte/henglein/papers/henglein2010d.pdf) is a good place to start if you're interested. -Jeff --- This communication may contain confidential and/or privileged information. If you are not the intended recipient (or have received this communication in error) please notify the sender immediately and destroy this communication. Any unauthorized copying, disclosure or distribution of the material in this communication is strictly forbidden. Deutsche Bank does not render legal or tax advice, and the information contained in this communication should not be regarded as such.

I agree with you. We can have different strategy for different back ends. For relational databases back ends such as persistent-postgres, it's reasonable to add some useful sql features, to get high performance in the production scenarios, and avoid reinventing the same wheels in the application layer. As for NoSql back ends, we can do nothing just like now, or provide some application layer tools for developers to use quickly. On Tue, 2011-02-22 at 13:04 +0100, Paolo Losi wrote:
2011/2/22 Антон Чешков
I want join its by some rule and take only first "N" results. In this case i do not want serve all datasets entirely. I would like to make as little as possible. I think this algorithms are exist. Those algorithms exist indeed and have been implemented in last 25 years inside RDBMS as query optimizers. The question is, how much is that reasonable to re-implement in Haskell/Persistent? My 2 cent guess is that there are two viable options:
1) For Relational Backends, when scalability concerns raised by Max are not important, the approach of a monadic DSL a la HaskellDB is the best. Basically the library job is to build the SQL query and let the RDBMS optmizer do its job.
2) For NOSQL Backends, the solution is to code your hand rolled queries as it can be done with persistent now (the "do nothing" solution). That is the approach suggested for redis, for example...
Paolo
-- Paolo Losi e-mail: paolo@enuan.com mob: +39 348 7705261
ENUAN Srl Via XX Settembre, 12 - 29100 Piacenza _______________________________________________ web-devel mailing list web-devel@haskell.org http://www.haskell.org/mailman/listinfo/web-devel
participants (4)
-
James
-
Jeff Polakow
-
Paolo Losi
-
Антон Чешков