Database 我应该去爬山吗？

刚刚同意了一个网络项目，基本上是从头开始重新设计。大量的用户界面和导航问题需要重新设计。 在评估项目时，允许在现有场地代码中跋涉。这让我感到很尴尬，看到了许多名为GetSubProductCategory和GetSubCategory的函数。我只是把这归因于非常糟糕的命名/编码。 我没有想到底层数据库可能是FF。我错了。同样可怕的桌子名称，还有97张该死的桌子！我甚至不确定这个网站是否销售97种产品

你会考虑用这样的数据库工作吗？或者你会诚实地告诉客户他手上真的很乱吗？

听起来很有趣

---

可以从这些任务中学到很多东西（拥抱它；）

97个表格并不一定意味着设计不好。规范化意味着比非规范化设计更高的表计数，所以它不一定是坏的

话虽如此，我无法根据你发布的内容来判断设计

我不知道是不是那些在网络和中间层上做了错误命名的人创建了数据库。要想知道是否有人聪明地使用了数据库，唯一的办法就是查看它。当然，要检查命名，还要检查规范化程度、正确的键、良好的索引等

---

是否接受这份工作取决于你有多需要这份工作以及你是否想接受挑战。修复一个大烂摊子可能是令人满意的：你可能会成为一个排干沼泽的人

不，老实说，如果不这样做，你以后会后悔不已，因为你永远不会在合理的时间内拿出一个像样的解决方案

另外，要记住，你的客户可能知道他的系统很糟糕，并且会尊重你给他的坦诚、专业的意见

---

最后，假设他倾听并接受你的分析，那么你就可以重新谈判了。

这完全取决于你客户的期望。

对我来说，你有多饿并不重要——如果客户对这项工作需要多少时间/工作量没有合理的预期，那就走开吧

话虽如此，你的工作就是告诉他他的混乱。花一天的时间，做一个粗略的分析，向客户展示你的担忧。然后，花你认为需要的时间把它加倍（也许是三倍）。给你的客户那个号码，看看他们的反应。

更新：

始终相信自己的直觉。

---

我绝对应该去爬山

“如果你不是解决方案的一部分，那么延长问题的时间是可以赚大钱的。”-www.despire.com是什么阻止了你同时做这两件事？（处理并告诉客户他真的一团糟）。现有的实施是否有效？是否有一个规范、测试用例或者至少有一个知情的客户可以告诉您它的功能和应该功能？我（从你所说的）不明白你为什么要跑这座山，除非它是固定价格。。。听起来这是一个很好的机会，可以把工作做好，改进事情，带着一个快乐的客户离开。保罗，是的，现有的实现在一定程度上是可行的，但它是一个集群。这是一个固定的价格，我们已经达成一致，但是没有涉及到后端的东西。同意表的数量和设计，但是当我看到像subSubProduct，subSubSubProduct，subSubSubProduct这样的名字时，我怀疑设计相当糟糕。更不用说，这些表都有类似qty_1到qty_8的字段。让我有点害怕那不是正常的。这违反了第一范式的规则。你可以告诉客户这是一件有形的事情，而不是“你的数据库糟透了”。