假设我有一个主表,它有100列引用(作为外键)到100个表(包含主键).
整套信息需要加入这100张桌子.加入如此多的表肯定是一个性能问题.希望我们可以期望任何用户都希望在查询中请求包含来自不超过5-7个表(在这100个表中)中的值的一堆数据,这些查询将条件(在查询的WHERE部分中)放在大约3-4张桌子(其中100张).不同的查询有用于生产表的不同组合的"选择"查询的一部分,并把条件"WHERE".但是,同样,每个SELECT都需要5-7个表,每个WHERE都需要3-4个表(当然,用于生成SELECT的表列表可能与用于在WHERE中放置条件的表列表重叠).
我可以编写一个VIEW,底层代码加入所有这100个表.然后我可以将上面提到的SQL查询写到这个VIEW.但在这种情况下,对我来说如何指示SQL Server(尽管代码中的明确指令连接所有这100个表)只有大约11个表应该连接(11个表足以连接以生成SELECT)是一个很大的问题.结果并考虑到WHERE条件).
另一种方法可以是创建转换以下"假"代码的"特征"
SELECT field1, field2, field3 FROM TheFakeTable WHERE field1=12 and field4=5
进入以下"真实"代码:
SELECT T1.field1, T2.field2, T3.field3 FROM TheRealMainTable
join T1 on ....
join T2 on ....
join T3 on ....
join T4 on ....
WHERE T1.field1=12 and T4.field4=5
从语法的角度来看,即使允许这种"TheFakeTable-mechanism"与真实表格和结构的任何混合组合也不是问题.这里真正的问题是如何在技术上实现这个"特征".我可以创建一个函数,它将"假"代码作为输入并生成"真实"代码.但是,因为它需要使用动态SQL工具evrywhere其中这个"TheFakeTable机制"似乎也不是很方便.幻想土地解决方案是在我的Management Studio中扩展SQL语言的语法,以允许编写这样的假代码,然后在发送到服务器之前自动将此代码转换为真实代码.
我的问题是:
感谢大家的每一条评论!
PS具有100个表格的结构来自我在这里提出的以下问题: 规范化一个非常大的表格