「データベースレイヤーにアプリケーションロジックを配置することに対する、またはそれに対する引数は何ですか？」という質問のdba.seバージョンとProgrammers.seバージョンに関する回答とコメント 一部の職場のDBAとプログラマーの格差について非常に明らかにしています。
このような問題に関してプログラマーとより良く働くために、DBAはどのように異なってできるでしょうか？
我々がすべき：
回答:
プログラマーの観点から、私たちが最も望むのは、データ層がどのように設計され構築されるかについて、一貫性があり、明確に定義され、実装された標準です。私はあなたがあなたのサンドボックスであなたが望む方法でプレーしたいと思っています、あなたはあなたが望むものを私に言うだけで、常にルールを変更する必要はありません。それはすべての人、スーパープログラマーの神に対しても同じように実装されるべきです。あなたが彼のために例外を作るなら、あなたは私にそれをサポートし、変えて欲しいが、私にとってはうまくいかない正しい方法でそれを再実装して欲しい。
そして、そのようにしないで、立ち去らないように言ってはいけません。私と協力して、あなたが望むもの、そしてあなたのやり方がより良い理由を教えてください。理解できれば、毎回遵守します。理解できなければ、それを遵守するのは難しくなります。DBAになりたくありません。私はあなたの仕事を望まないプログラミングが大好きです。あなたが良いDBAであるなら、私はあなたの最大のファンになります。
私は過去6。5年間MySQL DBAを務めてきました。また、開発者として約16年を費やし、多くのDBAと交流しました。それらの多くは実用的です。それらのいくつかは不快です。DBAであることの意味がわからない人もいます。
私はこの結論に達しました：
技術的に言えば、次の1つ以上の資質を備えたDBAが最適です。
非常に規律があり、知識のあるDBAは、共有して提供することがたくさんあります。開発者が実際に考慮していない観点からデータベースのパフォーマンスを見ることがあります。開発者は、データベースに必要なものを知っています。DBAは、データベースに対して「丁寧」になる方法を知っています。
パーソナリティに関する限り、常に対立、不満、そしてmaybe望さえあります。確かなことは1つあります。順不同で、DBAと開発者は夫や妻のようです（私は16年間、進行中のプロジェクト[4人の子供]と幸せに結婚しています）。
誰が夫と見なされ、誰が妻と見なされるかに関係なく、これらの原則が適用されます。
これらの7つの原則は、職場、特にIT分野でも同様に適用されます。
道のすべてのステップを通信することにより、すべてがする必要があります：
これにはミクロ管理の余地はありません。DBAは、開発者にDBAのような考え方を伝えるべきではありません。開発者は、DBAに開発者になる方法を教えてはなりません。データベースのパフォーマンスと使用に関する最終決定は、DBAに委ねる必要があります。アプリケーションのニーズに関する最終決定は、開発者に委ねる必要があります。この共生は常に維持されなければなりません。
原則7では、プロジェクト管理者、チームリーダー、主任開発者である高等当局（HA）による積極的な参加と監督が必要です。HAは、両当事者が個別にどのように機能するか、および両当事者がどのように連携するかをよりよく理解しています。HAが両当事者の基本ルールを確立していない場合、またはHAが当事者を個別にまとめて誘導しない場合、プロジェクトは常にある時点で停止し、開発者、DBA、または、HA。
この種のことは場所によって大きく異なります。私の現在のサイトでは、開発者とDBAの境界線は非常に曖昧です-私たち（DBA）もPL / SQLを書いており、彼ら（開発者）はクエリプランを分析しています。私たちは皆、自分自身を仲間と見なし、単に異なるスキルセットと責任を持つだけです。これは非常に面白いことです。最近、同社はDevOpsの時流に乗っています。データベースコミュニティはこれをまったく理解していません。私たちは常にそのように働いてきました。言うまでもなく、このように非常に生産的に作業しています。データベース層は圧倒的に同社の技術スタックの中で最も信頼性の高い部分であり、操作が簡単です（DBAチームにはアプリケーションを深いレベルで理解するスキルがあり、開発者は24/7/365の運用とその方法を理解するためにDBAにさらされているためそのためにアプリを構築します）。
しかし、「間違った」種類の開発者について話すとき、あなたが何を意味するか知っています。彼は独学であり、それ自体は高貴なものですが、途中で何らかの形式的な指示に不信感を抱いています。彼は彼が知らないことを知らず、彼を啓発しようとする人をresし、彼はそれを彼の自己学習スキルに対するin辱と見なします。彼は、プログラミングの命令型スタイルを学びました。なぜなら、CS型が常に口論するような理論的なものなしでそれを学ぶことができるからです（まあ、ひどく、誰もがビッグOを知る必要があります）および理論の同様のビット）。彼はJavaを使用しなければならないという理由だけで、OOも少し学びました。しかし、優れたデータベースプロフェッショナル（開発者またはDBA）は、宣言型のスタイルで快適に思考し、集合論、標準形式、さらには関係代数や計算を理解できることを考える必要があります。これらの人々とコミュニケーションをとることは非常に困難です。なぜなら、彼らは彼らの快適ゾーンから逃げる可能性のあるものに積極的に敵対しているからです。データベースについてまったく考えている場合、テーブルはクラスのようであり、行はオブジェクトのようなものだと考えます。これらの人は文字通り、自分のコードでSELECT * FROM TABLE結果をフィルタリングしてソートするだけです。彼らは本当に、データベースがフラットファイルよりも優れている理由を本当に理解していません（リレーショナルデータベースを使用する人は誰でもバカだとは思わない）。
実例を挙げましょう。最近、問題がQAをすり抜けた場合に、本番環境に移行した後にソフトウェアのリリースをロールバックすることに関連する問題について、これらのタイプの1つと話していました。彼のアプリケーション（データベースにアクセスする多くのアプリケーションの1つ）をロールバックすることはできますが、まだ展開されているデータベースを操作できる必要があると説明しました。彼はその理由を尋ねました。そして、私は、これらの新しいテーブルと列には、実際の顧客データがあると言いました。それから彼は言ったので、それを一時テーブルにコピーするだけです、問題は何ですか。私は信じられない思いで彼を見つめました。顧客が電話をして言ったとき、私の口座から私のお金がなくなったとき、私たちは彼に何を伝えますか？彼はあなたが他の人のお金を扱っているとき、責任ある大人のように振る舞わなければならないことを単に得ませんでした。私が知っているすべてのために、彼はまだそうしていません。彼はもう一緒ではない。
MySQLキャンプは長い間このようでした。トランザクションや外部キーなどを必要としなかったと言うのは、自分が何をしているのかわからないなどの理由だけであると考えた場合です（その後、彼らは成長したときに静かに追加しました）。これらはActiveRecordやHibernateのようなORMが開発された種類の人々であるため、SQLに触れることなくデータベースアプリケーションを作成できます。これらのテクノロジーの使用は危険だと考えています-これはDBAスキルを重視する会社ではありません。彼らが本当に欲しいのはベビーシッターです...
データベースを理解しているプログラマーとして、私はより良いプログラマーになりました。私がデータベース管理者になったとき、これはさらに重要になりました。したがって、教育が重要だと思います。
DBAは、有能な専門家として扱う開発者を辛抱強くガイドする必要があります。クライアント側でセット操作と行ごとの操作の違いを示したプログラマーはほとんどいません。アプリケーションの速度、データセキュリティ、保守性など、同じ目標の一部を共有します。これは、アプリケーションロジックの質問だけでなく、データベースインタラクションのすべての側面にも当てはまります。プログラマーは自分のツールをより良く使いたいと思っており、DBAがデータベースツールの使い方をより良く示すことができれば、両方のメリットが得られます。
どのインフラストラクチャをサポートする場合でも、そのユーザーをサポートする必要があります。多くのユーザーは開発者であるため、開発者がインフラストラクチャを最大限に活用できるように開発者をサポートしています。これを行うには、さまざまなアイデアや視点を念頭に置いて、お互いを理解する必要があります。双方からの見解を洞察することは、ビジネスにとって物事をより良くするのに役立ち、それが私たちの結合された目標です。ITができるだけ効果的にビジネスをサポートできるようにします。
多くの組織では、いくつかのdbaタイプがgodモードで実行されています。ほとんどの場合、これらはコンピテンシーが測定された場合に非常によく得点するものではありません。
私の意見では、プロであることと「プログラマーに優しい」こととは関係ありません。dbaの場合、アベイラビリティ、スケーラビリティ、リカバリ可能性、パフォーマンスなどの通常の目標を失うことなく、なぜそれを行うのかを説明し、それが役立つ場合は少なくともリースの決定を再検討する準備を整える必要があることを意味します。プログラマーにとっては、dbaと通信する必要があり、dbaを教えることもあれば、dbaから学ぶこともあります。これに関する私のモットーは、私が何かを学ばない最初の日がletが私の頭の上で閉じる日であるとしましょう。チームと開発者およびdbaを組み合わせた通常のコラボレーションは、確かに物事を容易にするのに役立ちます。
問題の一部は展望だと思います。DBA、データアナリスト、データベース開発者は、長期にわたってデータを処理する必要があります。アプリケーション開発者は、実稼働環境に送信するときに物事を機能させる方法に関心があります。展開時にエラーがなければ、6か月以内にデータがどのように表示されるかについてあまり心配しません。
しかし、データの人々は、データの整合性が失われたり、重複レコードが挿入されたりして、データが不良である理由を説明しようとする近視眼的な決定の結果に耐えなければなりません。DBAは、レコードが1,000件しかなかったときに正常に機能していたプロセスのパフォーマンスの問題に対処しなければならない人ですが、現在は100,000,000レコードで何時間もかかります。
データベースはリファクタリングするのが難しいため、DBAは初めてデータベースを正しくリファクタリングすることに関心があります。開発者は、今後のリファクタリングに問題がないことを確認しています。
開発者は、データベースをオブジェクト指向であるかのように動作させることに問題はないと考えており、データベースの人々は、データを保存または取得する最も効果的または効率的な方法ではないことを知っています。
アプリケーション開発者は、多くの場合、レコードの小さなサブセットのみを処理し、大きなデータのインポート/エクスポートまたはレポートは処理しません。1つのレコードを入力するのに正常に機能するものは、100万をインポートすることについて話しているときには機能しません。アプリケーションのビジネスロジック（レポートアプリケーションがアクセスできないことが多い）は、レポート作成者が一度に1レコードずつ画面に表示されるものと同じ結果を100万レコード取得するのに役立ちません。
問題の別の部分は、両側の無礼です。私は、データの仕事は難しくも面白くないと考え、自分の世界でハッキングできない場合にのみこの仕事をすると信じている少数のアプリケーション開発者に会いました。人々は、あたかも愚かで役に立たないかのように扱われることによく反応しない傾向があります。一方、DBAの中には、アプリケーション開発者を軽視する傾向があり、開発者がデータベースに対して行っていることをレビューするタスクの優先度を低くする傾向があります（大規模で複雑な本番データベースがある場合）。彼らは聞くことを拒否するか、反応することができます。DBAが2週間後にレビューするまで、プロジェクト全体を保留にしたい人はいますか？そして、彼はそれが受け入れられないとあなたに言った、あなたは全部を書き直さなければならない？
SQL Server（1998）を使い始めてから何年もの間、多くの開発者に仕事のやり方を教えてもらいました。彼らが皆、私よりも優れた .net開発者であることを知っているのは興味深いことです。実際、彼らもアーキテクトであり、コードモンキーよりも大きなことをすべきです。
おそらく、それは私からの間違った態度です：しかし、それは多くの店で非常に一般的な開発者の態度です。彼らもお互いにそれをします、覚えておいてください：あなたがピアレビューを提案するとき、戦いが始まるのを見てください。
修正は他の回答に任せます（これまでの2つに100％同意します）が、管理とショップカルチャーもコラボレーションをサポートおよび育成する必要があることを付け加えます。
開発者として、あなたに必要なのは、あなたが私に必要なものをどのように伝えたいかを知ることだけです。馬鹿げた何かを求めているなら、私にあなたが私に言う必要があります-そしてあなたがそう言うなら、あなたは誠実さの実績があるのでそれを信じます。私が何を求めているのか分からない場合は、時間をかけてあなたが私が何を意味していると思うかを説明してください-そして私は時間をかけて耳を傾けます。
...共通のテーマ、右...コミュニケーション...コミュニケーション...コミュニケーション。
本当に良い方法はありません。開発者は、「DBAはそれができなかったと言った-前回彼が間違っていることを証明した」と言ったので、チェックされます。「その開発者は、仕様を変更するたびに私がしなければならないことを理解していない」という理由で、DBAは気になります。
開発者とDBAは、@ Rolandoが述べたように、お互いを理解する必要があります。結局のところ、私たちは両方とも「Ones＆Zeros」を話します-あなたはそれが良い試合になると思います。私たちには2つの責任の領域があります。DBAにはデータがあり、開発者は残りのコンピュータを取得します。しかし、データがなければ、プログラマーは本当に多くのことをする必要はありません。
私たちにはDBAがいませんし、時には痛いこともあります。10年前にDBAになりたかった私の作品は、私たちがやっていることのいくつかを見ると縮みます。明日DBAを雇ったら、彼/彼女が歩いた地面にキスをするだろうと思います。
おそらく多くの企業では、製品開発はコンパイルされた言語で書かない人を無視する傾向があります。リリース時期が来ると、ネットワーク管理者、DBA、システム管理者、ユーザーサポートなどがそれぞれ完了すべきデューデリジェンスを持っているため、抵抗があります。環境の重要な側面が考慮されなかったため、多くの場合頭痛がします。これは当然、チーム間の緊張を引き起こします。
ここで誰のせいですか？コミュニケーションさん。
開発者は、環境コードがデプロイされる環境を理解する必要があります。適応するには、公正な警告を与える必要があります。環境が何らかの理由（セキュリティ、機器、ポリシー）に適応できない場合、ソフトウェアは適応する必要があります。これが設計および実装プロセス中に発生した場合、誰もが満足しています。展開時まで起動しない場合、それは痛い世界です。
はい、チームはお互いに話し合う（そして聞く）必要がありますが、プロジェクト/プロダクトマネージャーはこれが起こる可能性のある環境を作る必要があります。
幸運なことに、私が働いたほとんどの場所で、相互尊重とコミュニケーションは文化の一部でした。
優れたDBAが理解しなければならないことの1つは、データの政治です。私は、経験豊富なプログラマーと数人のドラフトDBAに数年間データベースのプログラミングと設計を教えました。定期的に出てくる質問の1つは、どうして私の店に戻ってきたデータベースがすべて政治的であるのかということでした。
私の標準的な答えは次のとおりです。データベースが有用であれば、データを共有しています。データを共有している場合、パワーを共有しています。権力が共有されると、政治が起こります。
政治を愛するか、政治を憎むかは関係ありません。優れたデータベース作業を行う場合は、それに慣れてください。
ちなみに、一部の人は開発環境でしか働いていません。フェンスの運用側で作業し、開発者とのやり取りがほとんどないDBAがいます。生産の方が政治が少ないと思うかもしれません。他にもあります。大規模な本番データベースは、企業規模でミッションクリティカルになる傾向があります。