I have created a View:
CREATE VIEW Lunch
AS
SELECT 'Beer' AS item
UNION SELECT 'Olives'
UNION SELECT 'Bread'
UNION SELECT 'Salami'
UNION SELECT 'Calamari'
UNION SELECT 'Coffee';
GO
Then I executed the following query in a different query.
SELECT item FROM Lunch
This is resulting in the data from the view being returned. There are not any underlying tables to hold data. But still the system is showing records. How is this possible?
I don't fully understand the question. The view is not "holding data", it is holding a query. The query statement has constants in it that are turned into a result set that can be used by other queries.
You can think of a query as substituting the text of the query directly into a statement. So, when you do:
select *
from lunch;
SQL really processes this as:
select *
from ( SELECT 'Beer' AS item
UNION SELECT 'Olives'
UNION SELECT 'Bread'
UNION SELECT 'Salami'
UNION SELECT 'Calamari'
UNION SELECT 'Coffee'
) t
This is a good model of what happens, although it is not quite what really happens. What really happens is that the view is compiled and the compiled code is inserted into the compiled code for the query.
There is another concept of "materialized views". These are views where you have indexes and the values are actually stored in the database. However, this is not an example of a materialized view.
It doesn't actually hold data, but it can evaluate SQL, which is all you're doing in the definition.
So the following can be evaluated:
SELECT 'Beer' AS item
UNION SELECT 'Olives'
UNION SELECT 'Bread'
UNION SELECT 'Salami'
UNION SELECT 'Calamari'
UNION SELECT 'Coffee';
The same as a view defined with:
SELECT * FROM Customers
SQL View Reference:
A view can be thought of as either a virtual table or a stored query. The data accessible through a view is not stored in the database as a distinct object. What is stored in the database is a SELECT statement. The result set of the SELECT statement forms the virtual table returned by the view. A user can use this virtual table by referencing the view name in Transact-SQL statements the same way a table is referenced.
A view is a Saved Select Statement in your case view definition does not have any underlying tables, but the select statement itself has hard coded (Constant) values.
Therefore it will always return this data.
Again to be clear it is not storing any data but the Select Statement which happens to return some constant values.
Yes, the data is shown because is statically included into the query itself.
I don't see anything uncommon here, the view refers to the query that embed the data .
Related
I want to run two Oracle SQL queries together inside TOAD.
first query:
SELECT * FROM OT_SO_HEAD WHERE SOH_ANNOTATION = 'ECSO10012791'
and second:
SELECT * FROM OT_SO_ITEM WHERE SOI_SOH_SYS_ID = '30977853'
Please guide
You can use UNION or UNION ALL.
The UNION operator is used to combine the result-set of two or more SELECT statements.
Every SELECT statement within UNION must have the same number of columns
The columns must also have similar data types
The columns in every SELECT statement must also be in the same order
Syntax:
SELECT column_name(s) FROM table1
UNION
SELECT column_name(s) FROM table2;
The UNION operator selects only distinct values by default. To allow duplicate values, use UNION ALL.
right click in script window and select EXECUTE -> Execute via Toad Script Runner and reuse Toad
I have doc_no, I need to find out its type. So I need to select a query from the table.
SELECT o.type_id
FROM operation_out o
WHERE o.doc_no = 17025337;
But what to do, if I have 3 different tables
operation_out, operation_in, operation_reverse
and given doc_no can be in any of the given tables.
I have already tried union:
SELECT transfer_type_id
FROM (SELECT doc_no, mt_o.type_id
FROM mt_operation_out mt_o
UNION ALL
SELECT doc_no, mt_in.type_id
FROM mt_operation_in mt_in
UNION ALL
SELECT doc_no, mt_r.type_id
FROM mt_operation_reverse mt_r)
WHERE doc_no = 17025337;
Is there another alternative way of writing this? Is there any syntax in SQL for this kind of task?
Thank you all for your recommendations. In the end, I created a view based on the UNION ALL, and I'm going to use it wherever needed.
Here's my query:
SELECT my_view.*
FROM my_view
WHERE my_view.trial in (select 2 as trial_id from dual union select 3 from dual union select 4 from dual)
and my_view.location like ('123-%')
When I execute this query it returns results which do not conform to the my_view.location like ('123-%') condition. It's as if that condition is being ignored completely. I can even change it to my_view.location IS NULL and it returns the same results, despite that field being not-nullable.
I know this query seems ridiculous with the selects from dual, but I've structured it this way to replicate a problem I have when I use a 'WITH' clause (the results of that query are where the selects from dual inline view are).
I can modify the query like so and it returns the expected results:
SELECT my_view.*
FROM my_view
WHERE my_view.trial in (2, 3, 4)
and my_view.location like ('123-%')
Unfortunately I do not know the trial values up front (they are queried for in a 'WITH' clause) so I cannot structure my query this way. What am I doing wrong?
I will say that the my_view view is composed of 3 other views whose results are UNION ALL and each of which retrieve some data over a DB Link. Not that I believe that should matter, but in case it does.
One thing you could try if you don't have luck with this route is to replace "IN" with an "EXISTS" or "NOT EXISTS" statement.
If you could accomplish what you want using joins, that would be the best option because of performance. If you have views pulling data from views, you can often make a single query to do what you want that gives you better performance using subqueries.
If you do
EXPLAIN PLAN FOR
SELECT my_view.*
FROM my_view
WHERE my_view.trial in (select 2 as trial_id from dual union select 3 from dual union select 4 from dual)
and my_view.location like ('123-%');
SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY);
you should see where the location predicate is 9or is not) being applied. My bet is that it has something to do with the DB links and you won't be able to reproduce it if all the tables are local.
Optimizing a distributed query gets complicated.
Try changing the UNION query to use UNION ALL, as in:
SELECT my_view.*
FROM my_view
WHERE my_view.trial in (select 2 as trial_id from dual
UNION ALL
select 3 AS TRIAL_ID from dual
UNION ALL
select 4 AS TRIAL_ID from dual)
and my_view.location like ('123-%')
I also put in "AS TRIAL_ID" on the 3 and 4 cases. I agree that neither of these should matter, but I've run into cases occasionally where things that I thought shouldn't matter mattered.
Good luck.
Currently I have 2 tables, both of the tables have the same structure and are going to be used in a web application. the two tables are production and temp. The temp table contains one additional column called [signed up]. Currently I generate a single list using two columns that are found in each table (recno and name). Using these two fields I'm able to support my web application search function. Now what I need to do is support limiting the amount of items that can be used in the search on the second table. the reason for this is become once a person is "signed up" a similar record is created in the production table and will have its own recno.
doing:
Select recno, name
from production
UNION ALL
Select recno, name
from temp
...will show me everyone. I have tried:
Select recno, name
from production
UNION ALL
Select recno, name
from temp
WHERE signup <> 'Y'
But this returns nothing? Can anyone help?
For what you are asking, you could do it this style.
SELECT * FROM
(
SELECT '1' as `col`
UNION
SELECT '2' as `col`
) as `someAlias`
where `someAlias`.`col` = '1'
Put the entire union inside parenthesis, give it an alias, then give the condition.
Not sure if I'm understanding what you want exactly. If you create records in the production table once they have signed up from the temp table, and you only want people who haven't signed up...you don't need to look in the production table at all. Simply:
SELECT recno, name FROM temp WHERE signup='N'
Or however you're trying to limit your search. If for some reason you do need a union but you're trying to eliminate duplicates you'd have to modify your statement to remove the ALL clause. Union ALL causes you to get duplicates. If you don't want duplicate values, you want to not use ALL in your UNION. You can read up on Unions here.
i want to add select query result into dataset, so i can write new query to run on it to get net dataset but how?
Original query:
MyDATASET=(
select x, y,z from table1
union all
select k,l,m from table2
)
i wan to this select * from this.MyDATASET
Well, you could perhaps create a CTE, UDF or view? But it really isn't clear what you are trying to do...
CREATE VIEW MyView AS
select x, y,z from table1
union all
select k,l,m from table2
GO
SELECT * FROM MyView
SELECT * FROM MyView WHERE x = 0
etc
Assuming you want to cache data for re-use later...
Use a temp table or table variable if it's contained within one bit of code.
If you want to refer the same data in several processes or calls, then use a temp table. Use a local one for many calls but don't close the connecion, use a global one for many different processes/connections.
If it's just one big select where you want to re-use the same data, then use a CTE.
A view also works but the data may change between executions.