著者から
ネットワーク管理者の職業をプログラマーの職業に変えてから1年が経ちました。 今年は多くの異常で奇妙なものでした。 私はsqlalchemyと密接に連携し、ポニームを見て、hibernateとnhibernateで遊んで、djangoからモデルを更新しました...そして、あなたは何を知っていますか？ 私が見たすべてのコードは、手rena弾の予備の猿の活動の結果に関連していました...プログラマーをデータベースに入れるのは良い考えではないことが判明しました。 カットの下では多くの痛みと憎しみがありますが、突然誰かにとって重宝します。
始める前に、いくつかの前提を紹介したいと思います。
- すべてのテキストは私見です
- すべての名前とケースは合成です。 実際のプロジェクトや人々との偶然の一致は偶然です。
- 著者は、グレートとマイティで大きな問題を抱えています（私たちは個人的なメッセージを通して戦います）
ORMとは何ですか？
誰かに心を教える前に、用語ORMが何であるかを理解する価値があります。 TSBの類似によれば、略語ORMはブルジョア語の「オブジェクトリレーショナルマッピング」を表し、プーシキンの言語に翻訳されて「オブジェクトリレーショナルマッピング」を意味し、「データベースをオブジェクト指向プログラミング言語の概念と接続するプログラミングテクノロジー」を意味します。 。 ORM-データベースとプログラマーによって記述されたコードの間のレイヤー。これにより、プログラムで作成されたオブジェクトをデータベースに追加したり、データベースから受信したりできます。
すべてがシンプルです！ オブジェクトを作成し、データベースに配置します。 同じオブジェクトが必要ですか？ データベースから取り出してください！ 独創的！ しかし！ プログラマは略語の最初の文字を忘れており、全員が同じプレートにこだわっています！ 論理的なオブジェクトのプロパティから始まり、外部キーで終わるのは、オブジェクトとは関係ありません！ そして何よりも、多くのハウツーと例がこのアプローチを広めています...根本的な原因は、「私はプログラマー」と「私はデータベースのアーキテクト」との間の絶え間ないバランスにあるように思われます ORM乗算と乗算-プログラマーの声が建築家に圧力をかけます。 すべて、それ以上の痛みはなく、私見だけです。
「ブルックスさん、あなたは誰ですか？」または「オブジェクトとは何ですか？」
ORMで「オブジェクトとは」を定義する方法は？ 初めて全体のポイントを伝えることができる人は何人ですか？ 試してみましょう。
私たち全員が私のようにベラルーシ/ウクライナ/ロシアに住んでいるとします。 法律によれば、同性婚および一夫多妻制は国内で禁止されています。 同時に、性別ごとに「軍事義務」およびその他の「特定の」特性の概念があります。 これから何が続きますか？
- 性別ごとに、サインを付けることをお勧めします（必須ではありません）
- 夫の妻に関する情報を保存する必要がある場所、またはその逆
「これがOneToOneです！ クラシック 何がそんなに複雑なの？ 男性または女性の行でfkeyを定義し、実行しました」-はい、私は心を読むことができます。 しかし！ 1年後、私たちのソフトウェアはアラブの王族にとって興味深いものになりました。 はい、誰にfkeyを追加しますか？ 男性の性別？ 女性？ そして、すべてが1つのテーブルにある場合-誰が高齢の女性が配偶者を持たないことを確認するロジックを書いて同行しますか？
はっきりしない わかった 擬似コードを見てみましょう：
man_1 = new Man()
man_1.name = ""
woman_1 = new Woman()
woman_1.name = ""
???
次は？
man_1.wife = woman_1
または
woman_1.husband = man_1
そして、これをデータベースに保存する方法は？ しかし、まさか！ 例では、データ構造に対する明らかに間違ったアプローチです！
woman_1およびman_1オブジェクトのnameプロパティはORMオブジェクトのプロパティですが、man_1オブジェクトのwifeプロパティとwoman_1オブジェクトの夫はすでにORMオブジェクトのリレーションです！ これらは異なる性質です！
まだ不明ですか？ わかった もっと人道的な言葉で問題に取り組みましょう。
イヴァンとタチアナがいます。 彼らが拒否されたら？ そう！ 彼らは変わりません！ そして、あなたがイワンに手を（または他の重要な器官）を引き裂き、タチアナの髪を剃るなら、それらは変わります！ したがって、結婚は物の態度であり、手と髪は物の性質です。 すべて、私は他に説明する方法を知りません。
OOPのp状
少なくとも、オブジェクトを理解するようになりました。 誰が誰であるかが明らかになりました。 しかし、ITをDBに保存する方法は？ 賢い顔と長いひげを持つ仲間の中には、「すべてがオブジェクトである」という主張を唱える人もいます。 ORMを検討しているので、同じことに固執してみましょう。 オブジェクトManとWomanには異なるテーブルを使用するとします。 関係の「オブジェクト」をどこに保存しますか？ そう！ 別のテーブルに！ 彼女を
woman_and_man
と呼びましょう。 これまでのタブレットでは、fkeyを表す2つの列（man_idとwoman_id）しかありません。
「ちょっと待って、これはすでにある種のManyToManyです！」-ええ、まだあなたの考えを読んでいます！ 原則として、1つのmaaalenkoyの修正条項に同意します。 woman_and_manテーブルに正しい制約を定義すると、手首を軽く押すだけでOneToOneに変わります。 信じられない？ やってみます！
OneToOneの場合、次のルールを遵守する必要があります。
- 1人の女性が複数の男性の夫を持つことはできません
- 1人の男性が複数の女性の妻を持つことはできません
対応する制約を導入します。
- テーブルwoman_and_man内のman_idの値は一意であり、nullでない必要があります
- woman_and_manテーブル内のwoman_id値は一意であり、nullでない必要があります
それだけです！ OneToOneがあります！
UAEへのエクスポート用のソフトウェアを送信します-man_idの制約を変更して、ManyToOne / OneToManyを取得します！ テーブル構造は変更されず、制約のみが変更されることに注意してください！
相互一夫多妻制/一夫多妻制の国に輸出するためにソフトウェアを送信します（そして、そのようなものがあります！？）-woman_idの制約を変更し、ManyToManyを取得します！ テーブル構造は変更されず、制約のみが変更されることに注意してください！
ORMを確認してください-extを介してOneToOne / ManyToOne / OneToManyを使用する例があります。 テーブル。
批評家専用
リーダーに私の考えを述べた後、私は期待される応答を得ました：「なぜこれを複雑にしますか？ キス！」
「経験を積む」必要がありました。
fkeyプロパティを含むオブジェクトと、xml / jsonでのこの不名誉の「バックアップ/シリアル化」のタスクとの間に循環関係がある場合がありました。 いいえ、バックアップは行われますが、後で復元するのは非常に困難です...復元/逆シリアル化中に作成されたプロパティを厳密に監視し、オブジェクトを繰り返して接続を復元する必要があります。 上記のルールを順守-最初にオブジェクトを復元し、次にオブジェクト間の接続のみを復元する必要があります。 なぜなら この情報は異なるテーブル/エンティティに保存されます-ロジックは線形でシンプルでした。
攻撃ごとに、「mongaを使用して心配しないでください」または「ドキュメント指向のデータベースステアリング」で、誰もカバーできない同じ結果に常に到達しました。
任意のデータ構造（任意のドキュメント）を保存するスキーマをリレーショナルデータベースに作成できますが、ドキュメント指向データベースのリレーショナルデータベースレベルでデータの整合性を保証できますか？ 私はそのレベルに到達できませんでした。
誰でも、任意のレベルのネストを使用して、複数の重複ドキュメントを気にしませんか？ いいえ、ストレージが最適化されていることを知っていますが、それを行うだけで、違いは何ですか？ しかし、まだ。
PSこれは、ORMに関連する「意識の流れ」全体ではありません。 nullには2、3の段落、クエリの最適化とオブジェクトの遅延読み込み、2つの関係プロパティの段落があります（そうですね）。 批評家にコメントでコメントするようお願いします。 続編には特に鋭く興味深い質問を掲載します。