这更像是一个面向业务的编程问题，我似乎无法弄清楚如何解决。我与一个与BASIC合作超过20年的程序员团队合作。我被引进来帮助在.NET中编写相同的软件，只有更新和现代实践。问题是，我似乎无法让任何其他3个团队成员（所有BASIC程序员，尽管现在也使用.NET）来了解如何正确地执行关系数据库。这是他们不理解的事情：
我们基本上有一个跟踪客户标签信息的交易。我们需要能够跟踪当前交易和过去的交易。在旧系统中，使用平面文件数据库，其具有包含客户的基本当前交易的记录的一个表，以及包含客户的所有先前交易以及重要货币信息的另一个交易。为了防止冗余，他们会用历史记录事务覆盖当前事务 - （历史文件首先更新，然后更新当前事务。）这是完全不必要的，因为你只需要一个事务表，但我的主管或我的其他任何两个co工作者似乎无法理解这一点。我怎么能说服他们看到光线，以便我们不必做太多荒谬的工作并最终击中数据表太多次？感谢您的投入！
答案 0 :(得分：7)
首先，我必须承认，从您的描述中我并不完全清楚现有结构中的数据结构和逻辑流是什么。这对我来说意味着也许你并没有让你的同事明白自己，所以你的一个优先事项必须是能够口头或最好以书面和图表来解释当前的情况和建议的替代。请把这看作是一个观察，而不是批评你的问题。
其次，我确实发现20年经验的程序员不了解关系数据库和事务是非常值得注意的。平板文件编码在很久以前就已经脱离主流 - 我在1988年首次处理商业环境中的关系数据库，到90年代中期它们已经相当普遍。您在做什么行业和产品类型？我觉得你可能正在处理某种嵌入式或其他“不寻常”的系统，在这种情况下，你确实需要确保你没有某种通信问题而你却忽视了一只大象没有向你指出 - 你不会成为第一个'顾问'被带入一个以某种方式设置的团队，而不是被提供适当的信息。也就是说，这些古老的商店仍然存在 - 我当前的客户系统之一与以COBOL编码的基于平面文件的系统接口，是的，它很难管理; - ）
最后，如果你完全确定自己的立场并面对一个不会接受你的建议的团队 - 如果你可以节省时间，那么演示代码是一个好主意 - 然后你可能会有优雅地接受决定并移动一个。我自己处于这个位置，我会尝试抽象出问题 - 例如，数据库更新是否可以移动到存储过程中，以便更新两个表的代码都在SP中，并且可以在以后修改以移动到您的模式而不需要相应的申请变更？确保您的论据有详细记录和记录，以便您可以在机会出现时再次访问它们。
你不会成为第一个因为办公室政治而必须实施次优解决方案的程序员 - 将它作为个人发展的学习经验来处理这种情况并同心你的想法你会得到报酬为了额外的工作。通常这些争论的决定因素不是逻辑，而是你自己带来的“声誉权重” - 听起来好像被带入了你对你的团队没有那么多的杠杆作用，所以你在你在后续案件中有足够的声誉之前，可能必须努力通过实施他们同意做的事情来获得声誉 - 你需要先修改一下！
答案 1 :(得分：4)
有时你不能。
如果您阅读了一些XP书籍，他们常常会说您最大的障碍之一就是说服您的团队放弃他们一直以来所做的事情。
一般来说，他们会建议让不能适应的人去其他项目（或者只是让他们离开）。
代码审核可能对您的情况有所帮助。每行代码的强制性代码审查并非闻所未闻。
答案 2 :(得分：4)
有时最好的论据是一个例子。我会写一个原型（或者替换，如果不是太多的工作）。通过一个示例来检查它将更容易看到关系数据库的优缺点。
顺便说一句，平面文件数据库有它们的位置，因为它们比真正的关系数据库更容易“管理”。保持开放的心态。 ; - ）
答案 3 :(得分：3)
我认为你可能不得不以身作则 - 当人们看到“新的”方式是较少的工作时他们会采用它（只要你不揉鼻子）。
我还会问自己，旧的设计是否真的导致了问题，或者它是否只是在美学上令人讨厌。选择你的战斗很重要 - 如果旧的设计不会导致性能问题或者使系统难以维护，你可能只想留下旧的设计。
最后，如果您确实保留旧设计，请尝试抽象新代码和旧数据库之间的接口，这样如果您说服您的同事稍后改进设计，您可以放弃新模式不得不改变其他任何事情。
答案 4 :(得分：1)
除了原始问题的一般挫折之外，很难提取出很多。
是的，随着时间的推移，长期以来有很多技术和习惯随着技术的变化而变得毫无用处甚至成本高昂。在处理能力，内存甚至磁盘时，一些有意义的事情是昂贵的，现在可能是愚蠢的优化尝试。随着时间的推移，人们也会积累坏习惯和糟糕的编程模式。
你必须要小心。
有时候那些老定时器的事情有充分的理由。可悲的是，他们甚至可能无法用语言表达“为什么” - 如果他们甚至不知道为什么。
当新手进入企业软件开发商店时，我发现很多这种挫败感。即使环境都是相当现代的技术和工具，它也可能很糟糕。如果您的大部分经验都是编写小型社区桌面和Web应用程序，那么您所知道的很多内容可能都是错误的。
通常，事务日志的要求高于DBMS可能执行的级别。通常，有必要超越数据库事务语义，以确保时间序列的正确性，只需更新一次，弹性和不可否认性。
这甚至没有开始解决企业或企业间可扩展性所涉及的问题。当你每天开始接近50万个复杂的交易时，你会发现RDBMS技术让你失望。由于关系数据库不是为处理高事务量而设计的，因此您必须经常使用标准范例进行规范化和更新。无论您在问题上投入多少硬件，传统的RDBMS锁定技术都会破坏可扩展性。
很容易将所有这些都视为笨拙或一般的错误 - 甚至是无能。但要小心，因为并非总是这样。
顺便说一句：除了RDBMS之外还有其他模型，而RDBMS的替代品不一定是“平面文件” - 这与今天大多数编码人员的经验相反。事务性分层DBMS可以处理比RDBMS高得多的吞吐量。例如，IMS在大型IBM商店中仍然非常活跃。其他供应商为不同的平台提供类似的软件。
当然，在一个四人店中，这可能都不适用。
答案 5 :(得分：0)
为他们签署一些体面的培训，然后由你来说服他们用新技术可以实现更多（或至少更容易！）。
但我认为最重要的是，专业的，经过认证的培训师首先会向他们传授基础知识。他们会给他们留下更深刻的印象，而不只是他们的一位同事告诉他们：“嘿，为什么不用这个？”
相关帖子here。
答案 6 :(得分：0)
以下可能不适用于您的情况，但您很少提及技术细节，所以我想我会提到它......
有时候，如果当前数据的访问模式与历史数据的访问模式非常不同（我正在制作这个例子，但是说当前数据每秒访问1000次，并访问一小部分列，并且所有当前数据都小于1 GB，而历史数据使用1000 GB，每天只访问100次，所有列都可以访问），
那么，对于性能优化，你的同事正在做的事情会非常有意义。通过分离当前数据（冗余的albiet），您可以优化该表中的索引和数据结构，以便在历史表中无法进行更高频率的访问模式。从实际的实际情况来看，并非从纯粹的关系角度来看，“学术上”或“技术上”正确的所有内容都是有意义的。