当社には、顧客情報データベース用のASP.NETアプリケーションがあります。アプリケーションは小規模で始まりましたが、適切な設計なしで成長しました。ここで、アプリの新しいバージョンを開発する必要があります。これは、基本的に、アプリを最初から設計および実装することを意味します。同社は将来的にMicrosoftSharepointServicesを利用することに関心があり、この顧客データベースアプリケーションでパイロットすることが提案されています。
だから私の質問は：
データベース駆動型アプリケーションはWSSに適していますか？ほとんどの場合、アプリはデータベースに対してCRUD操作を実行し、レポートも作成します。
簡単な答え：いいえ。
長い答え：コラボレーションはありますか？データのサポートドキュメント？ワークフロー？いいえの場合、SharePointを介してホストする理由は実際にはありません。多くの利益は得られません。
さらに、SharePointリストはテーブルのように見えるかもしれませんが、そうではないことに注意してください-リストの関係の側面はありません-結合、カスケード更新/削除などはありません。これは、データレポートがアプリの大部分。
データを外部に保存してSharePointで読み取り専用リストとして表示することはできますが、他のSharePoint機能を使用していない場合は、まだ多くの作業を行っています。
データをSharePointリストに入れることを必ずしもお勧めしないという点でGregに同意します（これはGregが想定していることです）。しかし、私の短い答えは「たぶん」でしょう。
これが長い答えです...
SharePointはASP.NETで実行されるため、ニーズに対応する必要があります。データベースにアクセスするSharePoint内にあるASP.NETWebページを作成するか、データベースにアクセスするSharePoint内にあるWebパーツを作成する可能性があります。
データの読み取り/取得にBDCを検討することもできますが、これにはMOSS Enterpriseが必要であり、CRUDのCUD部分は提供されません。CorasWorks DITのような他のツールが役立つかもしれませんが、カスタムWebパーツまたはページがあなたのために行く方法であると私は思います。
承認や、データとSharePointリストデータの統合、プロビジョニング、検索など、SharePointから得られるメリットはたくさんあります。SharePointが多くの機能を提供するかどうかは、アプリケーションの性質によって異なります。利点。
カークは私を殴ってパンチし、とにかく私が持っているよりも良いと言った:)
考慮すべきもう1つのことは、プロセス内のワークフローの可能性です。たとえば、新しい連絡先が追加されたときにプロセスを開始する必要がある場合（フォローアップの呼び出しなど）、SharePointは大きなメリットを提供します。
おそらく、ハイブリッドソリューションが適切でしょう。意味があり価値を提供する部分のためのCRUDとSharePoint統合のためのカスタムアプリ。
SPを使用するためにSPを組み込むことは、おそらく良い考えではありません。
MOSS 2007で実行されるASP.NETアプリケーションがあります。SharePointの機能はほとんど使用していませんが、SharePointのセキュリティモデル、ナビゲーションWebパーツ（CorasWorksを使用）、統合されたReporting Services、およびワークフローを利用できます。少なくとも、SharePointの機能はいつか使用できるようになっています。
すべてのアプリケーションデータは、独自のSQLServerデータベースにあります。SharePointコンテンツデータベースには何も保存しません。