0

いくつかのテーブルを検索できるイントラネットヘルプデスクのWebサイトに取り組んでいます。各テーブルのスキーマはまったく同じですが、目的に応じて表示が少し異なります。たとえば、ブログには作成者名がユーザーに表示されますが、FAQセクションとガイドセクションには表示されません。テーブルには次の列があります。

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)

各テーブルの結果で、すべてのテーブルのランクを返したいと思います。

Transact SQL（SQL Server 2008）を使用しているため、フルテキストインデックスを操作するには主キーが必要です。これまでのところ、フルテキストインデックスの一意のキーを取得する問題を解決するための2つの可能性を考え出しました。

  1. すべてのテーブルを結合する検索が実行されるたびにビューを作成し、次のようなものを使用してビューに一意のID列を生成します。

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

  2. すべてのテーブルを1つの大きなテーブルにマージし、タイプを示す追加の列を追加します（つまり、「ブログ」、「よくある質問」、「ガイド」など）。bigtableの主キーをフルテキストインデックスのキーとして使用し、追加のWHERE句を使用して必要な「テーブル」を取得します。

どちらがより良い実践と見なされますか、それともパフォーマンスが向上しますか？ビューを作成し、誰かがグローバルサイト検索を実行するたびにビューの「自動インクリメント」を生成するのは少し遅いように思われます。たぶん、ビューの一意のID列を生成する簡単な方法がありますか？

4

1 に答える 1

0

あなたはあなた自身の質問に答えたと思います1）本質的に同じ4つのテーブルがあるというやむを得ない理由がない限り、悪い考えのように思えます。

2を使用すると、後で新しいテキストオブジェクトを追加するときに、喜ぶでしょう。

「たとえば、ブログには著者名が表示されますが、FAQセクションとガイドセクションには表示されません。表には次の列があります。」

これはすべてビジネスロジックです。DBレイヤーでこの決定を行わないでください。タイプフィールドに基づいて決定を下します。

于 2012-09-18T22:05:20.813 に答える