ここ数日設計討論の心得
ここ数日、同僚と新しいプロジェクト、システムの設計案を討論しました.理は弁解すればするほど明らかになり、以前はぼんやりしていた考えや概念があり、討論に伴い、時には論争によって明確になることもある.
1つは、サービスインタフェースのべき乗等性です.
以前はサービスインタフェースをしていたが、この問題を考えたことがない.今回は静かに考えてみましたが、サービスインタフェースにはべき乗等性が必要だと思います.
すなわち、他の操作がない場合、同じサービスインタフェースに対して何度呼び出されても、システム状態および戻り結果は同じであるべきである.
そうでなければ、前後の足の2つを操作して、1つはOKと言って、もう1つは異常と言ってくれました.これは何の鬼だ.=
一般的な増削除については,削除は基本的にべき乗等性,さらには生まれつきべき乗等をサポートしやすい.
しかし、新たに、意味的には毎回1つのデータを追加するので、複数回の操作でデータが増えるのは当然です.
新規操作をべき乗等性操作にするには、重複チェックが必要です.ページコミットにはtokenを付けることができますが、サービスインタフェースは?
おそらく唯一のデータ検証をするしかないでしょう......この検証はトランザクションと同時処理にかかわる可能性があります......
そこで面倒なので、まあ、異常を投げ出してサービス呼び出し者に「データ重複」を伝えましょう.
これがサービスなのか何かの鬼なのか.=
私が今回作ったインタフェースは、「べき乗などの新しいインタフェース」に向かって一歩前進し、対外的な意味を維持しています.あなたは私にデータをくれて、私は唯一の標識を返します.同じデータは、同じIDを返します.
自己感覚良好o(*￣▽￣*)ゞ
二つ目はデータベースフィールド設計
同僚とシステム内のデータベース設計について議論する際、データベースフィールド設計の選択構想について話しました.
データベースは、sqlのさまざまな利便性を得るために厳格に従っているのか、複雑な構造(配列、さらにはjson)を保存して柔軟性と拡張性を向上させるのか.
シーンのデザイン
システムは、エンティティA、エンティティB、およびB 1に関する構成を行う必要がある.次のようになります.
A:Bは1:nの構成関係
A:B 1は1:1の配置関係
BとB 1は同型のデータである
将来的には、次のようになります.
A:D構成
A:E構成
……
論争の焦点
主に以下の2つの案です.
パターンのシナリオに従って、テーブルフィールドは「ビジネスID」、「銀行チャネルid」の2つのフィールドとして設計され、各ビジネス-銀行チャネルの構成は1行保存されます.たとえば(例;他の関連テーブルまたはベース構成テーブルは書かれていません):
A
B
123
B1
123
B2
123
B3
456
B2
456
B4
複雑なデータ構造を格納するスキーマ.表フィールドの設計は2つのフィールドですが、各データの「銀行チャネルid」フィールド、格納配列(json文字列を格納するスキーマも議論されています).たとえば、次のようになります.
A
B
123
B1,B2,B3
456
B2,B3
789
{"C":"B1","B":B3","B5"}
両案の長所と短所
パターンに従うスキームはsqlを最大限にサポートすることができる.例えば、運営にどれだけのAが指定されたBを配置したかを統計する必要がある場合(これは私が別の類似の需要をしたときに実際に遭遇したもので、前車の鑑と言える)、この案は簡単に結果を得ることができる.
ただし、パターンに従うためには、データ量(行数、実際の記憶領域ではない)が大きくなります.最悪の場合、50 w「Aの数」*(19「Bの数」+1「Cの数」)=1千万行のデータが発生する可能性があります.このような大きなデータ量から20行のデータが検出され(しかも関連クエリも行われる)、クエリの効率が危ぶまれます.
また、ライブラリテーブルの設計を厳格に規定したデータ構造およびエンティティ間関係に従う.すなわち,このテーブルはAからB/Cへのマッピング構成のみをサポートする.後続の需要のDまたはEがこのような構造、関係で構成されていない場合は、新しいテーブル構造で拡張するしかありません.
複雑なデータ構造を格納するスキームの長所と短所は基本的に正反対である.sqlのサポートが悪く、データはコードで追加の処理が必要です.実際に消費されるストレージ容量はさらに大きくなる可能性がありますが、データ行数は大幅に減少し(jsonを使用すると最悪50 w行)、クエリー効率は向上します.また、データが長すぎない限り、jsonは様々なデータ構造を互換性があり、非常に柔軟で便利です.
我々の議論の結果
私の理解はこうです.
1、前車の鑑があり、Bの構成データはsqlのwhere文条件として使用される可能性がある.複雑なデータ構造を使用する場合、この点はサポートしにくい.
2、データの行数の隠れた危険性は別の設計案と協力して解決することができる.
3、新しいデータ構造は新しいテーブルを拡張することによって実現できる.
これにより,複雑なデータ構造の優位性が縮小し,劣勢が拡大される.
1つは、サービスインタフェースのべき乗等性です.
以前はサービスインタフェースをしていたが、この問題を考えたことがない.今回は静かに考えてみましたが、サービスインタフェースにはべき乗等性が必要だと思います.
すなわち、他の操作がない場合、同じサービスインタフェースに対して何度呼び出されても、システム状態および戻り結果は同じであるべきである.
そうでなければ、前後の足の2つを操作して、1つはOKと言って、もう1つは異常と言ってくれました.これは何の鬼だ.=
一般的な増削除については,削除は基本的にべき乗等性,さらには生まれつきべき乗等をサポートしやすい.
しかし、新たに、意味的には毎回1つのデータを追加するので、複数回の操作でデータが増えるのは当然です.
新規操作をべき乗等性操作にするには、重複チェックが必要です.ページコミットにはtokenを付けることができますが、サービスインタフェースは?
おそらく唯一のデータ検証をするしかないでしょう......この検証はトランザクションと同時処理にかかわる可能性があります......
そこで面倒なので、まあ、異常を投げ出してサービス呼び出し者に「データ重複」を伝えましょう.
これがサービスなのか何かの鬼なのか.=
私が今回作ったインタフェースは、「べき乗などの新しいインタフェース」に向かって一歩前進し、対外的な意味を維持しています.あなたは私にデータをくれて、私は唯一の標識を返します.同じデータは、同じIDを返します.
自己感覚良好o(*￣▽￣*)ゞ
二つ目はデータベースフィールド設計
同僚とシステム内のデータベース設計について議論する際、データベースフィールド設計の選択構想について話しました.
データベースは、sqlのさまざまな利便性を得るために厳格に従っているのか、複雑な構造(配列、さらにはjson)を保存して柔軟性と拡張性を向上させるのか.
シーンのデザイン
システムは、エンティティA、エンティティB、およびB 1に関する構成を行う必要がある.次のようになります.
A:Bは1:nの構成関係
A:B 1は1:1の配置関係
BとB 1は同型のデータである
将来的には、次のようになります.
A:D構成
A:E構成
……
論争の焦点
主に以下の2つの案です.
パターンのシナリオに従って、テーブルフィールドは「ビジネスID」、「銀行チャネルid」の2つのフィールドとして設計され、各ビジネス-銀行チャネルの構成は1行保存されます.たとえば(例;他の関連テーブルまたはベース構成テーブルは書かれていません):
A
B
123
B1
123
B2
123
B3
456
B2
456
B4
複雑なデータ構造を格納するスキーマ.表フィールドの設計は2つのフィールドですが、各データの「銀行チャネルid」フィールド、格納配列(json文字列を格納するスキーマも議論されています).たとえば、次のようになります.
A
B
123
B1,B2,B3
456
B2,B3
789
{"C":"B1","B":B3","B5"}
両案の長所と短所
パターンに従うスキームはsqlを最大限にサポートすることができる.例えば、運営にどれだけのAが指定されたBを配置したかを統計する必要がある場合(これは私が別の類似の需要をしたときに実際に遭遇したもので、前車の鑑と言える)、この案は簡単に結果を得ることができる.
ただし、パターンに従うためには、データ量(行数、実際の記憶領域ではない)が大きくなります.最悪の場合、50 w「Aの数」*(19「Bの数」+1「Cの数」)=1千万行のデータが発生する可能性があります.このような大きなデータ量から20行のデータが検出され(しかも関連クエリも行われる)、クエリの効率が危ぶまれます.
また、ライブラリテーブルの設計を厳格に規定したデータ構造およびエンティティ間関係に従う.すなわち,このテーブルはAからB/Cへのマッピング構成のみをサポートする.後続の需要のDまたはEがこのような構造、関係で構成されていない場合は、新しいテーブル構造で拡張するしかありません.
複雑なデータ構造を格納するスキームの長所と短所は基本的に正反対である.sqlのサポートが悪く、データはコードで追加の処理が必要です.実際に消費されるストレージ容量はさらに大きくなる可能性がありますが、データ行数は大幅に減少し(jsonを使用すると最悪50 w行)、クエリー効率は向上します.また、データが長すぎない限り、jsonは様々なデータ構造を互換性があり、非常に柔軟で便利です.
我々の議論の結果
， 。私の理解はこうです.
1、前車の鑑があり、Bの構成データはsqlのwhere文条件として使用される可能性がある.複雑なデータ構造を使用する場合、この点はサポートしにくい.
2、データの行数の隠れた危険性は別の設計案と協力して解決することができる.
3、新しいデータ構造は新しいテーブルを拡張することによって実現できる.
これにより,複雑なデータ構造の優位性が縮小し,劣勢が拡大される.