【问题标题】:On K.I.S.S and paving cowpaths [closed]在 K.I.S.S 和铺路的牛道上[关闭]
【发布时间】:2008-11-27 12:25:12
【问题描述】:

我目前正在开发一个使用 Access 数据库作为后端的 PHP 应用程序。不是您理解的选择...数据库是客户最初使用的数据库,并且使用它是要求的一部分。

该数据库的问题之一是列名具有您可以想象的最疯狂的命名约定。大写,小写,下划线,空格和普通的疯狂。例如,“性别”列包含一个日期。 “User2”列也是如此。还有很多,但你明白了。

面对这种情况,我决定创建一个数组来将数据库列映射到 PHP 变量,这样我们就可以将代码与疯狂隔离开来。然而,我的同事认为我过于复杂了,我们应该将数据库的列名用于相应的 PHP 变量,这样我们就不需要通过映射数组来查找去哪里了。

所以我的问题是……我是在做正确的事情还是让事情复杂化了?

【问题讨论】:

    标签: language-agnostic naming-conventions


    【解决方案1】:

    您绝对是在正确的轨道上。如果你不把疯狂抽离出来,你自己最终会屈服于疯狂。

    您的同事有一个有效的观点,所以我建议您也编写一个简单的方法来确定 PHP 中的数据到列的映射。

    这不是为了保持简单,而是为了改造一个坚实的基础。

    让我担心的是,这种随机设计通常会隐藏某些业务规则,例如“......如果性别是日期,那么他们一定在某个时候购买了一个小部件,因此他们不可能允许贬低 lubdub..." - 我知道这很疯狂,但比它应该更常见。

    【讨论】:

      【解决方案2】:

      名字非常重要。如果您希望您的应用程序可维护,请在代码库进一步增长之前修复它们。

      【讨论】:

        【解决方案3】:

        我不会说你把事情复杂化了。

        Eric Evan 的书 Domain Driven Design 有一个可爱的术语:Anti Corruption Layer

        【讨论】:

          【解决方案4】:

          要玩《Devil's Advocate》,有一些话要说,因为在您使用系统的短期记忆负载中没有不必要的间接层。一旦熟悉了代码,您就会知道哪个变量包含了什么,因此主要的好处是对于从头开始编写代码的新人来说。但是,正确解决该问题还需要修复数据库模式,这将 (a) 是一项重要的工作,并且 (b) 在很大程度上使问题消失。

          这个问题没有非黑即白的答案,而且对你的具体问题没有明显的答案表明你可能想让睡狗撒谎。

          另一方面,如果清理操作在可能的范围内,那么您可能希望在重构类型的基础上执行此操作,并在机会出现时逐步修复 DB 列名称。

          【讨论】:

          • 这真的取决于应用程序有多大,至于您是否可以将所有不一致的地方都牢记在心。
          • 一旦应用程序超越了玩具,这就是疯狂所在。一旦我进入一个项目,就是这样开始的:“你会知道哪个变量里面有什么”。在我进来的时候,它已经成长为“没人知道它做了什么,不要碰”。需要几分钟才能修复的错误需要数小时甚至数天才能找到。
          • 同意。在一定程度的复杂性下,您确实需要一个组织良好的系统才能理解它。
          【解决方案5】:

          只需在最需要的地方创建视图。

          【讨论】:

            【解决方案6】:

            这是一个很好的问题,因为它涉及到编码恕我直言的核心。

            我会和你一起把坏名字抽象成可读的好名字。结果是更多在逻辑上更易于理解和可读的代码有点复杂。

            【讨论】:

              【解决方案7】:

              您没有说不能重命名 Access 中的列,所以....就那样做吧!另一种可能性是为每个表创建视图,并重命名视图中的列。然后,您可以使用视图 vEmployees,而不是使用表员工。如果我没记错的话,Access 允许您更新视图并从中进行选择。但是,如果您在 PHP 中使用 ORM,则可能不支持更新视图。

              【讨论】:

              • 抱歉,忘记说明了。无法更改 Access 数据库。
              • 不这么认为……那我建议你试试视图方法。
              【解决方案8】:

              即使名称有意义,硬编码表名和列名也不是一个好主意。

              我不知道使用数组是否是最好的解决方案。我对 PHP 不是很熟悉,但我会使用诸如常量字符串之类的东西来存储表名。在我使用的语言中,这将导致代码更具可读性。

              【讨论】:

                【解决方案9】:

                你很不幸被这个数据库困住了,但我认为总的来说,将字段名称抽象成更明智的方法更聪明。

                当您从数据库中提取数据时,我可能会创建一个数据结构,其中包含数据库名称、净化后的名称、类型和内容字段。这将提供一种将事物组合在一起的便捷方式,因此您不会映射出疯狂的名称方案。

                【讨论】:

                  【解决方案10】:

                  你绝对做对了。在我看来,最好在那里实现一些理智。展望未来,如果他们决定更改该数据库或其任何列名,您的逻辑就不会被抛弃。如果您以正确的方式构建映射,只需将新表/列直接插入应该很容易。

                  如果有的话,您正在做的事情可以提高整体解决方案的敏捷性。

                  当然我还是会说 KISS 适用于你的映射方法!

                  【讨论】:

                    【解决方案11】:

                    在您的应用程序末尾使用正确的列名是您能做的最好的事情。除非您想查找“该字段应该是什么?”,否则您应该这样做。当你做了其他事情后必须再次查看它时。

                    你的同事的观点是不要把事情复杂化。这也是有效的。

                    因此,将对字段的访问封装在一个或多个方法中,并让该方法进行翻译。使用地图这应该不是性能问题。

                    事实上,如果您的客户重新考虑使用 真实 数据库,将所有映射到数据源的所有映射放在一个对象中可能会对您有所帮助。客户喜欢改变他们的看法。

                    【讨论】:

                      【解决方案12】:

                      为什么不创建一个数据层,其中包含映射到每个表的类。然后,您可以定义类方法来访问列,并为这些方法提供您想要的任何名称。那么数据层数据库访问代码是唯一需要知道真实列名的东西。我怀疑有人(可能是几个人)已经开发了一个框架来做到这一点。谷歌“php orm”。

                      【讨论】:

                        【解决方案13】:

                        使用 ORM,您将很快更改数据库...

                        【讨论】:

                          【解决方案14】:

                          您仍然需要维护数据库。我可以建议的一种可能方法是按照您的计划在应用程序代码中映射字段名称。但是迟早你必须开始用字段名称处理这种命名疯狂并修复它。仅仅从问题中筛选并认为这是一个安全的解决方案和好方法并不是一个好主意。这只是临时解决方法。不要自满。

                          【讨论】:

                          • 是的。这里的计划是最终让客户离开 Access,让我们将所有数据移动到一个体面的数据库中,在那里我们可以建立一个稍微不那么疯狂的架构。
                          猜你喜欢
                          • 1970-01-01
                          • 1970-01-01
                          • 2012-06-01
                          • 1970-01-01
                          • 2016-01-09
                          • 2011-11-16
                          • 1970-01-01
                          • 1970-01-01
                          • 2023-04-09
                          相关资源
                          最近更新 更多