I came across a query to create a dummy table like this
CREATE TABLE destination AS
SELECT level AS id,
CASE
WHEN MOD(level, 2) = 0 THEN 10
ELSE 20
END AS status,
'Description of level ' || level AS description
FROM dual
CONNECT BY level <= 10;
SELECT * FROM destination;
1 20 Description of level 1
2 10 Description of level 2
3 20 Description of level 3
4 10 Description of level 4
5 20 Description of level 5
6 10 Description of level 6
7 20 Description of level 7
8 10 Description of level 8
9 20 Description of level 9
10 10 Description of level 10
10 rows selected.
Could you share some insights of how this works ? First, the missing of PRIOR is unbeknownst to me. Second, I don't get how the tree is constructed. From the level it looks like they are all branched out from the same root.
This gimmick was noticed by a DB professional, Mikito Harakiri, and shared on AskTom. It has been adopted in the Oracle community, although it is undocumented (it actually goes against the documentation), and its use is somewhat dangerous in that Oracle may at some point make it no longer work. (Although with its already massive use, it would be insane for Oracle to take it back.)
The rows are indeed branching from the same root, the single row of dual. You can use any other table that has EXACTLY ONE row for the same trick. If you start with two rows (or you use the trick on your own table, with many rows), you will quickly run into trouble. There are ways around that, you will pick that up over time. You may be interested in following the Oracle forum, at OTN, people use this trick all the time there.
Here is an article that discusses this trick: http://www.sqlsnippets.com/en/topic-11821.html
Related
How can we achieve the same functionality as of 'SEQUENCE' in provided in Netezza?
Please find below the link demonstrating the functionality I would like to achieve in Big query :
[https://www.ibm.com/support/knowledgecenter/en/SSULQD_7.2.1/com.ibm.nz.dbu.doc/r_dbuser_create_sequence.html][1]
I have reviewed RANK() but this is not solving my purpose to the core. Any leads would be appreciated.
in BigQuery Standard SQL you can find two function that can help you here -
GENERATE_ARRAY(start_expression, end_expression\[, step_expression\])
and
GENERATE_DATE_ARRAY(start_date, end_date\[, INTERVAL INT64_expr date_part\])
For example, below code
#standardSQL
SELECT sequence
FROM UNNEST(GENERATE_ARRAY(1, 10, 1)) AS sequence
produces result as
sequence
1
2
3
4
5
6
7
8
9
10
I am using Gephi to create a network graph, here is a small subset of the data that I have:
ID Label
1 Sleep quality
2 Stress
3 Healthy Eating
4 Tremor
5 Balance
6 Drooling
7 Exercise
8 Mood
9 Speech
10 Parkinson's On-Off
So I want my graph to have these 10 nodes.
Then for the edges, I have:
Source Target User
1 5 5346
5 4 5346
4 7 5346
7 6 5346
6 9 5346
9 3 5346
3 2 5346
2 8 5346
8 10 5346
The "User" column is something I have added to explain the problem I am having. I am using a big database (in SQL) to obtain this data. On a mobile phone app, users select 10 of the different choices available (as listed in the nodes). In SQL I can query the data easily so that I can obtain the 10 choices of each of the users.
It is easy to create a graph with the edges with the information in the edges table but I would also like to connect each edge to all other edges, this is important for me. So for example, 1 connects to all those in "target". Then 5 connects to all those in "target" and so until all nodes are connected to each other for each user.
I can do this manually but the original data set has 2000+ users and this will take a long time. I know that there is a way of using cross join, possibly in Excel or in SQL... but I'm unsure how to do this..
Thanks!
You can drop this cross join into your SQL: (It'll list all Source's with all possible Target's.)
(SELECT e.Source as Source, n.ID as Target
FROM
(SELECT DISTINCT Source FROM tblEdges) as e
cross join (SELECT DISTINCT ID FROM tblNodes) as n
) as xCross
For the documentation, I know connect by can be used together with prior, in hierarchical queries. But quite often I see it is used to generate numbers:
SQL> select level from dual connect by level < 10;
LEVEL
----------
1
2
3
4
5
6
7
8
9
9 rows selected
SQL>
How it works here ? I mean how it generate 1, then 2, and so on. I can not see a hierarchy here, and connect by is not being used with prior. This has confused me for a long time.
The query does a linear recursive call.
Level is fake column generated by the recursion which tells the recursion depth of current iteration. The connect by clause does not need to refer to prior, it is condition just like any other which tells 'If this row has level smaller than 10, union it to the result set'
This:
select *
from dual
connect by level <= i
...will return result as
1
2
3
...
i
Can the query be modified to get result row wise? i.e
1 2 3 .....i
The functionality you're after is called "pivot"--it's converting row data into columnar data. The opposite is called "unpivot". There is PIVOT/UNPIVOT syntax, but it isn't available until Oracle 11g.
On Oracle 9i+, CASE statements are used while prior to that you need to use DECODE to construct the logic so the values come out in columns. Here's an example for addressing if the limit to LEVEL is five on Oracle 9i+:
SELECT MAX(CASE WHEN LEVEL = 1 THEN LEVEL END) AS one,
MAX(CASE WHEN LEVEL = 2 THEN LEVEL END) AS two,
MAX(CASE WHEN LEVEL = 3 THEN LEVEL END) AS three,
MAX(CASE WHEN LEVEL = 4 THEN LEVEL END) AS four,
MAX(CASE WHEN LEVEL = 5 THEN LEVEL END) AS five
FROM DUAL
CONNECT BY LEVEL <= 5
The aggregate function MAX is necessary to "flatten" the resultset into a single row/record.
If you got this far, you're thinking "but I don't want to have to specify for every column--I want it to be dynamic based on i...". There's two issues:
There is a limit to the number of columns - see ORA-01792 maximum number of columns in a table or view is 1000. That goes for 8i & 9i, anyways. And frankly, needing to generate that many columns raises serious questions about what you're trying to do with the resultset, if there might be a better approach...
Dynamic requirements means using dynamic SQL
Try this:
select trim(both ',' from sys_connect_by_path(level, ',')) as string
from dual
where level = 100
connect by level <= 100
update: Testing the output:
SQL>
SQL> select trim(both ',' from sys_connect_by_path(level, ',')) as string
2 from dual
3 where level = 20
4 connect by level <= 20
5 /
STRING
--------------------------------------------------------------------------------
1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20
another update: Guess I haven't read all comments well enough before posting, sorry. :) If you need to select each number as a separate column, then yes, see, OMG Ponies' answer - it's either pivot or dynamic SQL. :)
I have the following tables, the groups table which contains hierarchically ordered groups and group_member which stores which groups a user belongs to.
groups
---------
id
parent_id
name
group_member
---------
id
group_id
user_id
ID PARENT_ID NAME
---------------------------
1 NULL Cerebra
2 1 CATS
3 2 CATS 2.0
4 1 Cerepedia
5 4 Cerepedia 2.0
6 1 CMS
ID GROUP_ID USER_ID
---------------------------
1 1 3
2 1 4
3 1 5
4 2 7
5 2 6
6 4 6
7 5 12
8 4 9
9 1 10
I want to retrieve the visible groups for a given user. That it is to say groups a user belongs to and children of these groups. For example, with the above data:
USER VISIBLE_GROUPS
9 4, 5
3 1,2,4,5,6
12 5
I am getting these values using recursion and several database queries. But I would like to know if it is possible to do this with a single SQL query to improve my app performance. I am using MySQL.
Two things come to mind:
1 - You can repeatedly outer-join the table to itself to recursively walk up your tree, as in:
SELECT *
FROM
MY_GROUPS MG1
,MY_GROUPS MG2
,MY_GROUPS MG3
,MY_GROUPS MG4
,MY_GROUPS MG5
,MY_GROUP_MEMBERS MGM
WHERE MG1.PARENT_ID = MG2.UNIQID (+)
AND MG1.UNIQID = MGM.GROUP_ID (+)
AND MG2.PARENT_ID = MG3.UNIQID (+)
AND MG3.PARENT_ID = MG4.UNIQID (+)
AND MG4.PARENT_ID = MG5.UNIQID (+)
AND MGM.USER_ID = 9
That's gonna give you results like this:
UNIQID PARENT_ID NAME UNIQID_1 PARENT_ID_1 NAME_1 UNIQID_2 PARENT_ID_2 NAME_2 UNIQID_3 PARENT_ID_3 NAME_3 UNIQID_4 PARENT_ID_4 NAME_4 UNIQID_5 GROUP_ID USER_ID
4 2 Cerepedia 2 1 CATS 1 null Cerebra null null null null null null 8 4 9
The limit here is that you must add a new join for each "level" you want to walk up the tree. If your tree has less than, say, 20 levels, then you could probably get away with it by creating a view that showed 20 levels from every user.
2 - The only other approach that I know of is to create a recursive database function, and call that from code. You'll still have some lookup overhead that way (i.e., your # of queries will still be equal to the # of levels you are walking on the tree), but overall it should be faster since it's all taking place within the database.
I'm not sure about MySql, but in Oracle, such a function would be similar to this one (you'll have to change the table and field names; I'm just copying something I did in the past):
CREATE OR REPLACE FUNCTION GoUpLevel(WO_ID INTEGER, UPLEVEL INTEGER) RETURN INTEGER
IS
BEGIN
DECLARE
iResult INTEGER;
iParent INTEGER;
BEGIN
IF UPLEVEL <= 0 THEN
iResult := WO_ID;
ELSE
SELECT PARENT_ID
INTO iParent
FROM WOTREE
WHERE ID = WO_ID;
iResult := GoUpLevel(iParent,UPLEVEL-1); --recursive
END;
RETURN iResult;
EXCEPTION WHEN NO_DATA_FOUND THEN
RETURN NULL;
END;
END GoUpLevel;
/
Joe Cleko's books "SQL for Smarties" and "Trees and Hierarchies in SQL for Smarties" describe methods that avoid recursion entirely, by using nested sets. That complicates the updating, but makes other queries (that would normally need recursion) comparatively straightforward. There are some examples in this article written by Joe back in 1996.
I don't think that this can be accomplished without using recursion. You can accomplish it with with a single stored procedure using mySQL, but recursion is not allowed in stored procedures by default. This article has information about how to enable recursion. I'm not certain about how much impact this would have on performance verses the multiple query approach. mySQL may do some optimization of stored procedures, but otherwise I would expect the performance to be similar.
Didn't know if you had a Users table, so I get the list via the User_ID's stored in the Group_Member table...
SELECT GroupUsers.User_ID,
(
SELECT
STUFF((SELECT ',' +
Cast(Group_ID As Varchar(10))
FROM Group_Member Member (nolock)
WHERE Member.User_ID=GroupUsers.User_ID
FOR XML PATH('')),1,1,'')
) As Groups
FROM (SELECT User_ID FROM Group_Member GROUP BY User_ID) GroupUsers
That returns:
User_ID Groups
3 1
4 1
5 1
6 2,4
7 2
9 4
10 1
12 5
Which seems right according to the data in your table. But doesn't match up with your expected value list (e.g. User 9 is only in one group in your table data but you show it in the results as belonging to two)
EDIT: Dang. Just noticed that you're using MySQL. My solution was for SQL Server. Sorry.
-- Kevin Fairchild
There was already similar question raised.
Here is my answer (a bit edited):
I am not sure I understand correctly your question, but this could work My take on trees in SQL.
Linked post described method of storing tree in database -- PostgreSQL in that case -- but the method is clear enough, so it can be adopted easily for any database.
With this method you can easy update all the nodes depend on modified node K with about N simple SELECTs queries where N is distance of K from root node.
Good Luck!
I don't remember which SO question I found the link under, but this article on sitepoint.com (second page) shows another way of storing hierarchical trees in a table that makes it easy to find all child nodes, or the path to the top, things like that. Good explanation with example code.
PS. Newish to StackOverflow, is the above ok as an answer, or should it really have been a comment on the question since it's just a pointer to a different solution (not exactly answering the question itself)?
There's no way to do this in the SQL standard, but you can usually find vendor-specific extensions, e.g., CONNECT BY in Oracle.
UPDATE: As the comments point out, this was added in SQL 99.