0

likeステートメントを使用してSQLクエリの結果をフィルタリングしようとしています。結果は次のとおりです

/q/my_rat_terrior_is_about_8_just_this_moring_hes_barley_moving_around_panting_heavy_and_shaking_like_shivering/1
/addquestion
/addquestion/Validation
/q/how_do_you_get_a_hamster_out_of_a_wall/2

これらは私のデータベースに保存されているURLです。このようなURLを一致させたい

/q/how_do_you_get_a_hamster_out_of_a_wall/2
/q/my_rat_terrior_is_about_8_just_this_moring_hes_barley_moving_around_panting_heavy_and_shaking_like_shivering/1

これは私が試したことです：

select * from MyURLs where MYuri LIKE '/q/'

しかし、結果は返されません。これに関するアイデアはありますか？

4

3 に答える 3

3

％をワイルドカードとして使用する必要があります。

select * from MyURLs where MYuri LIKE '%/q/%'

これにより、フィールドの任意の場所に「/q/」が含まれるレコードが返されます。'/ q /'で開始したいが、その後に何かがある場合は、次を使用します。

select * from MyURLs where MYuri LIKE '/q/%'
于 2009-10-12T03:27:19.320 に答える
2

Kalebはすでに解決策を提供しています（そしてJoelはコメントでインデックスのパフォーマンスについて警告しています）が、別のルートを提案したいと思います。テーブルが非常に大きくなることがない場合は、このアドバイスを無視してかまいません。実際、パフォーマンスが低下すると予想される（またはパフォーマンスが実際に低下し始める）までは無視できます。これがYAGNIの原則です。

ほとんどの場合、データベースは書き込まれるよりもはるかに多く読み取られます。つまり、URLが「/ q /」で始まるか、「/ q /」を含むかを判断する適切なタイミングは、データを抽出するたびではなく、データがテーブルに配置されるタイミングです。これにより、すべての読み取りにわたって計算のコスト（書き込み時に実行）が償却されます。

"startsWithQ"このスケーラブルなソリューションの場合、テーブルには、またはのような完全に別個の列が必要"hasQ"です。

次に、挿入/更新トリガーを使用して、テーブルに配置されるURLに基​​づいてその列を設定します。

次に、クエリは次のようになります。

select * from MyURLs where hasQ = 'YES'

そして、その列にインデックスがあれば、クエリは絶叫します。

ほとんどのデータベースの問題を実際に見ると、通常、「ディスクのサイズが十分でない」というよりも、「クエリの速度が十分でない」という問題があります。通常、ディスク容量を速度と交換するのが最善の方法です。

これにより、検索文字列がである場合にパフォーマンスが向上する可能性があり'/q/%'ます。これは、定期的かつ本番環境でプロファイリングする必要があります。データベースは、テーブル内のデータに基づいてパフォーマンスが変化する可能性があるため、設定して忘れることはめったにありません。

あなたのデータベースが読み取りよりも書き込みが多い非常にまれな獣の1つでない限り、検索文字列がである場合、それは確かに改善を提供します。'%/q/%'

于 2009-10-12T03:43:06.977 に答える
1

このようなテキストがたくさんある場合は、フルテキストカタログを作成し、フルテキストインデックスを作成してデータを入力してから、フルテキストデータをクエリします。そのキーワード：contains、freetext、containstable、freetexttable。SQL Server 2005および2008には、強力なフリーテキスト検索があります。

于 2009-10-12T04:01:39.980 に答える