web-dev-qa-db-ja.com

負の数を使用して業界標準のデータモデルを拡張しても大丈夫ですか

独自のデータセットに依存する必要があるクライアントとのプロジェクトに取り組んでいます。また、独自のデータと論理的に一致するカスタムデータもあります。彼らがすることは同じテーブルを使用することですが、IDは負です。したがって、例は

表：動物

フィールド：animal_id、name、can_purr

したがって、データを提供する組織は動物を提供します

1, Cat, yes
2, Dog, no
3, Mouse, no

そして、私のクライアントはFrankenmalsを追加しています

-1, Werecat, yes
-2, Werewolf, no
-3, Jackalope, no

そのため、他の動物のFKをWerecatとJackalopeで再利用できます。多くの場合、新しい動物はデータ管理者によって認識され、追加されるか、何かが新しいものに進化するため、元のキーを維持することが重要です。フランケニマル業界はすべてこのデータベースを使用しており、Animal 1について話しても私は理解できますが、Animal 1を猫以外のゴロゴロできるものに変えた場合は理解できません。 -2と2の間には、暗黙の関係または維持される関係はありません。

負の数はそれを行うための最良の方法かもしれません。 IDが単なるレコードの識別以外の何かを表すため、皮膚がクロールされます。

現在、他の多くのシステムが変更されています。これが優れたデザインではない場合は、今が変更する時です。

負の数のアプローチに何か問題はありますか？私が目にする主なリスクは、データ管理者が独自の目的で負の識別子を使用することを決定したかどうかです。自動更新は大混乱を引き起こす可能性があります。しかし、自動化はその状態をチェックすることができるので、それほど悪くはありませんか？

これに関するベストプラクティスのアドバイスはあまりわかりません。それで、あなたは負の数のアプローチをして、それを後悔しましたか？どうして？または、新しいスキーマに変換してから、メンテナンスやその他の理由でそれを後悔しましたか？

これが主観的すぎる場合は、申し訳ありません。私が非論理的であるのか、レコードIDの二重の目的が再設計に値するほど悪いのかを見つける方法がわからないだけです。

database-designindustry-standard
7
microsaurus_dex

実用的な観点から、本当に重要なのは、Animalテーブルにアクセスするすべてのコードがこれらの負のIDを正しく処理することが保証されていることだけですか？コードは完全に管理されていますか？ 「業界標準」のデータモデルについて話しているので、たぶん、いくつかのERP system？ ？このための標準ソフトウェアを提供するサードパーティベンダーが関与していると思います。

したがって、その「業界標準」のドキュメントを確認してください。「カスタマイズの目的で負のIDを安全に追加できる」などと表示されている場合は、先に進んでください。さもなければ、それが今でも機能しても、外部ベンダーのソフトウェアの次のバージョンが現在の使用法と衝突するかどうか確信が持てません。したがって、あなたがしていることに負のIDを使用できると100％確信できない場合、この方法でシステムを破壊する特定のリスクが生じます。

5
Doc Brown

2つのデータセットを使用しています。これを隠して1つに統合しようとすると、奇妙な副作用が発生し、後で問題が発生する可能性が高くなります。

すべてのフランケニマルを含む元のデータベースと同じ列を持つテーブルを備えた個別のデータベースを作成することをお勧めします。

次に、アプリケーションのデータセットを認識させ、タプルを使用します{dataset, row_id}をアプリケーションで使用します。これは素晴らしい、クリーンで拡張可能なものです（追加のデータセットを追加できるため）。また、アプリケーションでデータセットを操作することもできます（たとえば、公式データセットのみ、マージされたデータセット、カスタムデータセット-1の結果を比較するなど）。

3
Wilbert

それは素晴らしいアイデアではありません。

最良の方法は、独自のIDを持ち、それを外部データIDにリンクすることです。

動物テーブルの文字列IDがあるとしましょう

MyAnimals
MyId,                                 name
230a33e0-ffa4-47ff-9ccb-b3bcf3a33166, Werecat
89f990d5-88eb-4055-b7fe-787cf75d0461, Werewolf


ExternalAnimalLink
MyId,     ExternalDataSetId, ExternalId
"1",      "aniCorp2018",     1
"2",      "aniCorp2018",     2
"wd_2",   "wildData2001",    2

負の数のアプローチの欠点。

  • 外部プロバイダーがそれらの使用を開始した場合はどうなりますか？
  • 数値も使用する3番目のプロバイダーが必要な場合はどうなりますか？
  • 負の数値がエラーを表すために使用されている場合（悪いが一般的）
  • Uintがある時点で使用された場合、またはネガティブが他の方法で無効になった場合はどうなりますか？
  • 番号に注文などの追加の意味がある場合はどうなりますか？

ただし、IDに数値を使用することによって引き起こされる問題も考慮する必要があります。

  • 次に利用可能なIDは何ですか？
  • これまでの動物の最大数は
  • 試験動物についてはどうですか、彼らは数を取得しますか？
  • 数はすべてのデータベースで同じ動物と一致しますか？

などなど

2
Ewan

彼らの標準のドキュメントはこれについて議論していますか？

金融サービス業界では、独自仕様の拡張を可能にする文書化された標準が見られるのはごく普通のことです。私が見たもののいくつかの例：

  • 拡張機能はありませんが、独自の目的でさまざまな「汎用」IDが提供されています。
  • nより下のIDは予約されていますが、nより上のIDはカスタムデータ用です。
  • クライアント固有のフィールドには負の数を使用できます。

私は上記の方法をすべて見て使用したので、負の数を使用することは実行可能な解決策になる可能性があります。ここで重要なのは、ドキュメントを確認することです。ドキュメントでカスタムIDの機能が指定されていない場合は、標準のメンテナ/委員会に有効な改善策として提示することをお勧めします。ただし、最終的に、標準がexplicitlyで負の数値を使用できると述べていない場合、他のコード（たとえば、サードパーティのアプリケーション）が負の数値をサポートしていないと、問題が発生するおそれがあります。

1
Karl Nicoll