正如乔恩(Jon)所述，存储过程将为您提供直接表修改的保护.也有其他选择.您可以使用SQL Server的应用程序角色"(通过sp_setapprole proc).这样一来，您就可以继续为每个人使用单独的ID，但只有在应用程序连接时(通过前端)，用户的权限才会提高.

As Jon mentioned stored procedures would give you the protection over direct table modifications. There are other options too. You can use SQL Server's "Application Role" (via sp_setapprole proc). This enables you to continue to use a separate ID for everyone but only at application connection time (through the front-end) are the user's rights elevated.

使用共享ID的主要缺点是，您无法跟踪谁向服务器提交SQL，尽管如果它们都是内部的，则可以获取计算机名称.

A major downside to using a shared ID is you lose track of who is submitting SQL to the server though if they're all internal you can get to the machine name.

尽管有其他问题.听起来您的用户好像可以连接到数据库并随意运行查询.由于用户在直接连接的SQL会话中的行为，因此在应用程序中会造成重大的停机风险.如果可以实现，则可能要尝试创建一个报告数据库，该数据库会按您的业务可以承受的时间间隔(即每天)进行更新. HTH

Something else is concerning though. It sounds as if your users can connect to the database and run queries at will. You run a major risk of downtime in the application due to user behavior in the directly connected SQL sessions. If you can pull it off you may want to try to have a reporting database created that is updated at intervals that your business can tolerate, i.e., daily. HTH