私は最近、.NET の可能な ORM ソリューションを多数評価してきました。もし私があなただったら、MS SQL 以外のものを使用する場合は Entity Framework のルートには行かないでしょう - 概念的なエンティティ モデルの問題は別として (これは一般的なものであることが意図されていますが、このモデルでシーケンスのようなものをキャッチする方法はありません)。あなたはサード パーティのデータベース ドライバー プロバイダーの開発者に強く依存しています。私にとっては、この方程式の多くの変数に間違いなく依存しています。
一方、Hibernate では、コードの汎用性と、選択した DB 方言に固有の両方を使用できます。例えば。そのような属性を Id プロパティに使用できます。
[Generator( Class = "native")]
//...
public virtual int CustomerId {get; set; }
SQL Server NH で "Native" ジェネレーター オプションを表示すると、それが ID フィールド (自動インクリメント) であると見なされ、Oracle の場合、このプロパティは同じ名前のシーケンスを使用すると見なされます (必要に応じてシーケンス名を変更できます)。
また、ほんの数日前に、MS は LINQ to SQL エントリ レベルの ORM を完全に廃止しました。彼らが Entity Framework で同じことをしないかどうかはわかりません。オープンソースの NHibernate ではそのような問題はありません。
特定のニーズを知らないDBを提案することはできませんが、フリーソフトウェア（Oracleを除く）を使用したい場合で、MySqlの経験がまだない場合は、MySqlよりも強力なPostgresを試してください.
とにかく、NHibernate を使用すると、後から DB をあまり苦労せずに切り替えることができます。
NHibernate でサポートされているデータベース方言のリストは次のとおりです:
http://www.hibernate.org/361.html
編集：すでにMySQLを知っていることに気づきました-とにかくNHibernateでDBを直接使用するつもりはないので、最初にMySqlから始めてORM部分に集中する必要があると思います-正確にNHibernateを制御する方が簡単ですDBでやっています。
ただし、NHibernate では、最初にデータ クラスを記述し、DB スキーマを自動的に生成できることを知っておく必要があります。このルートに従うと (DDD の観点からは良い考えです)、DB レイヤーは実際に透過的になります。