重命名列还是附加列?这是个问题

时间:2022-08-06 12:34:06

I am about to alter the several tables in a massive system which I probably only understand around 10%.

我即将在一个庞大的系统中修改几个表,我大概只了解10%左右。

I want to add three columns. One of these is just a rename of an existing column. Part of me wants to :-

我要加三列。其中之一就是对现有列的重命名。我的一部分想:-

  • Rename the column but worried about the impact on unknown parts of the system that use the old name.

    重命名列,但担心对使用旧名称的系统未知部分的影响。

  • Append the three columns to the table therefore making the old column redundant (over time).

    将这三列附加到表中,从而使旧列变得多余(随着时间的推移)。

7 个解决方案

#1


0  

I think the safest way to do this is to create a new table and create new stored procedures and methods.

我认为最安全的方法是创建一个新表并创建新的存储过程和方法。

But it is best to understand the whole system though... Putting on bandages like this will become a big mess over time.

但是最好了解整个系统……随着时间的推移,戴上这样的绷带会变得一团糟。

Creating new tables, stored procedures and methods is a cleaner mess than adding/modifying stuff to existing.

创建新的表、存储过程和方法比添加/修改现有的东西要干净得多。

EDIT: I have worked on a few web apps that had the same problem. Multiple developers before me added and modified a bunch of stuff in their own style. I assume your case is similar.

编辑:我曾经开发过几个有同样问题的web应用。在我之前的多个开发人员以他们自己的风格添加和修改了一堆东西。我想你的情况和我差不多。

Like I said. Best way is to understand the whole system and modify it. But if you can't, I find it better to add new modules rather than modify existing. It is easy to unplug it when something goes wrong. Also, at least now you know exactly how your module works.

就像我说的。最好的方法是了解整个系统并对其进行修改。但是如果不能,我发现添加新模块比修改现有模块更好。当出现问题时很容易拔掉插头。而且,至少现在您已经确切地了解了模块的工作方式。

If the existing app is very well written and easy to extend, I assume you wouldn't ask the question here.

如果现有的应用程序写得很好,易于扩展,我猜您不会在这里问这个问题。

So.. my final thoughts.

所以. .我最后的想法。

  • Best: Rename column and modify accordingly (if you know exactly how system works)
  • 最佳:重命名列并相应地进行修改(如果您确切地知道系统是如何工作的)
  • Safe: Add new columns
  • 安全:添加新列
  • Safest: Add new table for new columns and create new methods (override or overload)
  • 最安全的:为新列添加新表并创建新方法(覆盖或重载)

#2


4  

If you really must do this, go with option two for sure.

如果你真的必须这么做,那么选择第二种方法。

For the record, I think making a structure change to a db you do not understand is a recipe for disaster, so good luck!

为了记录,我认为对一个你不理解的db做一个结构改变是一个灾难的配方,所以祝你好运!

#3


1  

Search the source code for references to the column you wish to rename.
I assume all the source code is in some source repository. (Including SQL scripts.).

在源代码中搜索要重命名的列的引用。我假设所有的源代码都在某个源库中。(包括SQL脚本)。

If you find any, you need to change them, and test that functionality.

如果找到了,您需要更改它们,并测试该功能。

In addition I would give the functionality related to this a reasonable test in a test environment, after making these changes.

此外,在进行这些更改之后,我将在测试环境中为与此相关的功能提供一个合理的测试。

If you don't do this, you should really go with your second option.

如果你不这样做,你应该选择第二种选择。

#4


0  

Ideal solution: Get to understand the remaining 90% of the system :)

理想的解决方案:了解剩下的90%的系统:)

I would add the two new columns, and leave the OLD misspelled column the way it is. Even if your new logic uses your new (fixed) column, what about old reports? Old logic? Old insert/update statements?

我将添加两个新列,并将旧的拼写错误的列保留原样。即使您的新逻辑使用了新的(固定的)列,那么旧的报告呢?旧的逻辑?老insert / update语句?

#5


0  

If you don't understand the database schema DO NOT rename. Who knows what you'll break :)

如果不理解数据库模式,请不要重命名。谁知道你会打破什么?

One (slightly crazy) option is to add your column that is basically just a rename, copy the current data over to it, then re-design the original column so that it's a calculated field that returns the value of the new column.

一个(有点疯狂的)选项是添加您的列,它基本上只是一个重命名,将当前数据复制到它,然后重新设计原来的列,使它是一个计算字段,返回新列的值。

That way you get the rename, but you won't remove the old column.

这样就可以重命名,但不会删除旧列。

The safer bet is to turn that around. Make your new column a calculated value that just reads the old one and be done with it :)

更安全的做法是扭转局面。使您的新列成为一个计算值,该值只读取旧列并使用它完成:)

Or, you could create a view that would do just about the same thing.

或者,你可以创建一个视图,它可以做同样的事情。

#6


0  

You know, I have worked on a system where we just left the old in place and then added the new and used that going forward. This creates a MUCH bigger mess in the long run than making the change and then changing all the refernces to the old structure. So now they have a system where they can't standardize anything new at all because there are four different structures for storing Speaker information and two different structures for storing rep information, etc. So every tiny little change must be customized by client making everything that much harder to maintain in the future. This is not efficient or effective and it becomes much more expensive to maintain. Bite the bullet and find out what will be affected and then change everything at once.

我做过一个系统,我们把旧的放在原来的地方,然后添加新的,然后继续使用。从长远来看,这比更改然后更改旧结构的所有引用要麻烦得多。现在他们有一个系统,他们不能标准化新东西,因为有四个不同的结构来存储议长信息和两个不同的结构来存储代表信息,等等。因此,每一个微小的改变必须由客户定制生产的一切将来更难维护。这既没有效率,也没有效果,而且维护起来要昂贵得多。咬紧牙关,找出会受到影响的因素,然后马上改变一切。

