Search code examples
sqlrefactoring-databases

How to rename SQL table column name(s) and not break stuff

I revisited some of my code from my beginner days and found that some of the SQL table column names are so ambiguous it made me cringe.

Now If I go ahead and change the names, the time and effort required to correct all the mappings in the code doesn't seem justifiable at this point.

I was wondering if its possible to provide an alias at all when inserting to the DB?

I ask because you can use an alias on a SELECT like this:

SELECT users.id, username, number AS order_number FROM users INNER JOIN orders ON users.id = orders.user_id;

Or does anyone have any other suggestions on how I can accomplish this?

Solution

  • While refactoring a database is no doubt a large and risk activity here are some tips to mitigate risk. Below are some suggestions with various pros and cons (as I see the them) hopefully they will help.

    Code

    Depending on your programming language, comfort and time frame you can replace inline direct SQL with a RDBMS independent object relational mapper like Hibernate / NHibernate etc.

    Pros

    • Provides abstraction for future database refactoring.
    • May provide improvements and re-usability.
    • Reduces any SQL injection attacks.

    Cons

    • A lot of effort and risk in rewiring your code base, but you can do this in a piecemeal approach.
    • Not suitable for every type of application / service (E.G., reports).

    Stored Procedures

    Depending on your RDBMS you can provide abstraction and additional security to the underlying data and schema using stored procedures.

    Pros

    • More code to maintain.
    • Not easily testable, although depending on your RDBMS there are plenty of database testing frameworks which should include SP coverage.
    • Improved data security and reduces the risk of SQL injection attacks assuming that you're not constructing any dynamic SQL in your stored procedures.

    Cons

    • Can be abused to intertwine your data access with domain / business logic.
    • You'll still need to update your code base to use the stored procs.

    Views

    You could rename your existing table(s) Users and Orders to something else and use a view to offer the column name abstraction.

    Pros

    • Offers some abstraction for your select statements an column aliasing.
    • Can be done quickly and relatively easily.
    • May provide improvements if schema bound / index views are used.

    Cons

    • Limited to select statements.
    • Can be confusing to develop against.
    • Doesn't off any security against SQL injection attacks.
    • More code to maintain.

    Facade tables Combined with the views suggestion you can create facade tables with revised column naming and security access. When data is inserted into the facade table use triggers as the abstraction mechanism to populate the old tables.

    Pros

    • Can provide abstraction for inserting data.

    Cons

    • Probably the most risky option for providing abstraction.
    • Only suitable for insert statements.
    • Still susceptible to injection attacks when using direct inline SQL.
    • Triggers may not be supported for your data types.
    • More code to maintain.
    • Triggers are difficult to debug and often disliked due to the "hidden" nature.