私は現在、SQL Server 2000データベースを使用して古いASPアプリケーションに取り組んでおり、.NETとNHibernateを使用して新しいテクノロジに移植しようとしています。
そのDBでは、すべてのテーブルに次のように作成された複合IDがあります。
CREATE TABLE [Languages](
[languageIncId] [int] IDENTITY(1,1) NOT FOR REPLICATION NOT NULL,
[languageSqlId] [smallint] NOT NULL,
...
[createdByIncId] [int] NOT NULL,
[createdBySqlId] [smallint] NOT NULL,
...
[lastModifiedByIncId] [int] NULL,
[lastModifiedBySqlId] [smallint] NULL,
[rowguid] [uniqueidentifier] ROWGUIDCOL NOT NULL,
...
CONSTRAINT [PK_Languages] PRIMARY KEY CLUSTERED
(
[languageIncId] ASC,
[languageSqlId] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON, FILLFACTOR = 90) ON [PRIMARY]
) ON [PRIMARY]
GO
つまり、各テーブルの主キーは次のもので構成されます。
- アイテムが作成されたSQLServerインスタンスのIDであるXXXSqlId
IDENTITY
新しい行が挿入されたときにインクリメントされるフィールドであるXXXIncId
重要なのSqlId
は、レプリケーションが発生すると、レコードがデータベースから別のデータベースに移動され、複製XXXIncId
が発生する可能性があるということです。残念ながら、多くのアプリケーションがデータベーススキーマに依存しているため、データベーススキーマを変更することはできません(これは確かに苦痛です)。
これは、テーブル間に関係が存在する場合は常に、のように両方のフィールドを指定する必要があることも意味しcreatedByIncId , createdBySqlId
ます。
この構造をNHibernate(流暢かどうか)でマッピングするための最良の方法を探していますが、ブロックされています。私は次の解決策を検討しました:
- SqlIdおよびIncId(最も自然なソリューション)でComposite-IDを使用しますが、IncIdはデータベースによって生成され、CompositeIDは「生成された」属性をサポートしないため、機能しません。
- これらのフィールドを完全に無視し、「rowguid」を実際のIDと見なします。これは、「複合ID」をリンクとして使用する必要があるエンティティ間の関係を試さない限り、うまく機能します...
- カスタムコンポジットユーザータイプ(
ICompositeUserType
)を使用する:ただし、これをエンティティのIDとして使用することはできません。
私の質問は質問1615647にかなり似ていますが、答えは私にとって満足のいくものではありません。
フォローする別のリードのアイデアはありますか?