2

私は一連のキーワード[abc、xyz、klm] `を持っているプロジェクトに取り組んでいます。コンテンツ[1.txt、2.txt、3.txt]を含むテキストファイルもたくさんあります。

私がしているのは、キーワードをテキストファイルにぶつけて、キーワードが出現する行を見つけることです。これは、複数回実行できます。ID (text file name without .txt), Extracted_Data, Line_Number, Spwaned_Across (keyword may be spread across 2 lines)だから私は発生ごとにを保存したいと思います。

このデータを保存するために、キーワードごとにテーブルを作成することにしました。

テーブル：abc、xyz、klm

表abcサンプルデータ：

ID Extracted_Data                         Line_Number Spawned_Across
12 MySQL is wonderful. What is 'abc'      34          1

だから私は各キーワードの表になってしまいます。私のプロジェクトでは、約150のキーワードがあり、それは成長する可能性があります。つまり、150のテーブル。

なぜ私はこの方法を選んだのですか？

今のところ、キーワードがファイルに存在するかどうかを確認する必要があります。将来、ファイル内のどこで、どのようにキーワードが発生したかを示すように求められると確信しています。新しいキーワードごとにテーブルを自動的に作成することを計画しています。これにより、キーワードごとに手動で作成したり、数百の列を持つ巨大なテーブルを作成したりする必要がなくなります。

私は正しい決断をしましたか？ご意見をお待ちしております。

4

4 に答える 4

6

そうしないでください。動的なテーブル名用に最適化されたデータベースライブラリはなく、テーブルにアクセスするたびにクエリを最初から作成する必要があります。また、「ファイル12の34行目でどのデータが見つかりましたか」などの質問にどのように答えますか。

3つのテーブルが必要になります。PostgreSQL構文[*]では、次のようになります。

CREATE TABLE source (sourceid SERIAL, filename VARCHAR NOT NULL);
CREATE TABLE keyword (keywordid SERIAL, keyword VARCHAR NOT NULL);
CREATE TABLE location (locationid SERIAL,
    sourceid INTEGER NOT NULL REFERENCES source(sourceid),
    keyword INTEGER NOT NULL REFERENCES keyword(keywordid),
    data VARCHAR NOT NULL,
    line INTEGER NOT NULL,
    span INTEGER NOT NULL);

新しいテキストファイルの処理を開始するときは、新しいsourceタプルを作成し、そのソースIDを覚えておいてください。キーワードに遭遇したら、そのキーワードの新しいレコードを挿入してそのキーワードIDを記憶するか、古いレコードを検索します。次に、そのsourceid、keywordid、およびその他の関連データをに挿入しlocationます。

私が以前に提起した質問に答えるために：

SELECT * FROM
    location JOIN source ON location.sourceid = source.sourceid
    JOIN keyword ON location.keywordid = keyword.keywordid
WHERE
    source.filename = 'foo.txt' AND
    location.line = 34;

はい、それを「正しい」方法で行うことは前もってより多くの作業ですが、パフォーマンス、メンテナンスの容易さ、および結果の使いやすさにおいて、100万倍以上の見返りが得られます。

[*] MySQLの構文は似ていますが、頭の中で覚えていないので、違いを簡単に理解できます。

于 2011-08-02T15:21:52.380 に答える
5

1つのテーブルのデータに沿ってキーワードを保存できない理由がわかりません。

ID  Keyword  Extracted_Data  Line_Number Spawned_Across
12  abc      Abc or xyz?..   31337       1
12  xyz      Abc or xyz?..   31337       1
12  xyz      just xyz here   66666       1
13  xyz      xyz travels!    123         1

したがって、キーワードまたはファイル、あるいはその両方でクエリを実行する必要があります。すべてのデータが存在します。さらに正規化するには、キーワードを「keywords」テーブルに個別に格納し、外部キーのみを「occurences」テーブルに保持します。

また、主キー以外の名前を「ID」にすることはあまり一般的ではありません。

于 2011-08-02T15:02:36.313 に答える
2

これは間違いなく非常に悪い決定です。

数百万の行は、数百万のテーブルよりも優れています。

適切な外部キーを使用して2つのテーブルを作成すれば、問題はありません。

ファイル内のどこで、どのように発生したかを示すように求められます。

これはまだ2つのテーブルで行うことができます

于 2011-08-02T14:57:43.183 に答える
1

これは効率的ではないと思います。リレーショナルデータベースがその仕事に適したツールであるかどうかさえわかりません。

新しいキーワードは、より多くのテーブルを意味します。それはスケーラブルではありません。

キーワードとファイルは、インデックス作成と非構造化検索について考えさせてくれます。リレーショナルデータベースの前にLuceneについて考えていました。

于 2011-08-02T15:03:33.833 に答える