given a table
create table mymy(A int(2),B int(2))
is it possible to use a field value as an alias? Something like (not really):
select A as valueOf(B) from mymy.
No. You can't. The values are not known until the query is run. And even if you could, you'd have a lot of possibly different values in one column. Which one should be used?
The only valid reason I can imagine for such a request is that you have some kind of EAV design and you want to have a Pivot result.
If that's the case, you could use Dymanic SQL (run a query, get the results, build another query based on those results and run that one.) But this kind of operations is better done at the application side (get the results and format them there, as you prefer).
Related
Is it possible to create a custom function in MySQL like SUM, MAX, and so on. That accepts multiple columns and do some operation on each row?
The reason I am asking this question is because I tried to do my logic using stored procedure but unfortunatelly couldn't find a way how to select data from table name where the name of the table is input parameter.
Somebody suggested to use dynamic SQL but I can not get the cursor. So my only hope is to use custom defined function.
To make the question more clear here is what I want to do:
I want to calculate the distance of a route where each row in the database table represents coordinates (latitude and longtitude). Unfortunatelly the data I have is really big and if I query the data and do the calculationgs using Java it takes more than half a minute to transfer the data to the web server so I want to do the calculations on the SQL machine.
Select something1, something2 from table_name where table name is a variable
Multiple identically-structured tables (prerequisite for this sort of query) is contrary to the Principle of Orthogonal Design.
Don't do it. At least not without very good reason—with suitable indexes, (tens of) millions of records per table is easily enough for MySQL to handle without any need for partitioning; and even if one does need to partition the data, there are better ways than this manual kludge (which can give rise to ambiguous, potentially inconsistent data and lead to redundancy and complexity in your data manipulation code).
I have done the SQL beginners and advanced courses at W3Schools successfully, and cannot find any other free advanced onine SQL course. I am having a problem with the SQL syntax in the accepted answer in this SO thread, covering the calculation of the median value of a column. My questions are:
After 'from' come two variables. Does that mean that data are selected from two tables, and if so, how would the formula be if I just require the median value of one column of one table?
The OP/TS named this columns 'id' and 'val'. Why then is 'x.val' selected?
The SELECT x.val from data x, data y means to cross-join table data with itself. I'm pretty sure it eventually just finds the median for one column, and this is a trick to help calculate that median.
To understand this better (and note that I don't totally understand it), try this:
Set up a table with some sample data - say 5-8 rows to begin with
Promote the HAVING values to the SELECT list
Get rid of the HAVING clause
So your query will look something like this:
SELECT x.val, SUM(SIGN(1-SIGN(y.val-x.val))), (COUNT(*)+1)/2
FROM data x, data y
GROUP BY x.val
Then take a look at the results and you'll be able to get more insight into the logic. Also see if you can follow the calculation when you track it row by row.
Finally, note that the query isn't so much advanced as it is specialized. I mean, it is advanced and all, but it's the math gymnastics rather than the query semantics that are probably giving you trouble. Don't sweat it if you don't understand this right off the bat :)
As for why val is selected - that's the column the OP is trying to calculate the median for. The id is probably there because it's generally a good idea to have a PK on every row. It's not needed for the calculation so it's not included in the query.
I have a large database w/ a bunch of tables and columns are mixed some allowing NULL while others not allowing NULL..
I just recently decided to STANDARDIZE my methods and USE NULL for all empty fields etc.. therefore i need to set ALL COLUMNS in ALL my tables to allow NULL (except for primaries ofcourse)
I can whip up a php code to loop this , but i was wondering if there's a quick way to do it via SQL?
regards
You can use meta data from system tables to determine your tables, columns, types etc. And then using that, dynamically build a string that contains your UPDATE SQL, with table and column names concatented in to it. This is then executed.
I've recently posted a solution that allowed the OP to search through columns looking for those that contain a particular value. In lieu of anyone providing a more complete answer, this should give you some clues about how to approach this (or at least, what to research). You'd need to either provide table names, or join to them, and then do something similar as this except you'd be checking type, not value (and the dynamic SQL you build would build an update, not a select).
I will be in a position to help you with your specific scenario further in a few hours... If by then you've had no luck with this (or other answers) then I'll provide something more complete then.
EDIT: Just realised you've tagged this as mySql... My solution was for MS SQL Server. The principals should be the same (and hence I'll leave this answer up as i think youll find it usefull), assuming MySql allows you to query its metadata, and execute dynamically generated SQL commands.
SQL Server - Select columns that meet certain conditions?
Based on this question here Selecting NOT NULL columns from a table One of the posters said
you shouldn't use SELECT * in production.
My Question: Is it true that we shouldn't use Select * in a mysql query on a production server? If yes, why shouldn't we use select all?
Most people do advise against using SELECT * in production, because it tends to break things. There are a few exceptions though.
SELECT * fetches all columns - while most of the times you don't
need them all. This causes the SQL-server to send more columns than
needed, which is a waste and makes the system slower.
With SELECT *, when you later add a column, the old query will also
select this new column, while typically it will not need it. Naming
the columns explicitly prevents this.
Most people that write SELECT * queries also tend to grab the rows
and use column order to get the columns - which WILL break your code
once columns are injected between existing columns.
Explicitly naming the columns also guarantees they are always in the same order, while SELECT * might behave differently when the table column order is modified.
But there are exceptions, for example statements like these:
INSERT INTO table_history
SELECT * FROM table
A query like that takes rows from table, and inserts them into table_history. If you want this query to keep working when new rows are added to table AND to table_history, SELECT * is the way to go.
Remember that your database server isn't necessarily on the same machine as the program querying the database. The database server could be on a network with limited bandwidth; it could even be halfway across the world.
If you really do need every column, then by all means do SELECT * FROM table.
If you only need certain columns, though, it would waste bandwidth to ask for all columns using SELECT * FROM table only to throw half the columns away.
Other potential reasons it might be good to specify which exact columns you want:
The database structure may change. If your program assumes certain column names, then it may fail if the column names change, for example. Explicitly naming the columns you want to retrieve will make the program fail immediately if your assumptions about the column names are violated.
As #Konerak mentioned, naming the columns you want also ensures that the order of the columns in your result is the same, even if the table schema changes (i.e. inserting one column in-between two others.) This is important if you're depending on FirstName being the [2]nd element of a result.
(Note: a more robust and self-documenting way of dealing with this is to ask for your database results as a list of key-value pairs, like a PHP associative array, Perl hash or a Python dict. That way you never need to use a number to index into the result (name = result[2] ) - instead you can use the column name: name = result["FirstName"].)
Using SELECT * is very inefficient, especially for tables that have a lot of columns. You should only select the columns you need.
Besides this, using column names makes the query easier to read and maintain.
Through a webservice my application receives a list of identifiers.
With this list, I have to look up a field, one per identifier.
If the field does not exist, the value should be null (it has to be shown).
I am wondering what would be the best approach. First I thought it was best to create a temporary table holding the id's and then joining it to the table holding the data, but if I'm correct this takes at least 1 query per identifier to insert it in the temporary table.
In that case, it seems that I could just as well iterate through the list of identifiers in my application and query the database 1 by 1. Is this correct?
Which approach can you advise?
greetings,
coen
Use the SELECT WHERE IN() Syntax to get a result set with the data you need, then iterate over it in your code. This way you only query the DB once and only get the information you need.
Showing nulls is the trick, you need to join the table to itself, so there are two index lookups per record. Just doing a 1-to-1 query for each identifier will only require one index lookup.
In practice, it won't be twice as slow, since the identifier will be in the key cache by the time the second lookup is executed.
Another option is to render your output using the input identifiers, and use an "IN" like previously suggested. The null records won't be in the query output, but that would be ok since you know what was requested.