两个 MySQL 表的合并和别名
我有两个表：members 和 members_data。
它们都共享相同的唯一自动增量 id 键和唯一的 username 字段。
我想将两个表合并为一个 members 表，但是我有大约 50 个使用 members & 的脚本。 members_data 引用。我还需要某种别名设置，以使我的 members_data 查询指向新的 members 表。
这可能吗？
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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您可以通过创建一个仅从另一个表执行 SELECT * 的视图来有效地将一个表别名为另一个表。然而，这不是一件好事：
然而，根据测试这些“50 个脚本”的容易程度以及它们的重要性（提示：难以测试的非常关键的代码可能会真正阻碍有效开发），创建视图可能是一件务实的事情短期内做（短期解决方案通常在实际应用中保留数年或永远）。
我敦促您，如果可行的话，更改“50 个脚本”并进行发布此类更改所需的所有测试。在我们的团队中，我们进行了更改（在单个版本中），修改了“50 个脚本”以上，但测试当然证明具有挑战性（或至少耗时）。
随着应用程序变得更大、更复杂，回归测试变得更加困难。尽可能多地考虑它是至关重要的，因为重构将变得必要（假设应用程序得到开发或维护），并且因为回归是不好的。
** 当然，您的所有表、视图等都是脚本化的，并且位于您的源代码管理系统中！
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:
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!
这句话是毫无意义的官话。 MySQL（或大多数 rDBMS）中没有办法让两个表可以共享列。
我怀疑您的问题可能有几种可能的答案，但如果没有看到实际的模式，就很难判断。
假设您的意思确实是两个表都有一个用户名字段，该字段在两个表中都是唯一的且大小相同，并且两个表都有一个名为 id 的自动增量列，那么事情就清楚多了 - 在这种情况下创建一个复合表实现两个基础表中的列，将数据迁移到其中，并用视图替换 2 个原始表。
C.
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.