tags:

views:

134

answers:

2

i've got two tables: members and members_data.
They both share the same unique auto increment id key and unique username fields.

I would like to merge the two tables into one members table, BUT I have ~50 scripts using members & members_data references. I also need some sort of alias setup to make my members_data queries point toward the new members table.

Is this possible?

+1  A: 

You can effectively alias a table to another table by creating a view which just does SELECT * from the other table. This is however, not a good thing to do:

  • It confuses future code maintainers by having a view which is really another table (They can of course, look at your view in the source code**)
  • It is possibly inefficient in some cases in the optimiser
  • It is not the right way of refactoring things.

However, depending on how easy it is to test those "50 scripts" and how critical they are (Hint: very critical code which is difficult to test can put a real brake on effective development), creating the view MIGHT be a pragmatic thing to do in the short term (And short term solutions generally stay in place for years, or forever, in real applications).

I urge you, if it is in any way feasible, to change the "50 scripts" and carry out all the testing necessary to release such a change. In our team we have carried out changes (in a single release) which modified a lot more than "50 scripts", but testing did of course prove challenging (or at least time-consuming).

As applications become larger and more complex, regression testing becomes more difficult. It is vital to think about it as much as possible, because refactoring WILL become necessary (assuming the app gets developed or maintained AT ALL), and because regressions are bad.

** All your tables, views etc, ARE scripted and in your source code management system, of course!

MarkR
from what i've just read i couldn't use a view as it won't work on UPDATE queries (I would would need update members_data to actually update members after i've removed the table.)I think i'll have to change the scripts as it says views aren't optimized either and i can't have that in place for a long time!thanks for your help
Juddling
You should be able to UPDATE a view unless it's defined in such a way that updates make no sense. A "SELECT * from t" view should be ok.
MarkR
A: 

They both share the same unique auto increment id key and unique username fields.

This sentence is meaningless gobbledy-gook. There is no way in MySQL (or most rDBMS that two tables could share columns).

I suspect there may be several possible answers to your question but without seeing the actual schema its rather difficult to tell.

Assuming that you really mean that the two tables both have a username field which is unique and the same size in both tables, and that both tables have an autoincrement column called id, then things are a lot clearer - in that case create a composite table implementing the columns from both the underlying tables, migrate the data into it and replace the 2 original tables with views.

C.

symcbean
sorry i shouldn't have said share, and maybe if i told you they both had the same number of rows that would have helped.
Juddling
rows? No, that doesn't help at all.
symcbean