I have a question about creating views in general.
If I have one table "table1" that has two columns, "code" and "value" is it possible to create a view "view1" that has the same data as table1 but just renames the columns to something different like "table1.code" and "table1.value" ? I kno this is a pretty simple question but I havent found much on it. Thanks!
You can alias the columns in the query behind your view. For example, your query might be like below...
SELECT code as table1.code, value as table1.value FROM table1
The exact syntax for creating a view is different depending on the vendor, which you didn't include in your question. But you can alias the columns in a query in almost any implementation, including SQL Server, Oracle, MySql, etc.
Using an alias is as simple as typing the AS keyword, followed by whatever you want to alias the column name as.
Related
I'm working on some current, and archived SQLite databases.
In current versions, a column is named message, but in the archived versions it's named message_id.
The query I'm running is pretty lengthy/complex, and it's just this one column that's changed. Is there any way I can do some kind of CASE EXISTS style query to do this, or am I just going to have to write a separate query?
I would suggest writing a view to access the historical data:
create view v_message_history
select message as message_id, . . .
from message_archive;
Then you can use the view and the two columns have the same name.
You could also use alter table to rename the column in either the history or current table. I am guessing, though, that you don't want to do that because it might break existing code.
I have a sql query (used with MS Access and C#) that in the where clause references table name with the column, that causes an error. When I remove the table name, it works fine, but it would seem like if you are more specific, it would work better?
Anyone have any ideas why that is?
SQL query in question:
SELECT profiles.profile_id,
profiles.full_name,
shifts.start,
shifts.stop,
shifts.start_log,
shifts.stop_log,
shifts.start_notes,
shifts.stop_notes
FROM shifts,
profiles
WHERE profile.full_name=#full_name AND
shifts.profile_id=profiles.profile_id;
I had to change "profile.full_name=#full_name" in the WHERE clause to "full_name=#full_name" i.e. remove the table name "profile".
This question came from another SO question found here
Your query pulls information from a table named profiles, so profile.full_name is not defined because there is no table (or alias) named profile in the query. profiles.full_name would probably work better.
I can't seem to get all the table names that a view is trying to use.
Currently, I am using INFORMATION_SCHEMA.VIEW_COLUMN_USAGE to find which tables are used. But, it only finds tables that currently exist. I want to find out if that view is trying to use tables that don't exist.
View_Column_Usage will only find columns that are used in the view. You can check to see if those columns are in any of the current tables columns to find which columns aren't used, but you can't find which tables aren't used.
Does anyone know a table I can use to find which tables are used in a view, but do not exist?
As far as I know there is no such a thing that stores the information of the not existed objects, simply because they don't exists! I believe that my recommendation is not the exact solution but I think it will help you through the way:
Select *
From INFORMATION_SCHEMA.VIEWS
Left Outer Join
sys.objects
On objects.type = 'U'
And views.view_definition Like '%' + objects.name + '%'
Where objects.name Is Null
Cheers
The script I found here seems to work to find the views that are broken.
http://www.sqlservercentral.com/Forums/Topic785213-146-1.aspx#bm785697
I have two tables. The field names in the projects table are stored in the fieldname table
Projects Table
RecordID, ProjectID, Field1, Field2, Field3, Field4,...,Field20
FieldNames Table
FieldNameID, ProjectID, FieldNumber, FieldName
Is it possible to return results from the Projects table where the field name is actually FieldNames.FieldName? Can you concatenate 'Field'+FieldNames.FieldNumber to return the Fieldname and then use that as the alias for Field(x) in Projects?
i.e.: instead of "Field1" it would be FieldNames.FieldName where Projects.ProjectID=FieldNames.ProjectNames and FieldNumber=1
You can do this with dynamic SQL, or a huge case statement that maps values to fields, or by creating a view that contains each combination and you use the appropriate code in the where clause to get the right rows.
However, in my opinion you are going down completely the wrong path, and helping you go farther without dire warning would be completely irresponsible. So here goes:
The database design you're using is a truly awful design anti-pattern and violates best practice in a particularly smelly way (like "code smell", you have "database smell"). Do not store column names in columns. It is wrong. It will hurt. It will make your database evil. Professionals will secretly and loudly laugh at it. I am deadly serious.
In sqlite3, I can force two columns to alias to the same name, as in the following query:
SELECT field_one AS overloaded_name,
field_two AS overloaded_name
FROM my_table;
It returns the following:
overloaded_name overloaded_name
--------------- ---------------
1 2
3 4
... ...
... and so on.
However, if I create a named table using the same syntax, it appends one of the aliases with a :1:
sqlite> CREATE TABLE temp AS
SELECT field_one AS overloaded_name,
field_two AS overloaded_name
FROM my_table;
sqlite> .schema temp
CREATE TABLE temp(
overloaded_name TEXT,
"overloaded_name:1" TEXT
);
I ran the original query just to see if this was possible, and I was surprised that it was allowed. Is there any good reason to do this? Assuming there isn't, why is this allowed at all?
EDIT:
I should clarify: the question is twofold: why is the table creation allowed to succeed, and (more importantly) why is the original select allowed in the first place?
Also, see my clarification above with respect to table creation.
I can force two columns to alias to the same name...
why is [this] allowed in the first place?
This can be attributed to the shackles of compatibility. In the SQL Standards, nothing is ever deprecated. An early version of the Standard allowed the result of a table expression to include columns with duplicate names, probably because an influential vendor had allowed it, possibly due to the inclusion of a bug or the omission of a design feature, and weren't prepared to take the risk of breaking their customers' code (the shackles of compatibility again).
Is there any use to duplicate column names in a table?
In the relational model, every attribute of every relation has a name that is unique within the relevant relation. Just because SQL allows duplicate column names that doesn't mean that as a SQL coder you should utilise such as feature; in fact I'd say you have to vigilant not to invoke this feature in error. I can't think of any good reason to have duplicate column names in a table but I can think of many obvious bad ones. Such a table would not be a relation and that can't be a good thing!
why is the [base] table creation allowed to succeed
Undoubtedly an 'extension' to (a.k.a purposeful violation of) the SQL Standards, I suppose it could be perceived as a reasonable feature: if I attempt to create columns with duplicate names the system automatically disambigutes them by suffixing an ordinal number. In fact, the SQL Standard specifies that there be an implementation dependent way to ensure the result of a table expression does not implicitly have duplicate column names (but as you point out in the question this does not perclude the user from explicitly using duplicate AS clauses). However, I personally think the Standard behaviour of disallowing the duplicate name and raising an error is the correct one. Aside from the above reasons (i.e. that duplicate columns in the same table are of no good use), a SQL script that creates an object without knowing if the system has honoured that name will be error prone.
The table itself can't have duplicate column names because inserting and updating would be messed up. Which column gets the data?
During selects the "duplicates" are just column labels so do not hurt anything.
I assume you're talking about the CREATE TABLE ... AS SELECT command. This looks like an SQL extension to me.
Standard SQL does not allow you to use the same column name for different columns, and SQLite appears to be allowing that in its extension, but working around it. While a simple, naked select statement simply uses as to set the column name, create table ... as select uses it to create a brand new table with those column names.
As an aside, it would be interesting to see what the naked select does when you try to use the duplicated column, such as in an order by clause.
If you were allowed to have multiple columns with the same name, it would be a little difficult for the execution engine to figure out what you meant with:
select overloaded_name from table;
The reason why you can do it in the select is to allow things like:
select id, surname as name from users where surname is not null
union all
select id, firstname as name from users where surname is null
so that you end up with a single name column.
As to whether there's a good reason, SQLite is probably assuming you know what you're doing when you specify the same column name for two different columns. Its essence seems to be to allow a great deal of latitude to the user (as evidenced by the fact that the columns are dynamically typed, for example).
The alternative would be to simply refuse your request, which is what I'd prefer, but the developers of SQLite are probably more liberal (or less anal-retentive) than I :-)