1

Visual Studio 2010を使用していますが、これはVS2003で最初に考案されました。

私は私のチームに最高の提案を転送します。現在の設定ではほとんど嘔吐します。これは、.sqlファイルを含むほとんどのプロジェクトでのC＃ソリューションです。Microsoft、Oracle、Sybaseをサポートしているため、Cプリプロセッサとよく似た自作のプリプロセッサですが、そのyaccようなツールを使用せずに自作のC＃プログラムによって置換が実行される点が異なります。#ifdefs条件付きマクロ定義に使用されます。そうです-マクロはこれを行う方法です。マクロは別のマクロに拡張できますが、最終的には終了するはずです。マクロのみが#ifdef含まれています。SQLのようなコードの残りの部分は、これらのマクロを使用するだけです。

さて、さまざまな構成：Debug, MNDebug, MNRelease, Release, SQL_APPLY_ALL, SQL_APPLY_MSFT, SQL_APPLY_ORACLE, SQL_APPLY_SYBASE, SQL_BUILD_OUTPUT_ALL, SQL_COMPILE、およびさらに2つ。

また：Any CPU, Mixed Platforms, Win32。

私を悩ませているのは、正しく構成する必要があることと、構成から適切なものを選択すること、12 x 3 = 36およびデータベースのタイプ（config、main、またはgateway）に応じてデータベース名を置き換える必要があることです。構成をDebug、Release、およびSQL_APPLYだけに減らす必要があると考えています。また、0、1、2を使用するのは80年代のようです...最後に、3種類のベンダー向けに3種類のデータベースを構築するかどうかの意図は、次のようなチックタックボードだけで構成する必要があると思います。

XOX
OOX
XXX

この場合、MSFT + CONFIG、すべてのSYBASE、およびすべてのGATEWAYをビルドすることを意味します。

それでも、テキストファイルとプリプロセッサおよび多くの構成を使用する全体的なものは、信じられないほど不格好なようです。今は2010年であり、そこにいる誰かが非常にクリーンで創造的なツール/ソリューションを持っているはずです。唯一の利点は、既存のマクロのコレクションが十分にテストされていることです。

複数のベンダーで機能するSQLを作成する必要があったことはありますか？どうやってやったの？

SqlVars.txt（30人のユーザー全員がテンプレートのコピーを作成し、ニーズに合わせてこれを変更します）：

// This is the default parameters file and should not be changed.
// You can overwrite any of these parameters by copying the appropriate
// section to override into SqlVars.txt and providing your own information.

//Build types are 0-Config, 1-Main, 2-Gateway
BUILD_TYPE=1

REMOVE_COMMENTS=1

// Login information used when applying to a Microsoft SQL server database
SQL_APPLY_MSFT_version=SQL2005
SQL_APPLY_MSFT_database=msftdb
SQL_APPLY_MSFT_server=ABC
SQL_APPLY_MSFT_user=msftusr
SQL_APPLY_MSFT_password=msftpwd

// Login information used when applying to an Oracle database
SQL_APPLY_ORACLE_version=ORACLE10g
SQL_APPLY_ORACLE_server=oradb
SQL_APPLY_ORACLE_user=orausr
SQL_APPLY_ORACLE_password=orapwd

// Login information used when applying to a Sybase database
SQL_APPLY_SYBASE_version=SYBASE125
SQL_APPLY_SYBASE_database=sybdb
SQL_APPLY_SYBASE_server=sybdb
SQL_APPLY_SYBASE_user=sybusr
SQL_APPLY_SYBASE_password=sybpwd

... (THIS GOES ON)
4

2 に答える 2

2

複数のベンダーで機能するSQLを作成する必要があったことはありますか？どうやってやったの？

ORMを使用しました。NHibernateを確認してください。VS2010を使用しているため、MS ADO.NetEntityFrameworkを確認することもできます。
ORMを使用すると、データベースを高度に抽象化できます。RDBMSごとに個別に作成する必要のあるクエリは引き続き存在しますが、私の経験では、10％未満です。

その他の商用およびオープンソースのORMのチェックウィキペディアの記事：オブジェクトリレーショナルマッピングソフトウェアのリスト。

編集：再取引プラットフォームのコメント：

私はそのようなプロジェクトに携わったことがないので、意味のあるアドバイスをすることはできません。一般的な提案として、ORMは、データアクセス層を統合し、RDBMS固有のコードの必要性を最小限に抑えるのに役立ちます。ほとんどのORMは、データベースを自動的に生成することもできます。

これによるパフォーマンスの低下は、私にはわかりません。商用とオープンソースの両方のトップORMでいくつかのテストを行ってから、決定する必要があります（Microsoftは、おそらく、市場でEntity Frameworkを使用している会社と協力することに関心があるでしょう）。

また、既存の製品にORMを導入するのは難しいので、これも考慮に入れる必要のある問題です。

于 2010-06-10T22:11:59.720 に答える
0

複数のベンダーで機能するSQLを作成する必要があったことはありますか？どうやってやったの？

基本的には、データ層と他の層の間に抽象化レイヤーを追加することでそれを行います。次に、いくつかの選択肢があります。

  1. スマートORMを使用して、データ層を構築し、データベースの特異性を考慮します
  2. サポートされるデータベースシステムごとにライブラリを作成するプロバイダーモデルを使用してデータ層を作成し、構成ファイルから何かを読み取るコードを使用して、ロードするプロバイダーを決定します。

あなたの状況における根本的な問題は、データ層が単一のライブラリにカプセル化されておらず、他の層から完全に保護されていないことであるように思われます。それが本当なら、緩い凝集度と緊密な結合があなたの悩みの原因のいくつかです。

現在のライブラリをリファクタリングして、すべてのデータベースの相互作用が単一のライブラリ内で行われ、インターフェイスを介してその上の層から完全に抽象化されるようにすることを検討する必要があります。これは、問題のデータベースに適切な具象クラスをロードするファクトリメソッドがあるデータベースに依存しないインターフェイスまたは抽象クラスを最終的にすべての呼び出しが通過するまで、複数のリリースサイクルを通じて段階的に実行できます。

詳細情報：

于 2010-06-11T05:14:49.907 に答える