Is it possible to find the name of the table for which a column in a MySQL view belongs?
If a view was constructed as
CREATE VIEW alpha_view AS
SELECT alpha.col1, alpha.col2, beta.col2 FROM alpha
INNER JOIN beta
ON alpha.col1=beta.col1;
then when I edit, I want to only affect alpha.col1 and alpha.col2 as beta.col2 is derived from another table.
I assumed the easiest way of knowing whether it's editable or not comes from knowing if the original table matches the view's FROM clause.
Is this even possible, or should I just make a list of editable columns for my parsing script?
Yes, it is possible. Just use aliasing (via AS keyword) to give different name for result column.
CREATE VIEW alpha_view AS
SELECT alpha.col1 AS a_col1, alpha.col2 AS a_col2, beta.col2 AS b_col2 FROM alpha
INNER JOIN beta
ON alpha.col1=beta.col1;
Related
When you create a view with
CREATE VIEW view1 AS SELECT * FROM table1
mysql changes this internally to
CREATE VIEW view1 AS SELECT f1, f2, f3 FROM table1
If you add a new column f4 to table1, view1 still has only the first 3 columns. You have to recreate your view. This is annoying, if you have a lot of views.
Is there a way to make mysql to save SELECT * in the view declaration so it always selects all the fields no matter if the table has changed?
MySql has a right behaviour.
When you create a view as SELECT * FROM table1, MySql changes your code with a full list of fields.
When you change your table structure, the view must be changed by user.
If exists this automatic behaviour you can create an issue of performance when you use a view.
Suppose you add 50 fields, and you use your view in a form, you can change the data load from 3 to 53 fields. No good.
So this behaviour is correct.
Long story short, no. This is how MySQL handles views internally.
Pro tip: don't use views. It's a poor man's way of hiding unnecessary complexity behind another complexity. It's way better to simply do plain query, MySQL performs better that way.
A MySql View does not use for return a complete definition of a table it's basic use to return a part of the tables with a specification or marge data.
Views would not be of much use without it.The principle also applies if you select from a view that selects from the table if the view selects from the table in a subquery and the view is evaluated using the merge algorithm.View processing is not optimized.
You can see this blog to know what is right with a view to MySql.View Restrictions
I am new to SQL and am currently doing a project on MSQL 2019.
I have one table with a list of codes mapping a "Loss ID" to a Reason.
Now I have another table that just gives you the number of the Loss ID but not the text version of it.
How can I create a table that will take the number code and automatically change it to the text version of it?
Im not even sure what this type of scripting is called, so even pointers on what to google or look for would be very useful.
Rather than creating another table use a view.
Let's call your tables tbl1 and tbl2. The view would be:
CREATE VIEW my_view AS SELECT tbl2.your_date_column,
tbl2.LossID,
tbl1.reason
FROM tbl1
INNER JOIN tbl2 on tbl1.LossID=tbl2.LossID;
Lear more about VIEWS https://www.mysqltutorial.org/create-sql-views-mysql.aspx
I'm trying to get zip codes from zip_id's which are internally stored in companies service table below screens will give you clear idea
I have wrote this query
companies service table
Please suggest me your valuable views . Thanks in advance.
As already mentioned your database scheme is not very well designed, it violates even 1st normal form. You'd need another table where you'd store serv_area_id and zip_code (with possibly multiple rows for a signle serv_area_id) and search within this table and eventually join your original table.
Nevertheless, in order to get the result you describe you cannot use the IN operator as it operates on a value and multiple values in a form of table (either explicit via nested SELECT or enumeration literal (val1, ..., valN)). I would try some string matching as illustrated below. However, consider it rather an ugly hack than correct solution(!)
SELECT zip FROM cities_extended WHERE (
SELECT GROUP_CONCAT(',', serv_are_zipcodes)
FROM company_service_areas WHERE ...
) LIKE concat('%(', id, ')%')
I've grown quite fond of the usefulness of CREATE VIEW. It for instance allows me to have global and specific values through COALESCE(post.publish, profile.publish) so that if publish is NULL, the global value gets fetched instead.
The part I'm a bit curious about from both perfomance and logical perspective, is how I should use this alongside the existing table. Lets say I have a table:
CREATE TABLE post (
id INT,
profile_id INT,
name VARCHAR,
publish ENUM('TRUE', 'FALSE') NULL
)
Would a CREATE VIEW be best to run like:
CREATE VIEW post_info AS
SELECT post.*, COALESCE(post.publish, profile.publish) AS publish
FROM post
INNER JOIN profile
ON post.profile_id = profile.id
And only use post_info in SELECT cases, or:
CREATE VIEW post_info AS
SELECT post.id, COALESCE(post.publish, profile.publish) AS publish
FROM post
INNER JOIN profile
ON post.profile_id = profile.id
And JOIN post_info with post in SELECT when extra values are needed?
Please share your insights and thoughs regarding this. I would like to hear your input to positives and drawbacks of each solution. Can also be one I haven't mentioned.
It really depends on how you will use the views. It should be worth mentioning that there are two methods MySQL can process a query that refers to a view, and the method used depends on the view declaration's ALGORITHM clause.
For the lack of a better phrasing, I will reproduce the manual:
For [ALGORITHM =] MERGE, the text of a statement that refers to the view and the
view definition are merged such that parts of the view definition
replace corresponding parts of the statement.
For TEMPTABLE, the results from the view are retrieved into a
temporary table, which then is used to execute the statement.
For UNDEFINED, MySQL chooses which algorithm to use.
The MERGE algorithm usually allows faster processing of the final query, however there are many cases where MySQL is unable to use it (see the linked manual page for more details).
So the answer is: if your view is not defined with ALGORITHM = TEMPTABLE and if the wrapping query does not prevent the use of the MERGE algorithm, the version with SELECT *, and without an extra JOIN, is better.
Otherwise, if MERGE is not used, the second solution could be better.
As a side note, to adress the use case you mention, a better option would be to have your application layer fill the post.publish with the value in profile.publish at insertion time, and get rid of the JOIN as well as the view. Alternatively, the same effect can be achieved by placing a suitable trigger on the table.
I am trying to use the results of another query to use as a criteria for another. In my specific example, I might have four houses that are 'A', 'B', 'C', 'D' (the unique values of a field in a table called Homes).
I want to go through another query and say for each house type, what percent of residents (in Residents table) are married, which I want to do by using Count() to count the number for each Home type.
Do I need to loop through the results using VBA? Asking on a higher level, is there a way to use the results from a query as inputs into another - more than just limit the results of the new query to the results of the prior query?
Edit:
In semi-pseudo code:
For each (result of previous query) Do
New query WHERE field1 = (row of previous query)
End Do
What I am trying to ask, is there a way to accomplish this in Access using SQL? Or is this something that has to be done in VBA?
I know that if it can be done in SQL that would be the best performing and best practice, but I'm relatively inexperienced in SQL and online resources aren't always helpful because Access has it's own particular flavor of SQL.
Since you are using VBA to run this, you can loop through your recordsets and yes you can use a value from one query in the next query. There are alot of resources out there to help.
VBA: Working with RecordSets
Looping through Record Sets
Code through all records
To answer your general question, yes there is. You can do a nested query i.e. select column a from table a where column a = (select column b from table b where column b=x)
You can go as many levels deep as you want, but the caveat is the nested query can only return one column and with a specific answer set. You can also use select statements as your columns i.e
select (select column b from table b) col b from table a ..... Not the exact syntax but I would have to dig out some examples from an old project to find that.
Nested queries are useful, but for the level of precision you are looking for, a stored procedure or a view is probably a better option. Just for ease of use, I would look at creating a view of the data that you want and then querying from that to start with. More flexible than a nested query.
You need to join two tables using a common column and then get your specific column from any of the table
SELECT A.REQUIRED_FIELD from TABLEA AS A
INNER JOIN TABLEB AS B ON A.FOREIGN_KEY=B.FOREIGN_KEY
WHERE CONDITION