Question

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?

Answer 1

I think you answered your own question 1) seems like a bad idea unless you have a compelling reason for there to be 4 tables that are essentially the same.

Go with 2 and when you add a new text object later you will be glad

“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”

This is all business logic. Don’t make this decision in the DB layer. Make the decision based upon the type field.