Using a view to encapsulate a table whose name changes yearly (tablename_year) called "vw_Tablename_Current" so I don't have to change any procs that use the table to reflect the new table name, just the view.
This is temporary until I'm able to make deeper model changes. Is there any performance hit on wrapping a single table in a view like this?
Sql Server 2005
You can use a synonym as well which is cleaner
CREATE SYNONYM tablename FOR tablename_year;
No, there is no performance difference if the view is essentially a SELECT * FROM table
Related
I want to query an object from DB that exists in any one of the tables. I am not sure about the table name that a particular object belongs to. For e.g. let's say my DB consists of various tables like Domestic_Passengers, Asian_Passengers, US_Passengers. And this table list may increase as well like in the future we may add the UK_Passengers table too.
So, I want to query something like
SELECT * FROM
(SELECT table_name FROM user_tables where table_name like '%PASSENGER')
WHERE NAME LIKE 'John%'
Is this possible?
That's a very bad database design.
I would suggest a view like this:
CREATE OR REPLACE VIEW PASSENGERS AS
SELECT * FROM Domestic_Passengers
UNION ALL
SELECT * FROM Asian_Passengers
UNION ALL
SELECT * FROM US_Passengers;
And then select from this view.
If this is not possible, then you need to run dynamic SQL in PL/SQL package. But this involves some code.
The best answer depends on a lot of details, such if you can create database objects, how static are the tables, and how will this query be consumed.
If you can create schema objects, and the list of tables is somewhat stable, then Wernfried's answer of building a view is probably best.
If you can create schema objects, but the list of tables is very dynamic, and your application understands ref cursors, you should probably create a function that creates the SELECT and returns it through a ref cursor, like in this answer.
If you cannot create schema objects, then you're limited to the DBMS_XMLGEN/XMLTABLE trick. In a single query, build a string for the SELECT statement you want, run it through DBMS_XMLGEN to create an XMLType, and then use XMLTABLE to transform the XML back into rows and columns. This approach is slow and ugly, but it's the only way to have dynamic SQL in SQL without creating any custom PL/SQL objects. See my answer here for an example.
I'm new to Azure and not great with SQL so any help would be greatly appreciated.
I have a Database where each user has a Schema. Each Schema has identically structured tables with the same name, say "Table".
I now require a View in another Schema which provides a read-only union of all the rows from all the tables Table.
I was successful in creating a Schema, say Views, handling its permissions and creating a View, "TableView", with the following SQL from Partitioned Views # learn.microsoft.com:
CREATE VIEW Views.TableView
AS
SELECT *
FROM Schema1.Table
UNION ALL
SELECT *
FROM Schema2.Table
UNION ALL
SELECT *
FROM Schema3.Table
...
GO
I now wish for this View to be dynamic as future Schemas (SchemaX) are added or even possibly removed without having to repeatedly DROP and CREATE TableView over and over.
Is it possible to create the View in such a way that it would automatically query all tables with the same name? Or perhaps there is some way to 'add' an additional table post creation?
I can get a list of all SchemaX.Table by querying INFORMATION_SCHEMA, but other than having a python script DROP and CREATE the View again I am lost.
Thanks
Thanks for #larnu's comments, it's very useful and professional:
To achieve this dynamically, it would be impossible to do in a VIEW.
You would have to use a stored procedure, and that means you can't do
simple things like SELECT from it, making it far harder to use.
Instead of having 17 tables, all identical, on different schemas you
have one table, with a column BusinessName. Instead of
MySmartCompany.Mytable you have a column in the table dbo.MyTable (or
your generic schema), called BusinessName which has the value 'MySmartCompany'.
This also can be beneficial to other community members.
We have a table in our Oracle Database that was created from an actual script.
Ex:
Create Table AS (Select * from table).
I was hoping to recover the original script the table was created from as the data is quite old in the table, but needs this created table needs to be refreshed. This table is created with data from another live table in our database, so if there is a way to refresh this without the original query - I'm open ears. Any solutions are welcomed!
Thanks!
I suppose you could also do a column by column comparison of this table against all others to see which one (if any) matches it. Of course, this would only be a guess.
It would require that object to actually be a materialized view instead of a table. Otherwise you are probably left off with exploring logs. Beyond that I doubt there is any way to recover the original select statement used to create that table.
I'm creating an Oracle view like this :
SELECT * FROM TABLE;
When I create the view, I notice that oracle changes the view query to something like :
SELECT FIELD1, FIELD2,... FROM TABLE;
My problem is that if I change the TABLE structure, add a new field for instance, the changes are not taken into consideration in the view. I have then to recreate the view, and regrant privileges on this view to the users/roles.
Is there any way to make a view mode generic and keep it as the form of : SELECT * FROM TABLE ?
Thanks.
You cannot define a simple view that would automatically change its structure when the underlying table changes. When new columns are added, you'll need to touch the view. You'll almost certainly need to do as #GordonLinoff suggests and do a CREATE OR REPLACE when the table changes. Given that changes to tables should be rare and should involve proper change control, touching the view as part of the change should be a relatively simple step.
If you're really determined to avoid having to touch the view, there are some alternatives. I generally wouldn't recommend these because they are very likely to increase rather than decrease the complexity of maintaining your system. But if you have a third party system that is generating DDL to add columns on an unpredictable basis, maybe it makes sense.
You could create a DDL trigger that fires in response to statements that ALTER the table and that submits a job using dbms_job that re-creates the view. That's quite a few moving pieces but it's generally workable.
Alternately, instead of a view, you could create a pipelined table function that returns a variable number of columns. That's going to be really complicated but it's also pretty slick. There aren't many places that I'd feel comfortable using that approach simply because there aren't many people that can look at that code and have a chance of maintaining it. But the code is pretty slick.
The * is evaluated when the view is created, not when it is executed. In fact, Oracle compiles views for faster execution. It uses the compiled code when the view is referenced. It does not just do a text substitution into the query.
The proper syntax for changing a view is:
create or replace view v_table as
select *
from table;
I have face this same issue and created a procedure which accepts the name of the table and creates the view:
str := 'create or replace view xyz.'|| tablename_in ||'_v as select * from '|| tablename_in;
execute immediate str;
Then in Toad (not sure if you use Toad), in the schema browser, right click on the table name, and then select 'Custom Queries' --> 'Edit Custom Queries' and then have it call your procedure as:
exec view_create<ObjectList>
Then you can right click on the table name and in one click create the view as Toad will pass the name of the table into the procedure.
Also in the procedure you may want to recompile the schema, so after the view is created do:
sys.utl_recomp.recomp_parallel(4, 'XYZ');
If you develop a script of some sort which can semi automate, it makes things easy.
Hope this helps...
I have created a table using a 'AS SELECT' statement.
CREATE TABLE TEST AS
SELECT ...
from (MANY TABLES)
WHERE (MANY CONDITIONS);
How do I make sure that updates on any of the table columns go onto TEST as well?
Or do I have to use a VIEW? (which I dont want to as there is a need of a trigger to be working on TEST)
Are any other options available other than using a VIEW ?
You need to create a View.
CREATE TABLE AS SELECT just make a copy of data at the moment of execution.
Look into creating the table test as a materialized view.
Triggers can be placed on these and there are various update options too.
Depending on your database system you could use a Trigger to insert the values in the other table as well. That's if you need something like near-realtime syncronization. Or you might go for a daily/weekly/... batch synchronization.
As I am not so familiar with Oracle you should look at their documentation for a detailed description.