在K.I.S.S.和铺砌牛道上[关闭]

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

不过,您的同事有一个正确的观点,因此我建议您也编写一个简单的方法,用PHP确定数据到列的映射。

让我担心的是,这种随机设计往往隐藏着某些商业规则,比如“…如果性别是约会对象,那么他们一定在某个时候购买了一个小部件,因此他们不能被允许对lubdub吹毛求疵…”-我知道这很疯狂,但比应该的更常见。

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

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

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

要扮演魔鬼代言人的角色,有一点值得一提,那就是在使用系统的短期内存负载中没有不必要的间接层。一旦熟悉了代码,您就会知道哪个变量中包含了什么,因此主要的好处是让新手从头开始学习代码。然而,正确地解决这个问题还需要修复数据库模式,这将(a)是一项重要的工作,(b)在很大程度上解决这个问题。

这个问题没有黑白的答案,而你的具体问题也没有一个明确的答案,这表明你可能想让安睡的狗躺着。

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

很 逻辑上更易理解和可读的代码。

对表名和列名进行硬编码从来都不是一个好主意,即使这些名称有意义。

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

你很不幸被这个数据库困住了,但我认为总的来说,把字段名抽象成更合理的东西是更明智的。

我可能会创建一个数据结构,其中包含数据库名称、净化名称、类型以及从数据库中提取数据时内容的字段。这将提供一种方便的方式来把东西放在一起,这样你就不会 映射出疯狂的名字方案。

如果有什么不同的话,那么您所做的工作可以提高总体解决方案的灵活性。

在应用程序的末尾使用正确的列名是最好的选择。你应该这样做,除非你想在做了其他事情后再看一遍“这个领域应该是什么?”的时候。

你同事的观点是不要把事情过分复杂化。这也是正确的。

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

真实的 数据库顾客喜欢改变他们的观点。

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

您仍然需要维护数据库。我可以建议的一种可能的方法是按照计划在应用程序代码中映射字段名。但迟早你必须开始用字段名来处理这种命名疯狂,并加以修复。仅仅从一个问题中筛选出来,想象它是一个安全的解决方案和一个很好的方法,这不是一个好主意。这只是暂时的解决办法。不要对这件事满腹牢骚。