Prakash Premkumar wrote:
> Let's say I have tables T1,T2 and T3 with 2 columns each and I am joining
> them.
> The result rows will have 8 columns each.
No. The result will have between 4 and 6 columns, depending on how you
do the joins.
Example:
CREATE TABLE T1(ID1, Name);
INSERT INTO "T1" VALUES('r11',NULL);
CREATE TABLE T2(ID2, ID1);
INSERT INTO "T2" VALUES('r21','r11');
CREATE TABLE T3(ID3, ID2);
INSERT INTO "T3" VALUES('r31','r21');
INSERT INTO "T3" VALUES('r32','r21');
INSERT INTO "T3" VALUES('r33','r21');
SELECT * FROM T1 NATURAL JOIN T2 NATURAL JOIN T3;
ID1 Name ID2 ID3
---------- ---------- ---------- ----------
r11 r21 r31
r11 r21 r32
r11 r21 r33
> sqlite produces 3 result rows , but I would like to produce one result row
> where the results are linked and the rows r11 and r21 are not repeated.(It
> is similar to an adjacency list representation)
The output of an SQLite query always has a fixed number of columns, and
for specific data, a fixed number of rows.
Please specify exactly how the output for this example data should look
like.
> 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.
Your program has to read either the value of ID1, to compare it with the
last one, or some other indication that there is a new T1 row. What's
the difference? Or how exactly should the API look like?
Regards,
Clemens
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
