- Java・エンジニア
- SES│在宅あり│契約社員◎
- 未経験大歓迎│Webエンジニア
- Other occupations (52)
-
Development
- Java・エンジニア
- 未経験大歓迎│Webエンジニア
- Webエンジニア
- 上流工程・システムエンジニア
- 未経験歓迎│資格支援
- 未経験も歓迎│Webエンジニア
- Java経験者│リモート有
- リモート有・Java経験者
- Java経験者
- リモートOK・Java
- SES│Java
- SES│在宅ワーク│Java
- 在宅ワーク│C# or VC+
- SES事業│テレワーク
- Webエンジニア│Java
- プログラマー・Java
- Webエンジニア・Java
- Webエンジニア・フルリモート
- JAVA・システムエンジニア
- エラー箇所の特定・修正
- Unisys経験者
- JAVA・TypeScript
- リモートOK・リーダー
- 在宅OK・Oracle EBS
- リモートOK・モバイル開発
- プログラマー
- アプリ開発エンジニア
- アプリエンジニア
- クラウドインフラ案件
- Java新規開発
- 開発経験3年以上│東京勤務
- データ移行
- Python案件
- システムエンジニア
- フルリモート
- プログラマー(Java)
- エンジニア・SE
- Systems Engineer
- Business
今回はデータベースの量について、設計視点とシステム保守視点から少し話したいです。
まず新規システム設計時、データベース各テーブルのData量(時系列に伴う量の変化を含む)の見積もりがされているのが前提です、見積もりない場合、ほぼ最適なSQL文の設計ができないで、システムリリース後、性能改善の作業が出るわけです、その時簡単に片付けるなら良いですが、大きな修正などが発生したら、提供サービス性能劣化、更なるサービス停止になる場合があります。
既存システム機能改修や追加の場合、現行データベースから各テーブルの件数を抽出して、実績件数として利用します、新規追加のテーブルについて、件数見積もりが新規ステム構築時と同様に必要です。
最後システム保守の段階で、開発環境と本番環境のData量を意識しながら、作業すれば無難です、証券系システムを例として、通常本番環境のData量が千万単位、億単位ですが、開発環境は通常百万単位以下で、本番で大量データ操作する場合、事前で開発環境で作ったSQL文でリハサル問題なくを実施したとしても、本番環境で同様なSQLで、結構遅くなるまたは全然動かない場合があります。環境差異を認識しながら、対策しましょう。