今日、データベースでの作業が彼の視野に入るとすぐに、開発者が直面する1つの問題を表明したいと思います。 最も悲しいことは、私はそれを正しく解決する方法と、何をすべきかわからないということです。 むしろ、私はそれを知っていますが、それは私を助けませんし、助けません。 あなたもそう思う。
以下は長い紹介であり、その結果によると、私はいくつかの7-Bフォームと生涯にわたる強制治療の指示に十分であると私について多くの興味深いことを言うことができますが、あなたはそれを読む必要があります。
これは企業の赤ちゃんです
入力には、ソフトウェア、複雑なビジネスロジック、および開発されたデータスキームを備えた製品があります。大量のデータ（数十ギガバイト）があり、それらの関係には特定の順序が観察されます。 特定の数のクライアントは、ビジネスロジックとデータロジックを
「異なる要件」とは、それらすべて（顧客）が異なるデータを必要とすることも意味します。 彼らの正しい考えでは、これは
そのような最初のフォールアウトは、データベース内のクソフィールド自体です。 典型的な「ビジネスプロセスを開始するためのデータ入力ウィンドウ」を見たことがありますか？ はい、はい、それは正しいことです、間違っていても。 10個のブックマーク、それぞれ100個のフィールド。 それらはそれぞれ何らかの形で（アタング、魔法！）データベースに分類され、プログラムの長い年月の間に追加されました。一部は独自のもの、一部は分析用のものです。 それらは追加され、なぜそれが必要なのか誰も覚えていないまで追加されます：新しいフィールドが必要でした-彼らはそれをどこにでも追加し、レポートに追加し、分析を変更しました。 分析が1つの合計/カウント/ group_byと見なされると便利です。
Bまず、テーブルに新しいフィールドを追加する作業は、主に
-「データベースへの追加、テーブルへの追加、オブジェクトへの追加、UIへの追加」。
-分析/アプリのワークフローで別の混乱をすくい取ります。
たとえば、sqlをコンパイルできない場合、必要なすべての場所で関連するものを更新するように非常に注意する必要があります。 実際には、「注意する」とは、99％の確率で最初のコンパイルと展開を行った後、システムが機能しないことを意味します。 おそらく、2回目以降も-クラッシュ、エラーなどが発生します。 自動テストを使用してある程度制御することができます。 しかし、道徳的に非常に絞め殺します。
最後に、2番目のサブプロットは次のとおりです。2つのフィールドを追加する必要があります。2倍の作業が必要です。 5つのフィールド-...まあ、あなたは理解しています。
徐々に、このマックはアプリケーション全体に広がります。 1〜2年後、アプリケーションは1つのタスクのみに従属するようになります-どのフィールドとどこにロード/保存/更新するかを把握します。 このようなもの： govnokod.ru/1071
これはどうして私に起こるのでしょうか？ 今生きる方法は？
継承（Active Recordだけでなく）にすることは機能しません。ほとんどの場合、適切な関係を見つけることを忘れずに階層を構築することは不可能です。 オブジェクトモデルの正しさを忘れると、松葉杖が得られます。これは、各場所で、オブジェクトのタイプを操作して異なる方法で作業するかどうかを確認する必要があるという事実で表されます。 「オブジェクトに追加」した後、階層を処理することも必要になるという選択肢があります。 さらに、私の個人的な潜在意識はこの場所での相続に反対しています。
たとえば、エンティティ属性値でモデルを美しく配布しようとすると、リクエストで完全なロバが出てきます。
-それらを手動で書くことは、何が起こっているのかを単に理解することよりもさらに悪い。
-パフォーマンスがパイプにクラッシュします。DBMSサーバーはjoin-sで非常に忙しく、残りはisいアイドル状態です。
別の試みられたオプションは、オブジェクトを忘れてメタデータを使用することです。 つまり、メタデータを持つ別のデータベースがターゲットデータベース内に作成され、テーブルやその他の機能の構造と構成に関する情報が本質的に複製されます。 それらのために特別なエディターが起動され、メガ抽象化レイヤーが（動的ストレージおよびビュー上に）形成されます。 各サーバー応答にデータが含まれる場合、このデータのメタデータもクライアントに送信されます。
データとスキームに応じた冗長性に加えて、ここではデータベースを更新するという地獄、そしてメタデータをリレーショナルな方法で操作する必要性を待っています。これは、開発者の脆弱な精神にとって非常に有害です：再帰を理解するには、再帰を理解する必要があります ある種の多少複雑なUI動作を絞り込もうとすると、英雄的な失敗と、理解/記憶する必要のあるメタデータの量の組み合わせの爆発が起こる運命にあります（システムでフィールドの変更に関する通知がどのように行われたかを知っていますか？フィールドとキャッシュされた値との比較、フラグの設定。例外がスローされるとすぐに-前の開発者はNullReferenceを通常のビジネスケースと見なしさえすると-スレッドはクラストに飛んで、アラートの受信を停止しました。 私が）はい、私は、すぐに彼が聞いたとして、それを削除しました。しかし、土砂が残って、雨靴。 そして、「これを更新する-それらを更新する」というサイクルは消えていません。 失敗。
また、非同期メタデータとロジックコードもあります。 また、顧客のDBAもあります。これについては、ロシアルーレットの
もう1つのテスト済みオプション（詳細）は、自己記述ORM +独自のオブジェクトシステムです。 リレーショナルデータを扱うのにあまり適していないという事実については、データベーススキーマの更新に関する待ち伏せを待っています。 そして、コードは厄介になります-オブジェクトの上に再びオブジェクトを配置して実装する必要があります。 これを書いてから、非常に小さな喜びが追加されます。 まあ、これが単なるガイドである場合。 これがルックアップテーブルまたはオントロジー分類子セグメントである場合 そして、最も興味深いのは、レポートをどうするかということです。
真実を求めて、アプリケーションサーバーがメタデータの説明の使用を開始すると、コードジェネレーターはオブジェクトのファミリを発行し、Aggregation Rootがそれらを処理するようになりました。 また、ライブラリは接続中にクライアントに転送され、生成されたツールが含まれます。 スズは、それよりも短いです。
私は通常、検証、プロセスなどのビジネスロジックについては黙っています。CustomSharpのスクリプトにはひどいものがあります（これはビジネスロジックの説明を
ミスアドベンチャー
実際には、説明したすべてのオプションを試し、同行しましたが、どれも好きではなかったのは、もはや秘密ではないと思います。 確かに、最後の公園では数少ない公園がありましたが、それでも私たちは不潔なバケツでたわごとを飲み続けました。
どうする？ 私は沼地に浮かぶ穴の開いたボートを通り抜けて座っているような感覚があり、私の手には2つのブリキのマグがあります。 それと別の両方を非常に迅速に行い、優先順位を理解する必要があります。
PSいくつかの魔法の言語で書いた場合、各ユースケース/スクリプト/プロセスは、データを監視し、オンデマンドでロードし、マッピング用のエディターと属性を含み、ロード時に組み合わせることができる個別のモジュールで引き出すことができます他のそのようなモジュールと-コードとデータの両方で、データベースと通信し、構造を透過的に更新します。 この魔法の言語では、システム構成を簡単に変更して新しい顧客に販売できます。コアは同じですが、データ/ロジックの充填は異なります。
誰もそのような魔法の言語やシステムについて知っていますか？ SAP / MDMは提供していませんが、ブランドのため
どうやって、このくそったれと手で戦うのですか？