On Wed, 24 Sep 2014 11:03:53 +0530 Prakash Premkumar <prakash.p...@gmail.com> wrote:
> Let's say an output of the join is: > > r11,r21,r31 > r11,r21,r32 > r11,r21,r33 > > where r1i is the i th row in T1, r2i is the i th row in T2 and r3i is > the ith row in T3: > > sqlite produces 3 result rows , but I would like to produce one > result row where, > > r11 > | > r21 > / | \ > r31 r32 r33 ... > The efficiency I gain with the 2nd approach, is the reduction is in > the number of copies .i.e each row is copied only once. Granting your thesis ad argumentum, your approach has three inefficiencies: 1. The graph needs pointers for the values, or some metadata to indicate the graph structure. 2. To create the graph, the data must be sorted. 3. Memory for the graph has to be allocated. If you build the graph yourself atop the API, you will do very much what you're asking SQLite to do. You will find that not only is it not very efficient after all but, because graphs are complex data structures, the interface is hideous. If you don't believe me, try reading IBM's IMS documentation sometime. Or consider the complexity of "next" in a depth-first search, compared with row iteration. Let's suppose none of that is true, though, and pretend a graph can be summoned instantly and navigated effortlessly. I ask you: how will your application use the data in the graph? Will it compute on them in situ? Or will it copy them into a native structure, so you can operate on them efficiently as named variables? If the latter, you're still copying the data. These among other reasons are why the relational model evicted its predecessors from the database landscape. If you revisit your assumptions, you may find it easier to use and more efficient than it first seemed. --jkl _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
