DBAはどのようにして「プログラマーフレンドリー」になることができますか？
質問の dba.seバージョン および programmers.seバージョン の回答とコメント "データベースレイヤーのアプリケーションロジック？」は、一部の作業環境におけるDBAとプログラマーの間の格差について非常に明らかにしています。
このような問題について、プログラマとよりうまく連携するために、DBAは何を変えることができるでしょうか？
我々がすべき：
- 特に適切に設計されたデータベースで作業する場合に直面する困難を理解するためにプログラマーが使用しているツールと言語を研究しますか？
- プログラマーに、データベースと、データベースレベルでビジネスロジックを使用する利点についての知識を深めるように勧めますか？
- データへのインターフェイスの定義方法を変更します-たとえば、よりプログラマーフレンドリーなトランザクションAPI（たとえば、下位互換性などの問題）を使用するなど。
プログラマーの観点から、私たちが最も望んでいるのは、データ層がどのように設計および構築されるかについての一貫性があり、明確に定義および実装された標準であると私は思います。私はあなたのサンドボックスであなたが望む方法でプレーしたいと思っています、あなたはあなたが何をしたいかを私に言うだけでよく、いつもルールを変えないでください。スーパープログラマーゴッドであっても、すべての人に同じように実装する必要があります。彼に例外を設ける場合は、サポートして変更してもらいたいが、私にとってうまくいかない正しい方法で再実装してほしい。
そして、そのようにしないで、離れて行くように私に言わないでください。私と協力して、あなたが何を望んでいるのか、なぜあなたのやり方が優れているのかを教えてください。私が理解すれば毎回従います。それがわからないときは、従うのが難しくなります。 DBAになりたくありません。私はプログラミングが好きなので、あなたの仕事は望んでいません。あなたが優れたDBAであれば、私はあなたの最大のファンになります。
私は過去6.5年間、MySQL DBAでした。私はまた、開発者として約16年間を費やしており、多くのDBAと対話しています。それらの多くは実用的です。それらのいくつかは不快です。 DBAになることの意味がわからない人もいます。
私はこの結論に達しました：
技術的には、次の1つ以上の資質を持つDBAが最適です。
- 開発者自身としての年月
- データベース理論を理解する
- RDBMSが内部でどのように機能するかを十分に理解している
- オペレーティングシステムに関する優れた知識がある
非常に訓練された知識豊富なDBAには、共有し、提供することがたくさんあります。開発者が実際に考慮していない視点からデータベースのパフォーマンスを確認する場合があります。開発者はデータベースから何が欲しいかを知っています。 DBAは、データベースに対して「礼儀正しい」方法を知っています。
パーソナリティに関する限り、常に葛藤や悲しみがあり、多分羨ましいことさえあります。確かなことは1つです。順不同で、DBAと開発者は夫と妻のようです（私は16年間、進行中のプロジェクト[4人の子供]と幸せに結婚してきました）。
誰が夫と見なされ、誰が妻と見なされるかに関係なく、次の原則が適用されます。
- 一方は他方に相談しなければなりません
- 一方は他方の視点を大切にする必要があります
- 双方の利益のために決定を下さなければならない
- 決断を下すのではなく、支持しなければならない
- 決定が悪い結果をもたらす場合、一方は他方を否定してはなりません
- 意思決定の成功に対する両当事者の貢献を喜ばなければならない
- 決定について相互に合意できない場合は、上位機関（HA）に相談する必要があります
これらの7つの原則は、職場、特にITの分野にも同じように適用されます。
すべてのステップを伝達することにより、全員が次のことを行う必要があります。
- 彼らの期待をレイアウトする
- 過去のパフォーマンスに基づいて相手の能力を発揮する能力を尊重する
- 相手が割り当てを完了することができるという信頼と自信を持っている
- 私たち自身の期待に応える
- acquiese HAの指導の下（原則＃7を参照）
これにはマイクロマネージメントの余地はありません。 DBASHOULD NOT TELL開発者はDBAのように考える方法。開発者SHOULD NOT TELLDBAが開発者になる方法。 データベースのパフォーマンスと使用法に関する最終決定は、DBAに委ねる必要があります。 アプリケーションのニーズに関する最終的な決定は、開発者に委ねる必要があります。この symbiosis は常に維持する必要があります。
最終的な考え
原則＃7には、より高い権限（HA）、つまりプロジェクトマネージャー、チームリーダー、リード開発者による積極的な参加と監視が必要です。 HAは、両当事者が個別にどのように機能するか、両当事者がどのように連携すべきかをよりよく理解しています。 HAが両方の当事者の基本ルールを確立しない場合、またはHAが当事者を個別かつ一緒に誘導できない場合、プロジェクトは常にある時点で停止し、開発者であるDBAの存在そのものを危険にさらします。またはHA。
チームを別のセクション/フロアに座らせることは、どういうわけか「私たち対彼ら」の考え方を奨励するようです。
開発チームの真ん中にDBAを置くことは、プログラマー/ DBAの壁を取り壊すための素晴らしい方法です。オープンマインドを保ち、エゴを脇に置いておけば、DBAもプログラマーもこの恩恵を受けます。
顔を合わせてコミュニケーションすること、特にアイデアを共有することは、メールよりもはるかに効果的であり、誤解により困難な感情を引き起こす可能性が低くなります。
この種のものは場所によって大きく異なります。私の現在のサイトでは、開発者とDBAの間の境界線は確かに非常に曖昧です-私たち（DBA）もPL/SQLを作成し、彼ら（開発者）はクエリプランを分析しています。私たちは皆、自分の仲間であり、スキルセットと責任が異なるだけです。これはとてもおもしろいです。最近会社は DevOps バンドワゴンに乗り込みました。データベースコミュニティはこれをまったく理解していません。私たちは常にそのように機能しました。言うまでもなく、次のように非常に生産的に作業しています。データベース層ははるかに会社のテクノロジースタックの最も信頼できる部分であり、操作が簡単です（ DBAチームはアプリケーションを深いレベルで理解する必要があり、開発者はDBAに24時間365日の操作とそのためのアプリの構造化方法を理解する必要があります。
しかし、「間違った」種類の開発者について話すとき、私はあなたが何を意味するのかを知っています。彼は独学で、それ自体は高貴なものですが、その過程で、彼はあらゆる種類の正式な指示に対する不信感を抱きました。彼は 彼が知らないことを知らない であり、彼は彼を啓蒙しようとする者を憤慨させ、彼はそれを彼の自己学習スキルへの侮辱と見なします。彼はプログラミングの命令的なスタイルを学びました。なぜなら、CSの型は常に（まあ、ひどく;全員が知っておく必要があるという理論的なことは何もせずにそれを学ぶことができるからです big-O と同様の理論の一部）。彼はJavaを使用しなければならないという理由だけでOOも少し学びました。しかし、優れたデータベースの専門家（開発者またはDBA）は、宣言理論で快適に考え、集合論について考える必要があります。 、通常の形で、関係代数や微積分を理解することさえできます。これらの人々とコミュニケーションを取るのは非常に困難です。ウェブページで何かをフォーマットする方法です。もしデータベースについて考えるなら、テーブルはクラスのようなもので、行はオブジェクトのようなものだと思います。これらの人たちは文字通りSELECT * FROM TABLEをフィルタリングして、結果を独自のコードでソートします。彼らは、データベースがフラットファイルよりも優れている理由を本当に理解していません（そして、リレーショナルデータベースを使用する人は誰でも馬鹿とは考えていません）。
実際の例を挙げましょう。最近、QAを超えて問題が発生した場合に、ソフトウェアのリリースが本番稼働になってからロールバックすることに関する問題について、これらのタイプの1つと話していました。私は彼のアプリケーション（データベースにアクセスする多くのアプリケーションの1つ）をロールバックする可能性がある一方で、データベースがまだデプロイされている状態で操作できる必要があることを説明しました。彼は理由を尋ねました、そして私が言ったように、これらの新しいテーブルと列には、実際の顧客データがあるでしょう。それから彼は言ったので、それを一時テーブルにコピーするだけで、何が問題なのか。私は信じられないほど彼をじっと見つめていました：顧客が電話して言ったとき、私のお金が私の口座から消えました、私たちは彼に何がいいのですか、それは一時的なテーブルにありますか？あなたが他の人のお金を扱っているとき、あなたは責任ある大人のように振る舞わなければならないということを彼は単に受け取らなかった。私が知っているのは、彼がまだそうしていないことです。彼はもう私たちと一緒ではありません。
MySQLキャンプは長い間このような状態でした。トランザクションや外部キーなどは必要ない、と考えたのは、自分が何をしているのかなどわからなかったからだと思った場合などです（その後、成長すると、静かに追加されました）。これらは、ActiveRecordやHibernateのようなORMが開発された人々の種類なので、SQLに触れる必要なくデータベースアプリケーションを作成できます。これらのテクノロジーを使用することは、危険信号と見なされます。これは、DBAスキルを重視する会社ではありません。彼らが本当に望んでいるのはベビーシッターです...
プログラマーとしてデータベースを理解することで、私はより優れたプログラマーになりました。私がデータベース管理者になったとき、これはさらに重要になったので、教育が鍵となると思います。
DBAは、有能な専門家として扱う開発者を辛抱強く指導する必要があります。クライアント側でのセット操作と行ごとの操作の違いを示すプログラマーはほとんどいません。アプリケーションの速度、データのセキュリティ、保守性など、同じ目標のいくつかを共有しています。これは、アプリケーションロジックの問題だけでなく、データベースの相互作用のすべての側面にも当てはまります。プログラマーは自分のツールをもっと使いたいと思っており、DBAがデータベースツールの使い方をもっと上手に示すことができれば、両方のメリットが大きくなります。
どのようなインフラストラクチャをサポートする場合でも、そのインフラストラクチャのユーザーをサポートする必要があります。多くのユーザーは開発者であるため、開発者がインフラストラクチャを最大限に活用できるようにサポートします。これを行うには、さまざまなアイデアや観点を考慮して、お互いを理解する必要があります。双方からの見方を理解することは、ビジネスをより良いものにするのに役立ち、それが私たちの複合的な目標です。 ITがビジネスをできるだけ効果的にサポートできるようにします。
多くの組織では、神モードで実行されているdbaタイプがいくつかあります。ほとんどの場合、コンピテンシーが測定された場合、これらは非常に良いスコアを獲得するものではありません.....多くの場合、彼らは言葉の壁の背後に自分の-不足-知識を隠すだけです。
私の意見では、それは「プログラマーフレンドリー」であることとプロであることとは何の関係もありません。 dbaの場合は、可用性、スケーラビリティ、回復可能性、パフォーマンスなどの通常の目標を失うことなく、私たちが行うことを行う理由を説明し、それが役立つ場合は、少なくとも再検討の決定に備えることができる必要があることを意味します。プログラマにとって、それは彼がdbaと通信しなければならないことを意味します。これに関する私のモットーは、私が学ばない最初の日を棺が私の頭の上で閉まる日とすることです。チームと開発者およびdbaを組み合わせた通常のコラボレーションは、物事をより簡単にするのに役立ちます。
問題の一部は視点です。 DBA、データアナリスト、およびデータベース開発者は、時間をかけてデータを処理する必要があります。アプリケーション開発者は、本番環境に送信するときに物事を機能させる方法に関心があります。展開時にエラーが発生しない限り、データが6か月後にどのように表示されるかについてそれほど心配する必要はありません。
しかし、データの人々は、データの整合性が失われたり、重複したレコードが挿入されたりする原因となる、近視眼的な決定の結果に耐えなければならず、次に、データが悪い理由を説明しようとします。 DBAは、レコードが1,000しかなかったときに問題なく動作したプロセスからのパフォーマンスの問題に対処する必要があるが、現在は100,000,000のレコードで数時間かかる。
データベースはリファクタリングが難しいため、DBAは最初に正しくリファクタリングすることに関心を持っています。開発者は、今後のリファクタリングに問題はないと考えています。
データベースをオブジェクト指向であるかのように機能させることで、開発者は問題がないことを理解しています。データベースの人々は、データを保存または取得するための最も効果的または効率的な方法ではないことを知っています。
多くの場合、アプリケーション開発者はレコードの小さなサブセットのみを扱い、大きなデータのインポート/エクスポートやレポートは扱いません。 1つのレコードを入力するために正常に機能するものは、100万のインポートについて話しているときは機能しません。アプリケーションのビジネスロジック（レポートアプリケーションからアクセスできないことが多い）は、画面に一度に1レコードずつ表示されるのと同じように、レポート作成者が100万レコードに対して同じ結果を得るのに役立ちません。
問題のもう一つの部分は両側の軽視です。データの作業は難しくないし、面白くなく、自分の世界でハッキングできない場合にのみこの作業を行うと信じているアプリケーション開発者の何人かと会ったことがあります。人々は、あたかも愚かで役に立たないかのように扱われることにうまく反応しない傾向があります。一方、一部のDBAは、アプリケーション開発者を軽視する傾向があり、開発者がデータベースに対して行っていることを確認するというタスクを低い優先度として扱いがちです（大規模で複雑な運用データベースがある場合、そうなる可能性があります）。彼らは聞くことを拒否するか、応答することができます。 DBAが2週間後にレビューするまで、プロジェクト全体を保留にしたいのは誰ですか。そして彼はそれは受け入れられないとあなたはすべてを書き直す必要があると言いますか？
開発者としてあなたに必要なのは、あなたが私に必要なことをどのように伝えてほしいかを知ることだけです。私がとんでもないことを求めているなら、私にあなたに教えてもらう必要があります。あなたがそう言ったなら、あなたは誠実さの実績があるのでそれを信じます。私が何を求めているのか理解できない場合は、時間をかけて私が何を言っているのかを説明してください。
...共通のテーマ、右...コミュニケーション...コミュニケーション...コミュニケーション。
それを置くための本当に良い方法はありません。 「DBAがそれは不可能だと私に言った-私は確かに前回彼が間違っていることを証明した」ので、開発者は怒られます。 「その開発者は、仕様を変更するたびに私が何をしなければならないのかを理解していない」ため、DBAは感動します。
@Rolandoが述べたように、開発者とDBAはお互いを理解する必要があります。すべてがそれに帰着するとき、私たちは両方とも「Ones＆Zeros」を話します-あなたはそれが良い試合だと思うでしょう。私たちには2つの責任の領域があります。DBAにはデータがあり、開発者は残りのコンピューターを取得します。しかし、データがなければ、プログラマーは実際に行うことはほとんどありません。
私たちにはDBAがいません。 10年前にDBAになりたいと思っていた私は、私たちがしていることのいくつかを見るとうんざりします。もし明日DBAを雇ったら、彼/彼女が歩いたまさにその地面にキスをすると思います。
SQL Server（1998）を使い始めてから何年もの間、多くの開発者に自分の仕事のやり方を教えてもらいました。彼らがall私よりも知っているsuperb .net開発者であることは興味深いことです。実際、それらもarchitectsであり、コードモンキーよりも大きなことをしているはずです。
多分それは私からの間違った態度です：しかし、それは多くの店でかなり一般的な開発者の態度です。彼らはお互いにそれを行います、あなたがピアレビューを提案するときに戦いが始まるのを見てください。
修正は他の回答に任せます（これまでの2つで100％同意します）が、管理とショップカルチャー必須サポートとコラボレーションの育成も追加します。
一部の企業、おそらく多くの企業では、製品開発はコンパイルされた言語で記述していない人を無視する傾向があります。リリースの時期に来てください。ネットワーク管理者、DBA、システム管理者、ユーザーサポートなどが、それぞれ完了するためのデューデリジェンスを持っているため、抵抗があります。環境の重要な側面が考慮されていなかったため、しばしば頭痛の種があります。これは当然チーム間の緊張を引き起こします。
ここで誰が責任を負うのですか？ミスター・コミュニケーション。
開発者は、展開される環境コードを理解する必要があります。人々は、適応するために公正な警告を与えられる必要があります。環境が何らかの理由（セキュリティ、機器、ポリシー）に適応できない場合、ソフトウェアは適応する必要があります。これが設計および実装プロセス中に発生した場合、誰もが満足しています。展開時まで始まらない場合、それは傷ついた世界です。
はい、チームは互いに話し合う（そして聞く）必要がありますが、プロジェクト/製品マネージャーは、このような環境を作り出す必要があります。
私は幸運でした、私が働いたほとんどの場所で、相互の尊敬とコミュニケーションは文化の一部でした。
優れたDBAが理解する必要があることの1つは、データのポリシーです。私は、経験豊富なプログラマーとドラフト作成のDBAにデータベースプログラミングと設計を数年間教えました。定期的に出てくる質問の1つは次のとおりです。私の店にあるすべてのデータベースがどうしてそれほど政治的なのでしょうか。
これが私の標準的な答えでした。データベースが有用であれば、データを共有しています。データを共有している場合は、パワーを共有しています。権力が分かち合うと、政治が起こります。
政治が好きか嫌いかは関係ありません。良いデータベースの仕事をするつもりなら、それに慣れなさい。
ちなみに、開発環境でしか仕事をしていない方もいます。フェンスの本番側で作業し、開発者とのやり取りがほとんどないDBAがいます。本番環境では政治が少ないと思うかもしれません。もっとあります。大きな本番データベースは、企業全体でミッションクリティカルになる傾向があります。
少し謙虚さがあなたの一部のために役立つかもしれません。 ;）
どちらのアプローチにも明らかに有効な議論があります。まずはそれを認識することから始めることをお勧めします。ソフトウェア開発は、すべて適切なトレードオフを行うことです。双方向の場合は、おそらくDBAも心を開いておく必要があります。