这更多的是一个设计问题，而不是实现问题。我们的数据库有一个VB.NET前端。当前的设计是使用一张又一张的元数据表来强制执行"前端无SQL"策略。我认为我们所做的事情比硬编码更糟糕，因为我们现在有了少量的STOREDPROC意大利面条代码。我们有很多动态SQL，用于构建表的完全限定名称，然后将这些名称发送回另一个STORED PROC，该PROC处理平面文本文件的实际加载。
ID DATA_TABLE_NAME DATA_TABLE_SCHEMA PTR_TABLE_NAME PTR_TABLE_SCHEMA
1 datatable DBO datatable_ptr DBO
因此，我们有一个类，它将获取数据表名称和表指针，并将其合并到VB.NET前端的一个类中，该类发送一个全名，如database.dbo.datatable，该全名映射到database.dbo.datable_ptr，并使用全局临时表加载平面文本文件。好吧，有人在这个讨厌的元数据小表中添加了一行，它破坏了VB.NET前端！必须有更好的方法来做到这一点，但我没有足够的经验来想出一个更好的通用解决方案。
程序员究竟是如何在保持代码可读性和可维护性的同时，强调使用T-SQL和VB.NET的代码重用和通用编程的？有没有人对有设计模式的书或烹饪书有一些建议，可以为我提供一些更可行的解决方案？
在开始我提出的解决方案之前，我认为我需要首先披露一些内容：
1) 我只有有2年多一点的专业编程经验
2)我目光短浅，因为我只对每天使用的数据库有经验
3)我只在一家(以及目前的)vb.Net/TSQL公司工作过
也就是说，以下是我在以下情况下会做的：
1) 你的管理者很可能希望看到一些可以量化的进展
2)您正在寻找一种实用的方法来解决这个问题(这个拟议的解决方案提供了什么)，以促进所述可量化的进展
3)您需要维护"前端无SQL"的理念
4)你需要一些可扩展的东西，所以当35个以上的应用程序变成75个以上的程序时，你仍然可以
解决方案：
1.创建一个新数据库，就好像SQL在前端是允许的一样(即"您一直想要的")
2.创建一个web服务，作为前端(不能有SQL)和"您一直想要的"数据库之间的中间人。这将解决问题。数据库结构不需要混淆，因为它将两次从最终用户中删除。
方法：
1)最初，动态SQL可以"按原样"移动到web服务。当意大利面条的部分被翻译时，它可以留在那里。我们可以称之为"主函数"，或者"旧的做事方式">
2)为每个应用程序指定一名团队负责人(或每5个应用程序指定1名负责人，等等)。他们的职责将是在创建他们的web服务部分时充当联络人。你需要知道他们需要什么表，他们在创建web服务时需要知道你想要的格式
3)一次处理一个应用程序：
nbsp A) 设置他们需要的数据库表
nbsp B) 创建web服务以将这些表与前端连接
nbsp C) 从前端创建函数调用以访问web服务。首先尝试与 nbsp；使用新的数据库表，然后尝试Master函数与数据库接口，就像现在一样。
随着应用程序被切换到使用其"个性化"web服务功能，主功能应该做得越来越少(即慢慢停止使用意大利面条存储过程)。此外，随着web服务的创建(到最后，其贡献者可能与应用程序)是去中心化的，工作可能会很快进行，并且由于主函数将是第一个启动和运行的东西运营作为一个整体应该仍然能够照常进行。