I have an SQL script I want to replicate inside tableau using tableau's joins.
SQL script (script simplified just for explanation):
Select *
From transactions
Inner join data1
UNION
Select *
From transactions
Inner join data2
How do replicate this in tableau using joins n unions? (No tableau custom SQL please)
You can do manual unions or wildcard unions: Tableau Help
Depending on your data connection, some features of it may or may not be supported.
Same with joins, lots of ways to do it: Tableau Help
Make sure you're looking up the docs and searching for an answer before posting. These types of this are easy to find.
Related
I have two tables, by joining that 2 tables i need to take distinct count of one particular column from OrientDB. Since joins donot support in OrientDB. Please suggest me in orient db how join works and please suggest me also how to use edges for join in orientdb.
Anyone know what is the ORM function for joining multiple db tables in ERPNext?
I need query result from 2 DB tables join using script report
*I don't need query report answer since i already have it. I only looking for an example do it using script report
Frappe currently doesn't have ORM support for joining tables. You might have to use frappe.db.sql for the time being.
data = frappe.db.sql(
"""
select tb1.name from tabTable1 as tb1
left join tabTable2 as tb2 on tb1.name = tb2.employee_name;
"""
);
return data
I want to know can we write query using two tables ( join) in flink Table and SQL api.
I am new to flik, I want to create two table from two different data set and query them and produce other dataset.
my query would be like select... from table1, table 2... so can we write like this query which querying two tables or more?
Thanks
Flink's Table API supports join operations (full, left, right, inner joins) on batch tables (e.g. those created from a DataSet).
SELECT c, g FROM Table3, Table5 WHERE b = e
For streaming tables (e.g. those created from a DataStream), Flink does not yet support join operations. But the Flink community is actively working to add them in the near future.
The task at hand is to select musicians (pid) and the amount of instruments each play, including instruments only played at a concert - these instruments might not be in the [plays] table.
I've solved it, but I read that sub queries in a from clause should be avoided if possible. Just out of curiosity, can anyone show me a more effective way? Or is this a good solution? I'm using psql.
select a.pid, sum(a.instr)
from
(
select pid, count(instr) as instr from plays group by pid
union all
select pid, count(instr) as instr from concert group by pid
) as a
group by a.pid;
Such queries are not a issue. The query optimizer of the database will take care of getting the best out of this query. In some cases a INNER JOIN will be converted to exactly the same execution plan as a sub-SELECT.
If you think the query has a problem you can always fire up the EXPLAIN ANALYZE function of psql. This will give you a overview what your query is actually doing. This way you can also compare different ways to write the query.
The example you gave... I do not think you can solve this without sub-queries very easily. I think the way you chose is good. Anything involving some LEFT JOINs will be more difficult to read.
Advantages
Subqueries are advantageous because they structure the query to isolate each part of the statement, perform the same operation that would ordinarily require complex joins and unions and are easier to read.
Disadvantages
When using subqueries the query optimizer may need to perform additional steps so they take longer to execute than a join.
Uncorrelated subqueries are executed one time for each row of the parent query. If this kind of subqueries process a great amount of data, you should expect it to take a very long time to process the data.
Possible solution:
You can create temporary tables for storing the data of subqueries, then use a JOIN for completing the query. Remember that using a JOIN is better than using a subquery. How to Create a Table
Use a with clause. WITH provides a way to write auxiliary statements for use in a larger query. These statements, which are often referred to as Common Table Expressions or CTEs, can be thought of as defining temporary tables that exist just for one query. It allows you to execute a subquery just once instead of executing it for each row. How to Use With Clause
NOTICE: You should avoid using UNION or UNION ALL.
I have around 200-250 reports that have been developed in SQL Server 2000 and I have used *= , =* in many places. So recently we migrated to SQL Server 2008 and all reports have to be fixed for the 2008 standard.
So I have couple of issue in compatibility like
"The query uses non-ANSI outer join
operators (*= or=*). To run this
query without modification, please set
the compatibility level for current
database to 80, using the SET
COMPATIBILITY_LEVEL option of ALTER
DATABASE. It is strongly recommended
to rewrite the query using ANSI outer
join operators (LEFT OUTER JOIN, RIGHT
OUTER JOIN). In the future versions of
SQL Server, non-ANSI join operators
will not be supported even in
backward-compatibility modes."
So it takes long time to re-query all things and fixing. Even we don't need to enable backward compatibility of 2008, we do need to fix all those queries...
Is there any tool that will fix all those queries easily?
Thanks and Best Regards,
The Microsoft SQL Server 2008 Upgrade Advisor should identify the offending TSQL, but it won't fix it for you.
It is a prudent idea to run the SQL Server 2008 Upgrade Advisor on all Databases to be upgraded.
There is no tool. How can any tool know what the semantics would be of this, for example?
You are changing
FROM Table1 T1, Table2 T2, Table2 T3
WHERE T1.key *= T2.key AND T1.key = T3.key AND T3.foo = 'bar'
to
FROM
Table T1
JOIN
Table T3 ON T1.key = T3.key
LEFT JOIN
Table T2 ON T1.key = T3.key
WHERE
T3.foo = 'bar'
You have been able to use JOIN/LEFT JOIN etc since at least SQL Server 6.5: using *= for SQL Server 2000 was ignorance and/or laziness
There is a tool built into SSMS that can help, but you will still need to test. See my post on SSC which describes the technique:
http://www.sqlservercentral.com/Forums/FindPost1098339.aspx