#7


0  

Here's a good presentation on refactoring databases by Scott Ambler, the guy that literally wrote the book on refactoring databases.

这是Scott Ambler关于重构数据库的一个很好的介绍,他写了一本关于重构数据库的书。

#1


0  

I think the safest way to do this is to create a new table and create new stored procedures and methods.

我认为最安全的方法是创建一个新表并创建新的存储过程和方法。

But it is best to understand the whole system though... Putting on bandages like this will become a big mess over time.

但是最好了解整个系统……随着时间的推移,戴上这样的绷带会变得一团糟。

Creating new tables, stored procedures and methods is a cleaner mess than adding/modifying stuff to existing.

创建新的表、存储过程和方法比添加/修改现有的东西要干净得多。

EDIT: I have worked on a few web apps that had the same problem. Multiple developers before me added and modified a bunch of stuff in their own style. I assume your case is similar.

编辑:我曾经开发过几个有同样问题的web应用。在我之前的多个开发人员以他们自己的风格添加和修改了一堆东西。我想你的情况和我差不多。

Like I said. Best way is to understand the whole system and modify it. But if you can't, I find it better to add new modules rather than modify existing. It is easy to unplug it when something goes wrong. Also, at least now you know exactly how your module works.

就像我说的。最好的方法是了解整个系统并对其进行修改。但是如果不能,我发现添加新模块比修改现有模块更好。当出现问题时很容易拔掉插头。而且,至少现在您已经确切地了解了模块的工作方式。

If the existing app is very well written and easy to extend, I assume you wouldn't ask the question here.

如果现有的应用程序写得很好,易于扩展,我猜您不会在这里问这个问题。

So.. my final thoughts.

所以. .我最后的想法。

  • Best: Rename column and modify accordingly (if you know exactly how system works)
  • 最佳:重命名列并相应地进行修改(如果您确切地知道系统是如何工作的)
  • Safe: Add new columns
  • 安全:添加新列
  • Safest: Add new table for new columns and create new methods (override or overload)
  • 最安全的:为新列添加新表并创建新方法(覆盖或重载)

#2


4  

If you really must do this, go with option two for sure.

如果你真的必须这么做,那么选择第二种方法。

For the record, I think making a structure change to a db you do not understand is a recipe for disaster, so good luck!

为了记录,我认为对一个你不理解的db做一个结构改变是一个灾难的配方,所以祝你好运!

#3


1  

Search the source code for references to the column you wish to rename.
I assume all the source code is in some source repository. (Including SQL scripts.).

在源代码中搜索要重命名的列的引用。我假设所有的源代码都在某个源库中。(包括SQL脚本)。

If you find any, you need to change them, and test that functionality.

如果找到了,您需要更改它们,并测试该功能。

In addition I would give the functionality related to this a reasonable test in a test environment, after making these changes.

此外,在进行这些更改之后,我将在测试环境中为与此相关的功能提供一个合理的测试。

If you don't do this, you should really go with your second option.

如果你不这样做,你应该选择第二种选择。

#4


0  

Ideal solution: Get to understand the remaining 90% of the system :)

理想的解决方案:了解剩下的90%的系统:)

I would add the two new columns, and leave the OLD misspelled column the way it is. Even if your new logic uses your new (fixed) column, what about old reports? Old logic? Old insert/update statements?

我将添加两个新列,并将旧的拼写错误的列保留原样。即使您的新逻辑使用了新的(固定的)列,那么旧的报告呢?旧的逻辑?老insert / update语句?

#5


0  

If you don't understand the database schema DO NOT rename. Who knows what you'll break :)

如果不理解数据库模式,请不要重命名。谁知道你会打破什么?

One (slightly crazy) option is to add your column that is basically just a rename, copy the current data over to it, then re-design the original column so that it's a calculated field that returns the value of the new column.

一个(有点疯狂的)选项是添加您的列,它基本上只是一个重命名,将当前数据复制到它,然后重新设计原来的列,使它是一个计算字段,返回新列的值。

That way you get the rename, but you won't remove the old column.

这样就可以重命名,但不会删除旧列。

The safer bet is to turn that around. Make your new column a calculated value that just reads the old one and be done with it :)

更安全的做法是扭转局面。使您的新列成为一个计算值,该值只读取旧列并使用它完成:)

Or, you could create a view that would do just about the same thing.

或者,你可以创建一个视图,它可以做同样的事情。

#6


0  

You know, I have worked on a system where we just left the old in place and then added the new and used that going forward. This creates a MUCH bigger mess in the long run than making the change and then changing all the refernces to the old structure. So now they have a system where they can't standardize anything new at all because there are four different structures for storing Speaker information and two different structures for storing rep information, etc. So every tiny little change must be customized by client making everything that much harder to maintain in the future. This is not efficient or effective and it becomes much more expensive to maintain. Bite the bullet and find out what will be affected and then change everything at once.

我做过一个系统,我们把旧的放在原来的地方,然后添加新的,然后继续使用。从长远来看,这比更改然后更改旧结构的所有引用要麻烦得多。现在他们有一个系统,他们不能标准化新东西,因为有四个不同的结构来存储议长信息和两个不同的结构来存储代表信息,等等。因此,每一个微小的改变必须由客户定制生产的一切将来更难维护。这既没有效率,也没有效果,而且维护起来要昂贵得多。咬紧牙关,找出会受到影响的因素,然后马上改变一切。

#7


0  

Here's a good presentation on refactoring databases by Scott Ambler, the guy that literally wrote the book on refactoring databases.

这是Scott Ambler关于重构数据库的一个很好的介绍,他写了一本关于重构数据库的书。