我目前正在开发一个使用 Access 数据库作为后端的 PHP 应用程序。不是你理解的选择......数据库是客户最初使用的,使用它是需求的一部分。
该数据库的问题之一是列名具有您可以想象的最疯狂的命名约定。大写,小写,下划线,空格和普通的疯狂。例如,“性别”列包含一个日期。“User2”列也是如此。还有很多,但你明白了。
面对这种情况,我决定创建一个数组来将数据库列映射到 PHP 变量,这样我们就可以将代码与疯狂隔离开来。但是我的同事认为我过于复杂了,我们应该将数据库的列名用于相应的 PHP 变量,这样我们就不需要通过映射数组来查找去哪里了。
所以我的问题是……我是在做正确的事情还是让事情复杂化?
14 回答
绝对你在正确的轨道上。如果你不抽象出疯狂,你自己最终会屈服于疯狂。
你的同事有一个有效的观点,所以我建议你也编写一个简单的方法来确定 PHP 中的数据到列映射。
这不是为了保持简单,而是为了改造一个坚实的基础。
让我担心的是,这种随机设计通常会隐藏某些业务规则,例如“......如果性别是一个日期,那么他们一定在某个时候购买了一个小部件,因此他们不能被允许胡说八道lubdub ......” - 我知道很疯狂,但比它应该更常见。
名字非常重要。如果您希望您的应用程序可维护,请在代码库进一步增长之前修复它们。
要玩 Devil's Advocate,有一些话要说,因为在您使用系统的短期记忆负载中没有不必要的间接层。一旦熟悉了代码,您就会知道哪个变量包含了什么,因此主要的好处是对于从头开始编写代码的新人来说。但是,正确解决该问题还需要修复数据库模式,这将 (a) 是一项重要的工作,并且 (b) 在很大程度上使问题消失。
这个问题没有非黑即白的答案,而且对你的具体问题没有明显的答案表明你可能想让睡狗撒谎。
另一方面,如果清理操作在可能的范围内,那么您可能希望在重构类型的基础上执行此操作,并在机会出现时逐步修复 DB 列名称。
只需在最需要的地方创建视图。
这是一个很好的问题,因为它涉及到编码恕我直言的核心。
我会和你一起去把坏名字抽象成可读的好名字。结果是逻辑上更易于理解和可读的代码有点复杂。
您没有说您不能重命名 Access 中的列,所以.... 这样做!另一种可能性是为每个表创建视图,并重命名视图中的列。然后,您可以使用视图 vEmployees,而不是使用表员工。如果我没记错的话,Access 允许您更新视图并从中进行选择。但是,如果您将 ORM 与 PHP 一起使用,则可能不支持更新视图。
即使名称有意义,硬编码表名和列名也不是一个好主意。
我不知道使用数组是否是最好的解决方案。我对 PHP 不是很熟悉,但我会使用诸如常量字符串之类的东西来存储表名。在我使用的语言中,这将导致代码更具可读性。
你很不幸被这个数据库困住,但我认为总的来说,将字段名称抽象成更明智的方法更聪明。
当您从数据库中提取数据时,我可能会创建一个包含数据库名称、已清理名称、类型和内容字段的数据结构。这将提供一种将事物组合在一起的便捷方式,因此您不仅可以映射出疯狂的名称方案。
绝对你在做正确的事。在我看来,最好在那里实现一些理智。展望未来,如果他们决定更改该数据库或其任何列名,您的逻辑不会被丢弃。如果您以正确的方式构建映射,则只需将新表/列直接插入应该很容易。
如果有的话,您正在做的事情可以提高整体解决方案的敏捷性。
当然,我仍然会说 KISS 适用于您的映射方法!
在应用程序的末尾使用正确的列名是您能做的最好的事情。除非您想查找“该字段应该是什么?”,否则您应该这样做。当你做了其他事情后必须再次查看它时。
你的同事的观点是不要把事情复杂化。这也是有效的。
因此,将对字段的访问封装在一个或多个方法中,并让该方法进行翻译。使用地图这不应该是一个性能问题。
事实上,如果您的客户重新考虑使用真实数据库,将所有到数据源的映射放在一个对象中可能会对您有所帮助。客户喜欢改变他们的看法。
为什么不创建一个带有映射到每个表的类的数据层。然后,您可以定义类方法来访问列并为方法指定您想要的任何名称。那么数据层数据库访问代码是唯一需要知道真实列名的东西。我怀疑有人(可能是几个人)已经开发了一个框架来做到这一点。谷歌“php orm”。
使用 ORM,您将很快更改数据库...
您仍然需要维护数据库。我可以建议的一种可能方法是按照您的计划在应用程序代码中映射字段名称。但是迟早你必须开始用字段名称处理这种命名疯狂并修复它。仅仅从问题中筛选并认为这是一个安全的解决方案和好方法并不是一个好主意。这只是临时解决方法。不要把你自己填满。