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