Absolutely you are on the right track. If you don't abstract away the madness you will eventually succumb to the madness yourself.
Your colleague has a valid point though, so I suggest you also code an easy way to determine the data to column mapping in PHP.
This isn't about keeping it simple, it's about retrofitting a solid foundation to build upon.
The thing that would worry me is that this kind of random design often hides certain business rules, things like "...if the gender is a date then they must have purchased a widget at some point therefore they can't be allowed to fribbish the lubdub... " - crazy I know but more common than it should be.
To play Devil's Advocate, there's something to be said for not having an unnecessary layer of indirection in your short-term memory load for working with the system. Once familiar with the code, you will know what goes in which variable, so the main benefit is to someone new picking up the code from scratch. However, fixing that problem properly would also require fixing up the database schema which would (a) be a significant body of work, and (b) largely make the problem go away.
There is no black-and-white answer to this question, and the lack of an obvious answer to your specific problem suggests that you may want to let sleeping dogs lie.
On the other hand, if a cleanup operation is within the bounds of possibility then you may want to do it on a re-factoring type basis, incrementally fixing up the DB column names as the opportunity arises.
This is a good question as it talks to the heart of coding IMHO.
I would go with you and abstract out the bad names into readable decent names. The result being a little complication for much more logically understandable and readable code.
You didn't say you can't rename the columns in Access, so....do that! Another possibility would be to create views for each table, and rename the columns in the view. Then instead of working with table Employees, you work with view vEmployees. If I recall correctly, Access lets you update views as well as select from them. If you are using an ORM with PHP, that may not support updating views however.
Hard coding table names and column names is never a good idea even when the names make sense.
I don't know if using arrays is the best solution though. I'm not really familiar with PHP but I would have gone with something like constant strings to store the table names. In the languages I work in this would lead to more readable code.
You are very unlucky to be stuck with this database but I think on the whole a way of abstracting the field names into something more sensible is smarter.
I would perhaps create a data structure containing the database name, sanitised name, type and a field for the content when you're pulling the data out of the DB. That would give a convenient way of drawing things together so you're not only mapping away the crazy name scheme.
Absolutely you're doing the right thing. In my opinion it's better to implement some sanity there. Going forward, you're logic wouldn't be throw away if they decided to change that database or any of it's column names. If you build your mapping the right way, it should be easy to just plug the new tables/columns right in.
If anything, what you're doing improves the agility of your overall solution.
Of course I would still say KISS applies to the method of your mapping!
Using proper column names in your end of the application is the best you can do. And you should do it unless you want to have to look up "what that field was supposed to be again?" when you have to look at it again after you did something else.
Your colleague's point is not to overcomplicate things. That's valid, too.
So encapsulate access to the fields in a method or methods and have that method do the translation. Using maps this shouldn't be a performance problem.
In fact putting all the mapping to the data source in one object might help you if your customer reconsiders to use a real database. And customers love to change their opinion.
Why not create a datalayer with classes that map on to each table. Then you can define the class methods to access the columns and give the methods whatever names you want. Then the datalayer database access code is the only thing that needs to know about the real column names. I suspect that someone (perhaps several soneones) has already developed a framework to do this. Google "php orm".
You still need to maintain database. One possible approach I can suggest is to map field names in application code as you plan it to do. But then sooner or later you have to start handling this naming madness with field names and fix it. It is not good idea just to screen from a problem and imagine that it is a safe solution and good way to go. It is only temporary workaround. Do not full your self about it.
发布评论
评论（14）
绝对你走在正确的轨道上。 如果你不抽象出疯狂，你自己最终也会屈服于疯狂。
不过，您的同事的观点是有道理的，因此我建议您还编写一种简单的方法来确定 PHP 中的数据到列的映射。
这不是为了保持简单，而是为了改造一个坚实的基础。
让我担心的是，这种随机设计经常隐藏某些业务规则，比如“......如果性别是一个日期，那么他们一定在某个时候购买了一个小部件，因此不能允许他们胡闹” lubdub...” - 我知道这很疯狂，但比应有的更常见。
Absolutely you are on the right track. If you don't abstract away the madness you will eventually succumb to the madness yourself.
Your colleague has a valid point though, so I suggest you also code an easy way to determine the data to column mapping in PHP.
This isn't about keeping it simple, it's about retrofitting a solid foundation to build upon.
The thing that would worry me is that this kind of random design often hides certain business rules, things like "...if the gender is a date then they must have purchased a widget at some point therefore they can't be allowed to fribbish the lubdub... " - crazy I know but more common than it should be.
名字尤为重要。 如果您希望应用程序可维护，请在代码库进一步增长之前修复它们。
Names are exceptionally important. If you want your application to be maintainable, fix them before the code base grows further.
我不会说你让事情变得复杂。
Eric Evan 的书 领域驱动设计对此有一个可爱的术语：反腐败层
I wouldn't say you are complicating things.
Eric Evan's book Domain Driven Design has a lovely term for this: Anti Corruption Layer
要玩《Devil's Advocate》，需要注意的是，在使用系统的短期记忆负载中不要有不必要的间接层。 一旦熟悉了代码，您就会知道哪个变量包含什么内容，因此主要的好处是让新人从头开始学习代码。 然而，正确解决该问题还需要修复数据库模式，这将（a）是一项重要的工作，并且（b）很大程度上可以解决问题。
这个问题没有非黑即白的答案，并且对您的具体问题缺乏明显的答案表明您可能想让睡狗撒谎。
另一方面，如果清理操作在可能性范围内，那么您可能希望在重构类型的基础上执行此操作，并在机会出现时逐步修复数据库列名称。
To play Devil's Advocate, there's something to be said for not having an unnecessary layer of indirection in your short-term memory load for working with the system. Once familiar with the code, you will know what goes in which variable, so the main benefit is to someone new picking up the code from scratch. However, fixing that problem properly would also require fixing up the database schema which would (a) be a significant body of work, and (b) largely make the problem go away.
There is no black-and-white answer to this question, and the lack of an obvious answer to your specific problem suggests that you may want to let sleeping dogs lie.
On the other hand, if a cleanup operation is within the bounds of possibility then you may want to do it on a re-factoring type basis, incrementally fixing up the DB column names as the opportunity arises.
只需在最需要的地方创建视图即可。
Just create views where it is most needed.
这是一个很好的问题，因为它涉及到编码的核心恕我直言。
我会和你一起去把坏名字抽象成可读的好名字。 结果是对于逻辑上更容易理解和可读的代码来说有点复杂。
This is a good question as it talks to the heart of coding IMHO.
I would go with you and abstract out the bad names into readable decent names. The result being a little complication for much more logically understandable and readable code.
您没有说您不能在 Access 中重命名列，所以....这样做！ 另一种可能性是为每个表创建视图，并重命名视图中的列。 然后，您不再使用表Employees，而是使用视图vEmployees。 如果我没记错的话，Access 允许您更新视图并从中进行选择。 如果您在 PHP 中使用 ORM，则可能不支持更新视图。
You didn't say you can't rename the columns in Access, so....do that! Another possibility would be to create views for each table, and rename the columns in the view. Then instead of working with table Employees, you work with view vEmployees. If I recall correctly, Access lets you update views as well as select from them. If you are using an ORM with PHP, that may not support updating views however.
硬编码表名和列名从来都不是一个好主意，即使这些名称有意义。
我不知道使用数组是否是最好的解决方案。 我不太熟悉 PHP，但我会使用常量字符串之类的东西来存储表名。 在我所使用的语言中，这会产生更具可读性的代码。
Hard coding table names and column names is never a good idea even when the names make sense.
I don't know if using arrays is the best solution though. I'm not really familiar with PHP but I would have gone with something like constant strings to store the table names. In the languages I work in this would lead to more readable code.
您很不幸被困在这个数据库中，但我认为总的来说，将字段名称抽象为更合理的内容的方法更聪明。
当您从数据库中提取数据时，我可能会创建一个包含数据库名称、清理名称、类型和内容字段的数据结构。 这将提供一种将事物组合在一起的便捷方法，这样您就不仅仅是映射出疯狂的名称方案。
You are very unlucky to be stuck with this database but I think on the whole a way of abstracting the field names into something more sensible is smarter.
I would perhaps create a data structure containing the database name, sanitised name, type and a field for the content when you're pulling the data out of the DB. That would give a convenient way of drawing things together so you're not only mapping away the crazy name scheme.
绝对你做的是正确的事。 在我看来，最好在那里实现一些理智。 展望未来，如果他们决定更改该数据库或其任何列名称，您的逻辑将不会被丢弃。 如果您以正确的方式构建映射，那么插入新表/列应该很容易。
如果有的话，您正在做的事情提高了整体解决方案的敏捷性。
当然我还是会说KISS适用于你的映射方法！
Absolutely you're doing the right thing. In my opinion it's better to implement some sanity there. Going forward, you're logic wouldn't be throw away if they decided to change that database or any of it's column names. If you build your mapping the right way, it should be easy to just plug the new tables/columns right in.
If anything, what you're doing improves the agility of your overall solution.
Of course I would still say KISS applies to the method of your mapping!
在应用程序末端使用正确的列名称是最好的选择。 除非您想再次查找“该字段应该是什么？”，否则您应该这样做。 当你做了其他事情之后必须再次查看它时。
你同事的观点是不要让事情变得过于复杂。 这也是有效的。
因此，将对字段的访问封装在一个或多个方法中，并让该方法进行转换。 使用地图这不应该是性能问题。
事实上，如果您的客户重新考虑使用真实数据库，那么将所有到数据源的映射放在一个对象中可能会对您有所帮助。 客户喜欢改变他们的观点。
Using proper column names in your end of the application is the best you can do. And you should do it unless you want to have to look up "what that field was supposed to be again?" when you have to look at it again after you did something else.
Your colleague's point is not to overcomplicate things. That's valid, too.
So encapsulate access to the fields in a method or methods and have that method do the translation. Using maps this shouldn't be a performance problem.
In fact putting all the mapping to the data source in one object might help you if your customer reconsiders to use a real database. And customers love to change their opinion.
为什么不创建一个包含映射到每个表的类的数据层。 然后，您可以定义类方法来访问列，并为这些方法指定您想要的任何名称。 那么数据层数据库访问代码是唯一需要知道真实列名的事情。 我怀疑有人（也许是几个人）已经开发了一个框架来做到这一点。 谷歌“php orm”。
Why not create a datalayer with classes that map on to each table. Then you can define the class methods to access the columns and give the methods whatever names you want. Then the datalayer database access code is the only thing that needs to know about the real column names. I suspect that someone (perhaps several soneones) has already developed a framework to do this. Google "php orm".
使用 ORM，您很快就会更改数据库......
Use a ORM, you will be changing the db soon...
您仍然需要维护数据库。 我建议的一种可能的方法是按照您的计划在应用程序代码中映射字段名称。 但迟早你必须开始处理字段名称的命名疯狂并修复它。 仅仅从问题中筛选出来并想象它是一个安全的解决方案和好的方法并不是一个好主意。 这只是临时解决方法。 不要对此自满。
You still need to maintain database. One possible approach I can suggest is to map field names in application code as you plan it to do. But then sooner or later you have to start handling this naming madness with field names and fix it. It is not good idea just to screen from a problem and imagine that it is a safe solution and good way to go. It is only temporary workaround. Do not full your self about it.