2011-05-25 125 views
0

是否有可能有SQL服务器在连接到数据库,以这样的方式,用户创建一个临时表中的特定数据库中的连接用户可以访问的内容只有一个在此表中(甚至更好,连接用户的是,甚至可以看到表中的唯一一个)?创建临时表

我尝试使用登录触发器(包括使用“与执行呼叫者”子句),但是尽管这创建了临时表,连接用户永远不能看到它/从中选择。 所有这一切都必须在SQL Server内部运行,并要求根本没有用户交互...

基本上,这是我想支持的场景:

  • 用户连接
    • 一个临时表一个特定的DB内创建SQL内部(由SQL,踢掉,通过建立连接的)
  • 一些特定信息被填充在表内
  • 对于连接的持续时间;用户具有(读取)访问此表中的内容;此表中的信息用于子系统中的特定数据库中
  • 用户断开
    • 临时表及其所有内容由SQL

感谢

+2

这听起来效率极低。您最终会用无数的临时表格来污染您的目录,您还需要在登录时填写这些临时表格。 (更不用说,您的数据在登录时可能会过时。) – 2011-05-25 16:47:44

+0

这是一个在数据库中强制执行行级安全的安全子系统。我希望数据库执行此操作,以便无论您使用哪个客户端连接到数据库,数据库本身都将始终强制执行行级安全性。 – 2011-05-25 18:32:22

回答

1

下降第一个想法:

  • 修改你的客户端代码,在c上创建表onnection?然后,它需要的不是所有的时间
  • 使用基于一个GUID一个共同的,固执地维持着的SessionID表时只能做?这将提供一些审计+故障排除信息太
  • 使用table value parameters发送点播数据,而不是有任何服务器端缓存

什么我可能会做的事:

  • 创建表当我需要时它被填充。用户可以连接到数据库的各种原因(我认为)。所以“连接”应该从“CREATE TABLE”中解耦。
+0

感谢gbn的回答。 关于你的建议:我明确地想避免在客户端做这件事,因为我不希望用户有能力绕过这段逻辑。 (即想象一个用户可以直接使用SSMS连接;我希望发生同样的逻辑) 拥有一个持久表格会使该表格中的所有信息对所有用户都可见,这是我明确要避免的。 我们也处于多用户场景,每个用户都应该有'自己的桌子'。 – 2011-05-25 16:57:32

+1

@T_D - *使该表中的所有信息对所有用户可见*。取决于您的安全结构,这不是真的。用户如何连接到数据库?直接使用他们的AD帐户(或通过模拟)?通过代理帐户? – Thomas 2011-05-25 17:01:56

0

如果您的数据访问被正确设计为打开连接 - 执行操作/查询 - 关闭连接,则使用临时表不会是正确的方法。当你关闭连接时,临时表将被销毁。这将是更好地使用视图或存储过程来过滤该用户有权访问的信息。这种观点的结构将在用户连接到数据库很大程度上依赖。请用户连接到使用自己的个人Windows身份验证帐户数据库或做他们间接地连接至另一个帐户像许多Web服务器呢?

海事组织,更好的办法是,GBN的回答的第二个项目符号点:一个共同的坚持表的指标作为对会话或用户。