Oracle : 2 column names for a single column

Question

There is a requirement to rename the DB tables and column names, so all the tools/application taking data from the source will have to change their queries. The solution we are planning to implement is that for every table name change we will create a VIEW with the original table name. Easy and simple to implement. No query change required, but there are cases where a table name remains the same but a column name changes within the table, so we can't create another view (any object with the same object name).

Is there a Column Synonym kind of thing which we can propose here? Any solutions/ideas are welcome. Requirement is to have queries containing original column names referring to the new columns in the same tables.

For example:

Table Name:            DATA_TABLE
Existing Column Name:  PM_DATE_TIME
New Column Name:       PM_DATETIME

Existing Query select pm_Date_time from Data_Table; should refer to new column pm_Datetime

Answer 1

You could consider renaming your original table, and then create a View in its place providing both the old and the new column-names:

CREATE TABLE Data_Table ( pm_Date_time DATE );

ALTER TABLE Data_Table RENAME TO Data_Table_;

CREATE VIEW Data_Table AS
(
  SELECT pm_Date_time,
         pm_Date_time AS pm_Datetime  -- Alias to provide the new column name
  FROM Data_table_
);

-- You can use both the old columnn-name...
INSERT INTO Data_Table( pm_Date_time ) VALUES ( SYSDATE );

-- ... or the new one
UPDATE Data_Table SET pm_Datetime = SYSDATE;

There are things that won't work the same way as before:

-- INSERT without stating column-names will fail.
INSERT INTO Data_Table VALUES ( SYSDATE );

-- SELECT * will return both columns (should not do this anyway)
SELECT * FROM Data_Table

Once you are done with your changes drop the view and rename the table and the columns.

Answer 2

You'll want to add virtual columns:

ALTER TABLE Data_Table ADD pm_Date_time as (pm_Datetime);

UPDATE: Oracle (11g at least) doesn't accept this and raises "ORA-54016: Invalid column expression was specified". Please use Peter Lang's solution, where he pseudo-adds zero days:

ALTER TABLE Data_Table ADD (pm_Datetime + 0) AS pm_Date_time;

This works like a view; when accessing pm_Date_time you are really accessing pm_Datetime .

Rextester demo: http://rextester.com/NPWFEW17776

And Peter is also right in this point that you can use it in queries, but not in INSERT/columns or UPDATE/SET clauses.

Answer 3

This was basically touched on in the answer by Thorsten Kettner, but what your looking for is a pseudocolumn.

This solution looks a little hacky because the syntax for a pseudocolumn requires an expression. The simplest expression I can think of is the case statement below. Let me know if you can make it more simple.

  ALTER TABLE <<tablename>> ADD (
   <<new_column_name>> AS (
    CASE
      WHEN 1=1 THEN <<tablename>>.<<old_column_name>>
    END)
  );

This strategy basically creates a new column on the fly by evaluating the case statement and copying the value of <old_column_name> to <new_column_name> . Because you are dynamically interpolating this column there is a performance penalty vs just selecting the original column.

One gotcha here is that this will only work if you are duplicating a column once. Multiple pseudocolumns cannot contain duplicate expressions in Oracle.

Answer 4

we cant create a another view (any object with the same object name).

That's true within a schema. Another somewhat messy approach is to create a new user/schema with appropriate privileges and create all your views in that, with those querying the modified tables in the original schema. You could include instead-of triggers if you need to do more than query. They would only need the old columns names (as aliases), not the new ones, so inserts that don't specify the columns (which is bad, of course) would still work too.

You could also create synonyms to packages etc. in the original schema if the applications/tools call any and their specifications haven't changed. And if they have changed you can create wrapper packages in your new schema.

Then your legacy tools/applications can connect to that new schema and if it's all set up right will see things apparently as they were before. That could potentially be done by setting current_schema , perhaps through a login trigger, if the way they connect or the account they connect to can't be modified.

As the tools and applications are upgraded to work with the new table/column names they can switch back to the original schema.