2

私はビジネスアプリ（asp.net）に取り組んでいます。現在、SQLサーバーを使用しています。しかし、今後は少なくとも mysql と postgresql をサポートする予定です。将来の頭痛の種を避けるために考慮すべき問題は何ですか? 特にデータ型 (列の型) について。たとえば、一部のデータベースでは BIT 列がサポートされていないと思うので、tinyint を使用しますか?

私は主にプレーンな SQL (エンティティ フレームワークや linq などは使用しない) を使用し、できるだけシンプルに保つようにしています。トリガーなどは使用していません。ストアドプロシージャを使用していますが、必要に応じてプレーンSQLに置き換えることができます。

4

3 に答える 3

1

唯一の希望は、Remus Rusanu が示唆するように、データ アクセスを適切なデータ アクセス レイヤーに分離することです。データ アクセス レイヤーは、コードの残りの部分に対して 1 つの一貫したインターフェイスを持つことができ、各 DB プラットフォームの他のバージョンに変更できます。SQL をかなり標準に保つことは役に立ちますが、SQL コードの 1 つの本体を記述してどこでも機能させることは実際には不可能です (SQL 標準はそれほどうまく実装されていません)。

于 2009-07-30T17:16:27.767 に答える
1

NHibernate ( https://www.hibernate.org/343.html )のような OR/M に基づくドメイン モデルとデータ アクセス層の採用を検討してください (学習曲線の観点からいくらかのコストがかかります)。

于 2009-07-31T14:43:09.750 に答える
0

具象ではなく抽象IDbConnection、IDbCommand、IDataReaderを使用して、すべてのクライアント コードを記述してください。また、SQL ステートメントを常にチェックして、互換性のある構文のみを使用するようにする必要があります。

また、OdbcConnection /OdbcCommand コンポーネントを介して接続を試み、一般的な ODBC 構文と一般的な ODBC データ型 (つまり、ODBC エスケープ構文) を使用することもできます。{fn SUBSTRING(...)}

別の方法として、データ アクセスを分離し、バックエンドごとに特定の DAL クラスを作成することをお勧めします。XML と XSLT を使用して DAL コードを生成します。これと同様に、私のブログの XSLT コード生成を統合する手法ですが、バックエンド固有のコードごとに特化した XSLT を使用します。

于 2009-07-30T00:05:14.160 に答える