0

I am working on an Intranet helpdesk website that provides a search on some tables. Each table has the exact same schema, but is presented slightly differently depending on the purpose. For example, the Blog will display author names to the user while the FAQ and Guides sections will not. The tables have the following columns:

id int IDENTITY,
title VARCHAR(255),
body NVARCHAR(MAX),
author VARCHAR(80),
date DATETIME,
lasteditor varchar(80),
lastedited DATETIME,
CONSTRAINT [PK_blog_id] PRIMARY KEY CLUSTERED
([id] ASC)

I would like for the results of each table to return a rank with respect to all of the tables.

I am using Transact SQL (SQL Server 2008), so full text indexes require a primary key to operate on. So far I've come up with two possibilities to solve the problem of getting a unique key for the fulltext index:

  1. Create a View every time a search is performed that unions all of the tables, and generates a unique ID column on the View using something like this:

        SELECT id,
    variety,
    1 + (SELECT COUNT(*) FROM tbl WHERE t.id < id) as num
    FROM tbl

  2. Merge all of the tables into one big table, and append an extra column denoting the type (i.e "blog", "faq", "guides", etc). Use bigtable's primary key as the key for the fulltext index, and get the "table" I want using an extra WHERE clause.

Which one is considered better practice, or performs better? It would seem like creating a view and generating an "auto-increment" for the view everytime someone performs a global site search is a bit slow. Maybe there's an easier way of generating a unique id column for the view?

4

1 回答 1

0

我认为您回答了自己的问题 1) 似乎是个坏主意，除非您有令人信服的理由让 4 个表基本相同。

选择 2，稍后当您添加新的文本对象时，您会很高兴

“例如，博客将向用户显示作者姓名，而常见问题解答和指南部分则不会。表格具有以下列”

这都是业务逻辑。不要在数据库层做出这个决定。根据类型字段做出决定。

于 2012-09-18T22:05:20.813 回答