It's probably a silly question but it is straight forward.
Is it possible to create a view from an existing view?
Let's say I've tableA. I create vwtableA from tableA and now I want to create vvVwtableA from vwtableA.
In pseudo-code it would be something like:
create view vwA as select * from tableA;
create view vwvwA as select * from vwA;
is this possible?
I'm trying something like this and I get no MySQL errors executing the statment but I can't browse the second view... MySQL Workbench keeps loading for ever and I don't know if this may be the cause.
My tableA has around 100 000 records, vwA has around 50 000 records and vwvwA should have around 50 000 as well.
Yes, it is possible. See MySQL documentation
The select_statement is a SELECT statement that provides the definition of the view. (When you select from the view, you select in effect using the SELECT statement.) select_statement can select from base tables or other views
just make a copy of your first view (vwA) and create a new one (vwvwA) . Simple this way. ;-)
Related
Right now, I'm altering a table with a crap ton of data, which is going to take weeks to run. In the meantime, I figured I'd create a new table to write to while this one is locked.
I can create an empty table and just write to this one, and check both tables when reading. Or I can create a copy of the current table and do all reads/writes from this copy for the next month.
It looks like copying the table is not the best solution. What about creating a view (just to read from) combining both tables?
CREATE VIEW MY_TABLE_VIEW AS
SELECT * FROM MY_TABLE
UNION ALL
SELECT * FROM MY_TABLE_COPY
Would creating the view be just as expensive as altering the original table? Should I instead just change all my table reads to UNION ALL the results from both tables?
Creating a view is a metadata-only operation. Views don't store any data. Querying the view will actually query the base table as if you ran the query in the view definition. So there's practically nothing to do to create the view. It only stores the query as metadata.
How I see into MsSql sys.sysprocesses
can I modify it?
Example :
select count(spid) from master.dbo.sysprocesses
The result will be what I want
As Dan has stated, sys schema objects cannot be modified, you will get an error if you try to do so.
The sys.sysproccesses view can be queried using the statement you have posted from a query window and will return results
select count(spid) from master.dbo.sysprocesses
If you are really wanting to "modify" which I assume means you want to update values, drop rows and such, you can add to a temp table and modify that but the data is a copy so anything you do will not affect the underlying view
SELECT *
INTO #MyTable
FROM sys.sysprocesses
sysprocesses is a view and a legacy one at that. One cannot modify system objects.
You can create your own view to encapsulate DMV queries:
CREATE VIEW dbo.YourView
SELECT COUNT(session_id) AS SessionCount
FROM sys.dm_exec_sessions;
GO
I'm using this to create a view of a query in mySQL:
create view services_view as
SELECT `innovation_name`,`link`,`category`,`brief_description` FROM `innovation_db`
WHERE `category`= "Service"
This ends up making a view with all the right columns, but there's no data. If I just run the query without the create view, it displays all the right data.
What am I doing wrong here?
Thanks for any advice.
You then need to run
SELECT * FROM services_view
to retrieve data.
I was wondering is there a performance difference between:
query 1: CREATE TEMPORARY TABLE temp_table1 AS SELECT * FROM lookup_table JOIN ...
then
INSERT INTO dest_table SELECT * FROM temp_table1
vs
query 2: INSERT INTO dest_table SELECT * FROM lookup_table JOIN ...
My concern was, the lookup_table is accessed very often by different users and when I run query 2, most of the users need to wait longer to be able to retrieve their result. What I was thinking was to write the data into a temporary table then write it to dest_table afterwards . Im just not sure if writing into a temp table with give a difference performance compared to writing it directly to the destination table. Im using mysql 5.6.
The reason why I need to write data from lookup_table to dest_table is because I need to create a report from it. Seeing how complex the query from lookup_table is makes it very difficult to create a report so I decided to move those data to a single table then just make a report from it.
You're concerned about the lockout time that's taken by the SELECT query that populates this temporary table.
The tables are implemented the same way, so the cost of creating will be very close to the same in either case.
You might be able to get it to go a little faster by creating your temporary table in the MEMORY access method, but I suspect the difference will be minimal; the work involved here is the SELECT / JOIN stuff.
You might be able to get it to go faster by making sure your target table has no indexes when you create it. CREATE ... AS SELECT will do that.
You will be able to make it cheaper to create by getting rid of SELECT * (which yields redundant columns on JOINs anywhow), and instead specify the columns you really need.
But, your best bet is to figure out why you're creating this table, and see if you can deliver on those requirements by writing queries against the source tables instead. If you make those query operations efficient, you've saved yourself lots of data shuffling.
Is it possible to use the create table query (create table t2 like t1) to get the query instead the actual table? Kind of like duplicating some management consoles Send To editor feature?
I think you're looking for SHOW CREATE TABLE tablename;
'tablename' can be the table within the current database, if you've selected one, or you can qualify it as in 'dbname.tablename'. The output can be used to create the table again. In fact, I sometimes use it in scripts that need to either use an existing table or create it if it doesn't exist. First I'll get the table creation info as shown above, and then I'll use something like"
CREATE TABLE IF NOT EXISTS tablename .........
Where '..........' is all the goodies that SHOW CREATE TABLE tablename gives me.
If you're interested in a good tutorial on MySQL (the database), as well as SQL (the language), you might have a look at the O'Reilly book, Learning MySQL. It's pretty good.