いつものように、 "それは依存..."。
受信するデータの性質に、固定スキーマがないか、ビジネスロジック/ドメインロジックの一部として頻繁に変更されるスキーマがある場合は、それを管理するソリューションを設計することをお勧めします。デザイン時にスキーマがわからないデータを保存することは、StackOverflowの長期的な議論です。「プロパティバッグ」、「エンティティ属性値」またはEAVを探して、さまざまな質問と回答を確認してください。
このアプローチであきらめるのは、Webサービス層で、受け取ったデータが合意されたインタフェース契約を満たしていることを確認する機能です。これにより、あらゆる種類のエキサイティングなバグを避けることができます。無効なXMLを受け取った場合、システムはどうしたらよいでしょうか?合意されたスキーマ/ dtdがなければ、コードにあらゆる種類のチェックを組み込む必要があります。
データベースレベルでは、通常、従来の行と列の関係がなくてもデータを格納するリレーショナルモデルの側面(したがってSQLの能力)をあきらめることになります。そのため、クエリが困難になることが多く、ベンダー固有の拡張機能を使用するなど、標準への準拠を犠牲にする可能性があります。
技術的な理由でデータが変更された場合、つまり変更するデータの性質ではない場合は、これを心配するのはテクノロジーチェーンだけです。代わりにバージョニングという概念を構築することをお勧めします。異なるバージョンの「強く型付けされた」サービス/データを持っている。これがもっとうまくいくように見えますが、スキーマの検証、リレーショナルデータベースモデル、そして単純さに頼ることのメリットは、通常、それを良いトレードオフにします...
これは私が探していたものです。ありがとう!私はそれらの議論を見ていきます – Mage