今日、タスクを設計するための従来のアプローチは、自動的にSQL DBMSを意味します。 システムの最後の層の前に、ガスケットを「DBMS abstraction」という大きな名前で置き換えます。 そして、何から抽象化しているのでしょうか？ MySQLから、Postgrssおよびその他のSQLは横向きになりました。 DBMSには他にも多くの種類があるため、障害が見つかった場合、おそらく「SQLの抽象化」になります。
プロジェクトデータのモデルを作成する場合、最初はテーブル、結合、およびユニオンで既に考えています。 SQLに感染しています。 デザイナーが特定のイデオロギーの間違いを犯すのは自然なことであり、これは悪い形とは見なされず、恥ではありません。 私は、プロジェクトの特定の独立した部分としてのデータモデルが、突然2つのコンポーネント（計算モデルとリポジトリ）に分割されるという事実について話しています。 ストアドプロシージャは何らかの方法でデータモデルをストレージに転送しますが、全体ではありません。 したがって、この概念の次の否定的な側面が得られます。
-非SQL DBMSを使用できない
-建築の調和が崩れている
-ORMは過剰なリソース消費に苦しんでいます。
代替として提供されるものは何ですか？ まず、データモデルを計算モデルの一部として完全に配置します。 SQLデータベースと汎用テーブルは忘れてください。 私たちのデータモデルは独立しており、特定の計算モデルに基づいたオブジェクトであり、テーブルではなくその用語で話します。 そこに格納されるテーブルをまったく気にすることなく、インターフェイスまたはAPIを考え出します。
インターフェイスを定義したら、モデルを特定のDBMSに接続するドライバーを作成できます。 これは完全な抽象化になります。 すでにしきい値に達している任意のSQL、さらにはファイルやBigTableを接続できます。 また、ドライバ自体は常に特定の種類のストレージに対して理想的に接地され、損失は最小限に抑えられます。
したがって、モデルデータを構築するときに一般的なリレーショナルテーブルを破棄し、プロジェクトの特定のニーズに専念すると、次の肯定的なポイントが得られました。
-DBMSの完全な抽象化
-建築の調和の維持
-ORMで速度損失なし
当然、このアプローチには独自のニュアンスもあります。 特定のリクエストでは、オーバーヘッドが発生する場合があります。 たとえば、製品のリストを要求します：
$製品-> getAll（）
このドライバーは、テーブル全体をシャベルし、2、3の結合を作成しますが、実際に必要なのは製品IDとその名前だけです。 以下に解決策があります。 データの保存方法について心配する必要はないと言いました。 はい、できますが、完全なスノッブである必要はありません。 99％のケースで、ストレージが何らかの形でリレーショナルになることを理解しています。 したがって、ドライバーがインターフェイス/ APIを設計するのに役立ちます。 追加のメソッドを作成するか、パラメーターを指定します。
$ products-> getIndex（）または$ products-> getAll（ 'brief'）
ほぼ同じ方法で、完全に抽象的な DBMSで完全に具体的なデータモデルを作成します。 ORMを使用しても意味がありません。 汎用オブジェクトチャームはすべて必要ではないため、ドライバー内での使用でさえ疑わしいでしょう。 モデル内のアプリケーション用に、特定の便利で適切に調整されたオブジェクトが既にあります。