WordPressをベースとして使い、簡易的なデータベースを構築して情報検索サイトをつくることが出来ます。
例えば
・地域情報サイト（イベント・店舗情報）
・グルメサイト
・商品情報サイト（決済機能をつければECサイトに）
・クリニック、整体院等の口コミ・検索サイト
etc

極めて件数の多い全国規模のサイトや、大手のような高機能なサイトでなければ、以上のようなものを比較的短期間で構築する事が出来ます。

その時に問題となってくるのが、いかにしてデータを登録し、分類・検索可能にして行くかという基本方針になります。

(1)投稿またはカスタム投稿タイプで登録して行く

もっともWordpressの仕組みに沿ったやり方だと言えます。
デフォルトではタイトルと本文しか登録出来ませんので、付加データについてはpost metaを利用する事になります。
その場合はCustom Field Template等のプラグインを使えば簡単にインターフェースを組む事が出来ます。
また検索ロジックは、WPに備わっているwp_queryをそのまま利用する事が出来、ページング等もWPの仕組みを流用できます。テンプレートの切り替えも、おなじみのsingle.php(single-{post_type}.php)やarchive.phpをそのまま使う事が出来ます。
もっとも構築が早い方法なのですが、デメリットがあります。
まず、検索の仕組みがwp_query頼みだと、複合検索に対応するなど、検索ロジックをカスタマイズするのが非常に難しくなります。検索の精度が問われるサイトではこの方法は避けた方が良いと思われます。
また、post_metaは一項目につき一行を消費するため、テーブルの行数は早いペースで肥大して行きます。
例えば30項目のデータが1000件だとすると、これだけで30000行使ってしまい、wp_postsとJOINされている以上、パフォーマンスの低下は免れられません。

(2)投稿またはカスタム投稿タイプで登録して行く＋検索ロジックを自作

データ登録については上記(1)の方法を取り、検索についてはwp_queryを使わず、自作するという方針です。
検索については$wpdb->query()などを使い、ガリガリ作り込んで行きます。ORM的な組み方も可能ですが、$wpdbの能力がもうひとつ不明なので、自分的にはSQLを組む方が見通しが良く作れそうです（その分セキュリティ対策は当然）。
表示系もかなりの部分が自作になり、なかなかしんどい事にはなると思いますが、おおよそ求められる検索結果は得られるだろうと思われます。
「不動産プラグイン」などもこの方法を取っていると思われます。

(3)wp_postsテーブルを拡張し、行x列式のテーブルを基本にする

wp_postsは言うまでもなく、wpの投稿を格納するもっとも基本的なテーブルになります。
このテーブルに対し、必要に応じカラムを追加したとしても（パフォーマンスの低下を除いては）害になるようなことはないでしょう。
ただ、この場合は、WPが本来持っているクエリ・システム(Wp_query)を使う事が出来なくなり、自前で検索ロジックを組む事になります。ページング等も当然自作することになります。
また、この場合、登録のインターフェースにCustom Field Template等のプラグインを利用する事が出来ず、これもやはり自作する事になります。PHPに腕のある構築者向けの方法になると言えます。

(4)オリジナル・テーブルを利用する

$wpdbを使い、wp_***系でない、全くのオリジナルのテーブルにアクセスすることも可能です。
この場合、カスタム投稿タイプやタクソノミーとは無関係ですので、管理画面のCRUD、登録画面、検索ロジック、表示系すべて自作する事になり、ここまで来ると正直Wordpressを使う必然性そのものが薄れて来るかも知れません。CakePHP等のDBに強いフレームワークなどを導入することも充分検討に値します。

データの付加データと分類について

データには当然何かしらのデータ項目、カテゴリー分類などを施すことになります。
まず、Wordpressにはデフォルトでカテゴリーおよびタグのタクソノミー（分類法）があり、複数カテゴリー付けも、親子関係も定義出来る本格的なものです。
　階層化されたカテゴリーならば、こちらをそのまま使う事が素直ですし、カテゴリーの設定も通常のWPと同じですので馴染みやすいインタフェースをつかうことが出来ます。
　ただし、独自の検索ロジックを付加する場合、タクソノミーを含め、さらにpostmetaを併用したSQLを作るのはなかなか骨が折れます。
　タクソノミーはDB的には多対多の関係にあり、複数のテーブルを多重連結しますので、ロジックは複雑になり、さらにDBにかかる負担も比較的大きくなります。

　そこで、タクソノミーは限定的に使い、主なデータはpostmetaの方に格納するという方法が一番現実的と言えます。
その方が、複雑な検索をする場合、はるかに明快なロジックを組む事ができるでしょう。
　もちろん、カテゴリーを辿って行くだけという簡易検索で良ければ、カテゴリーを使ったり、カスタム・タクソノミーを作成するのもひとつの方法です。

ひたすらSQLのみで複合的な検索を行いたい場合のTIPSが見つかりました。
http://stackoverflow.com/questions/15243114/wordpress-join-wp-post-and-wp-postmeta

この方法の要点ですが、
wp_post とwp_postmetaをエイリアス(v1,v2,v3…)を付けて複数回LEFT JOINすると、すべてのメタデータごとにSELECTがなされ膨大な件数になります。
そこでWHERE句とAND句で、「該当のmeta_keyを持つものだけ」を絞り出します。そうすると選択結果のmeta_keyとmeta_valueがカラムとして並びます。
カラム名は重複しますがエイリアスを付けているのでv1.meta_value , v2.meta_value…というように区別できます。
あとはその中から、さらにWHERE句とANDやOR句で絞り込むだけになります。
私としては、はじめの連続したLEFT JOINの結果が正確には理解できないでいるのですが、結果的にはmetaデータ形式のものをカラム＆ロー形式に持っていくことが出来ました。
　ただ、この方法はさすがにDBを酷使しているように感じますので、パフォーマンスが落ちないよう、入念に項目の設計をした方が良いように思います。