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.
Related
Table will be getting new data everyday from source system and i want the duplicates to be deleted automatically as soon as new data gets loaded to table.
Is it possible in bigquery?
I tried to create a view named sites_view in bigquery with below query
SELECT DISTINCT * FROM prd.sites
but duplicates not getting deleted automatically.
Below is for BigQuery:
Duplicates will not be deleted automatically - there is no such functionality in BigQuery
You should have some process to make this happen as frequently as you need or use views
Bigquery is based on append-only kind of a design. So, it accepts all the data.
This is one of the reasons there are no Primary/Unique key constraints on it, so you can't prevent duplicates from entering in the table.
So, you have to have a process like:
1.) Create a new table without duplicates from your original table.
(You can use DISTINCT/ROW_NUMBER() for doing this.)
2.) Drop original table.
3.) Rename new table with original table name.
Let me know if this information helps.
Can anyone please share the steps to hide the particular column from the table in SQL Server 2012 as I don't want to delete that column
By hide I mean that whenever I use the select query against that particular table it should never show me that column.
Is it possible?
I need to make the column as hidden irrespective of any user login and whatever query i use
3rd party edit
Based on the comment But the problem is whenever i open the table in sql i dont want to see that particular column i assume that the question is:
How can i configure ssms so that opening a table definition inside sql management studio to only show the columns the connected user has select right to?
The screenshot below shows all columns of the table Employee despite the fact that the login StackoverIntern has no select rights to the columns SSN, Salary
Late post but I think its worth to share
Earlier to SQLSERVER-2016 there was no any option to hide few columns from table when selecting *, however SQLSERVER-2016 come up with HIDDEN keyword by which you can now set columns hidden from Select * which you don't want to show and want only for some background process of your business logic.
The HIDDEN property is optional and will hide these columns
from a standard SELECT statement for backward compatibility with our
application and queries. You cannot apply the HIDDEN property to an existing column
.
you can alter existing table as well lets take an example of existing table
ALTER TABLE [dbo].[Account] ALTER COLUMN [StartDate] ADD HIDDEN;
ALTER TABLE [dbo].[Account] ALTER COLUMN [EndDate] ADD HIDDEN;
You can check this concept used more often in Temporal table
you can find more on this in below Temporal Table
You can use column level permissions so that targeted users cannot select on that column. However, this will not "hide" the column in the case of doing a SELECT * or SELECT SpecialColumn. Instead, it will fail the query, resulting in an error.
An alternative to allow easier queries, you can make a View that does not include this column:
create view MyTableEx As
SELECT Every, Other, Column
FROM MyTable
Then only grant SELECT permissions to the View, rather than the table, for certain users. However, this is still problematic for an application, which now has to know whether it should select from the Table or the View.
When it comes down to it, column level permissions are kind of an unnatural thing to do in a database.
If you do not want the column to show, then you should not include it in you select statement. It is also more efficient to not use an asterisk (*) in your select statement.
See this post for more info in the performance issue:
Performance issue in using SELECT *?
I have got a rather basic question but I could not find a confirmation about it online. When you create a view like the one below
create view report AS
select employee_id
from employees
It will store the data in a virtual table. That's ok. But when you add additional employee ids AFTER you have created the view will they be displayed when you run the view again? Cuz what I need is basically some view that will display the latest records I have added in the tables. Is that possible?
Short answer is Yes, it will update....
Ok, so Views don't quite "store" data, they just present data in a different format or select certain columns from a table to create your own "view" of the data.
If you are just looking to find the most recent employee ids through a view, I would recommend adding a column with a created or modified date field defaulting to the date entered. Then have your table do an Order By the datefield descending and select only top few rows so you only get recent records. The way to do this is slightly different depending on if you are using SQL, Oracle, or MySQL.
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 :-)
Say I'm mapping a simple object to a table that contains duplicate records and I want to allow duplicates in my code. I don't need to update/insert/delete on this table, only display the records.
Is there a way that I can put a fake (generated) ID column in my mapping file to trick NHibernate into thinking the rows are unique? Creating a composite key won't work because there could be duplicates across all of the columns.
If this isn't possible, what is the best way to get around this issue?
Thanks!
Edit: Query seemed to be the way to go
The NHibernate mapping makes the assumption that you're going to want to save changes, hence the requirement for an ID of some kind.
If you're allowed to modify the table, you could add an identity column (SQL Server naming - your database may differ) to autogenerate unique Ids - existing code should be unaffected.
If you're allowed to add to the database, but not to the table, you could try defining a view that includes a RowNumber synthetic (calculated) column, and using that as the data source to load from. Depending on your database vendor (and the products handling of views and indexes) this may face some performance issues.
The other alternative, which I've not tried, would be to map your class to a SQL query instead of a table. IIRC, NHibernate supports having named SQL queries in the mapping file, and you can use those as the "data source" instead of a table or view.
If you're data is read only one simple way we found was to wrapper the query in a view and build the entity off the view, and add a newguid() column, result is something like
SELECT NEWGUID() as ID, * FROM TABLE
ID then becomes your uniquer primary key. As stated above this is only useful for read-only views. As the ID has no relevance after the query.