ソフトウェアチームとデータベースチーム間の調整の問題
これはほとんど「ソフトウェアプロセス」の質問です。
組織がソフトウェアチームとデータベースエンジニアリングチームの2つのチームに分かれている場合（組織はETL/BI /データマイニングに参加しており、研究組織向けにテラバイトサイズのレポートとデータベースダンプを提供しています）、
そのような2つのチーム間の調整で最も一般的な問題は何ですか？そして、どのようにそれらを回避しますか？ DBAは、ソフトウェアエンジニアと比較して、設計を決定する上で正確にどの程度の権限を持っていますか？
データベーススペシャリストを分離するのではなく、チームの一員にします。データベース開発者/開発DBAは、すべてのプロジェクトにフルタイムで参加する必要はありませんが、絶対にチームの一員であり、毎日のスタンドアップやレビューなどに参加し、チームの他のメンバーと共同で成果物を所有する必要があります。
データベース開発ガイドラインを事前に作成し、その目的と適用方法を全員が知っていることを確認します。
現実的なサイズのデータを使用したテストは、後のテストだけでなく、すべての反復とすべてのテストサイクルの一部であることを確認してください。このステップだけで、開発者とDBAの間で発生する可能性のある問題と緊張のほとんどに対処する必要があります。
アジャイルで反復的なデータベース開発アプローチを採用します。つまり、進化的なデータベース設計、継続的インテグレーション、高度なデータベース正規化、およびビジネスルールへの厳密なアプローチ（キーやその他の整合性制約を早期に適用し、必要に応じて後で削除する）を意味します。
これには正しい答えも間違った答えもないと思います。しかし、私は過去にも同様の状況にあり、プロジェクトのニーズに基づく合理的な決定ではなく、政治や組織の歴史によって誰がどの役割を担うかが決まることがよくありました。
たとえば、あるチームでは、すべてのデータベーステーブルがdbaによって承認される必要がありました。これにより、チームの速度が大幅に低下し、DBAが不機嫌になり、過労になりました。このプロセスが開始された理由を尋ねたところ、誰も覚えていなかったので、それを取り除きました。
あなたの場合、データベースのパフォーマンスがあなたの成功の重要な部分だと思います。私が見た中で最高のモデルは、学際的なチームに特定の機能に取り組んでもらうことです。チーム内で、誰がリードしているかを判断します。正式な部門の境界間よりも、すべての専門分野が（パートタイムであっても）代表されるチームで作業する方がはるかに簡単です。
私たちの場合、DBAは設計を指示しません。ただし、データベースの作成、データベースの展開、スクリプトまたはSSISジョブまたはSSRSレポートの展開中に、開発チームが従うべき一連のガイドライン（すべきこと/すべきでないこと）があります。
DBAの役割の性質はプロジェクト間で共有されており、ほとんどの場合、リクエストで過負荷になっています。これが最も一般的な問題です。解決策は、十分なリードタイムとフォローアップです。いくらで十分ですか？ -DBAに相談して、知ってください。
開発者チームにはDBAのようなスキルを持つ人が必要ですが、DBAが行うことのほとんどは開発プロジェクトでは役に立たないため、DBAは必要ありません。
通常の問題は、データベースが展開前に「調整」のためにDBAに渡されることですが、それでは遅すぎます。問題は、DBAが、テーブルが何に使用されるのか、テーブルがどのように照会されるのか、誰がデータベースを使用するのか、いつ使用するのかについての手がかりを持っていないことです。彼らが改善すべき何かを見つけたとき、それはしばしば再設計を必要とすることがわかります。非常に費用がかかります。
他の観点からの問題は、開発に積極的に関与していないDBAは、分析または開発中に対処する必要のある問題のほとんどを理解しておらず、「適切な分析では発生してはならない」としてほとんどの問題を却下することです。 。これはある意味では真実ですが、単純すぎて役に立たないのです。
異なる機能間で人を交代させることは、知識を伝達し、両方のチームの作業方法を強化するための優れた方法です。プロジェクトの知識をDBAチームに追加し、DBAスキルを開発チームに追加します。
私はこの記事に書かれていることの多くに同意しますが、知識の伝達が不足しているため、一人のチームは最適ではないと思います。しかし、私は彼らが説明するような人々との人員配置チームに同意します。
スパナ：次世代BI開発者
データベースチームと開発チームはどちらも異なる視点を持っています。どちらも重要であり、調整する必要があります。データベースチームの誰かを開発チームの一部として迎えることは良い考えです。彼らは、標準と、このプロジェクトの既存の企業データを活用する能力を持ってプロジェクトに参加する必要があります。
開発チームの視点は、プロジェクトのニーズに焦点を合わせます。プロジェクト内のデータのライフサイクルは、通常、数時間または数日で測定されます。その後、多くのテーブルのデータが履歴アーティファクトになります。
データベースチームの観点からは、データは企業資産の一部になります。データは何年も利用できるようにしておく必要があるかもしれません。このデータを維持し、最終的には廃棄する必要があるのはデータベースチームです。データベースチームは、データに適用される規制順守の問題に精通している必要があります。
検討中の問題は、ソフトウェアチームとデータベースチームのどちらを優先するかを決定する必要があります。コンセンサスを目指すことが最良の選択肢です。 2つのチームは、相手の懸念に率直に耳を傾ける準備をする必要があります。データベースチームを設計に積極的に関与させることを奨励する必要があります。壁を越えて問題を投げないようにしてください。