这更像是一个面向业务的编程问题,我似乎无法弄清楚如何解决.我与一个与BASIC合作超过20年的程序员团队合作.我被引进来帮助在.NET中编写相同的软件,只有更新和现代实践.问题是,我似乎无法让任何其他3个团队成员(所有BASIC程序员,尽管现在也有.NET)了解如何正确地执行关系数据库.这是他们不理解的事情:
我们基本上有一个跟踪客户标签信息的交易.我们需要能够跟踪当前交易和过去的交易.在旧系统中,使用平面文件数据库,其具有包含客户的基本当前交易的记录的一个表,以及包含客户的所有先前交易以及重要货币信息的另一个交易.为了防止冗余,他们会用历史记录事务覆盖当前事务 - (历史文件首先更新,然后更新当前事务.)这是完全不必要的,因为你只需要一个事务表,但我的主管或我的其他任何两个co工作者似乎无法理解这一点.我怎么能说服他们看到光线让我们赢了' 必须做大量的工作并最终击中数据表太多次？感谢您的投入!
首先,我必须承认,从您的描述中我并不完全清楚现有结构中的数据结构和逻辑流是什么.这对我来说意味着也许你并没有让你的同事明白自己,所以你的一个优先事项必须是能够口头或最好用书面和图表来解释当前的情况和建议的替代.请将此视为观察,而不是批评您的问题.
其次,我发现20年经验的程序员不了解关系数据库和事务是非常值得注意的.平板文件编码在很久以前就已经脱离主流 - 我在1988年首次处理商业环境中的关系数据库,到90年代中期它们已经相当普遍.您在做什么行业和产品类型？我觉得你可能正在处理某种嵌入式或其他"不寻常"的系统,在这种情况下,你确实需要确保你没有某种通信问题而你却忽视了一只大象没有向你指出 - 你不会成为第一个'顾问'被带入一个以某种方式设置的团队,而不是被提供适当的信息.
最后,如果你完全确定自己的立场并面对一个不会接受你的建议的团队 - 如果你可以节省时间,那么演示代码是个好主意 - 然后你可能不得不接受优雅地决定并移动一个.我自己处于这个位置,我会尝试抽象出问题 - 例如,数据库更新是否可以移动到存储过程中,以便更新两个表的代码都在SP中,并且可以在以后修改以移动到您的模式而不需要相应的申请变更？确保您的论据有详细记录和记录,以便您可以在机会出现时再次访问它们.
你不会是第一个因为办公室政治而必须实施次优解决方案的程序员 - 将它作为一种学习经验,用于处理这种情况的个人发展,并同心你的想法,你会得到额外的报酬工作.通常这些争论的决定因素不是逻辑,而是你自己带来的"声誉权重" - 听起来好像被带入了你对你的团队没有那么多的杠杆作用,所以你在你在后续案件中有足够的声誉之前,可能必须努力通过实施他们同意做的事情来赢得声誉 - 你需要先修改一下!
京公网安备 11010802040832号 | 京ICP备19059560号-6 