開発者にはどのくらいのデータベースアクセスが必要ですか？[閉まっている]

そのため、私は開発者としてさまざまな職場で働いてきましたが、データベースへのアクセスレベルはさまざまです。通常、本番データベースへのアクセス権はありません。

ほとんどの場合、テストデータベースにアクセスできますが、さまざまです。データベースとデータを自由に変更できる場合もありますが、通常は他の方法もあります。私はデータへの読み取りアクセス権しか持っていないように。

私はDBAチームがデータベースを管理する1つの場所で働いていましたが、「検査」するSQLスクリプトを含むフォームを送信しない限り、まったく変更できませんでした。彼らは通常、プロジェクト自体とはあまり関係がなかったので、ほとんどの場合、F5を押すだけでした。

正直なところ、なぜprodをロックダウンする必要があるのか​​は理解できますが、開発環境とテスト環境でデータベースにできるだけ多くアクセスすることを好みます。ほとんどの開発者は、データベースをどのように使用するかを合理的に把握できていると思います。しかし、私は意見を聞きたいのですが？開発者にはどのくらいのデータベースアクセスが必要ですか？そこに何かを壊さないと信頼できるでしょうか？

開発者は、prodを含むすべてのデータベースへの読み取りアクセスが必要です。問題は、Prodのデータが期待したものではなく、devで再現できないため、問題の原因となっているデータを確認する必要がある場合があります。

開発者は、本番データの書き込み権限またはオブジェクトを作成する権限を持ってはいけません。公式リリースの一部ではない製品は何もすべきではありません。あまりにも多くの場合、人々は機能しない製品を簡単に修正して、製品をさらにマックアップしたり機能させたりしますが、コードを開発/ QA /ステージングサーバーに入れるのを忘れ、さらに悪いことにソースに入れます制御リポジトリとコードは、次の公式リリースで約1か月後に上書きされます。

別のサーバーにデプロイすると、開発プロセスにギャップがあるかどうかを確認するのに役立つため、開発者は完全なデータベースQA権限を持っていることをお勧めしますソース管理のスクリプトではなくGUIを使用します。これは、データベース構造の変更が必要な方法です）。

独自のサーバーセットを使用する新しいエンタープライズタイプのクライアントを使用している場合、公開する前にアクセス許可を緩和することができます。これは、非常に多くのことを行う必要があり、それをprodで実行できる少数の人々が未処理になり、場合によっては休暇を取る必要があるためです。特に、別のシステムからデータをインポートするユーザーは、データロードに時間がかかる場合、起動前にそれらをprodに配置するタスクを課される可能性があります。これらの人々はデータの専門家である傾向があり、平均的なアプリケーション開発者よりも一時的な製品へのアクセスを許可することで、より高い快適レベルがあります。これは、既に稼働している実稼働サーバーにアクセスするときの贅沢ではありません。

データベースへの本番権限を制限することに関して最も重要なことの1つは、開発者が自分の作業が他の誰かが展開できる形式であることを確認する必要があることです。これは、彼らが何かを忘れたため、またはメモリだけに依存している場合のprodとは異なる方法で何かを行ったためにその場で修正しようとしないため、作業の品質を改善する傾向があります。また、prodの展開が、devsの典型的なように一度に1つのコマンドではなく全体として実行されるスクリプトを純粋に使用している場合、「where句をハイライトするのを忘れたため、誤ってユーザーテーブル全体を削除した」製品で物事を実行します。prodデータベースに対する制限された権限を持つチームは、データベースの変更をソース管理にも保存する可能性が高くなります。

ジェフ・アトウッドがここに置いたように、それは本当に「吸血鬼（プログラマー）対狼男（システム管理者）」の問題です。

通常（つまり、完全な環境をセットアップする余裕があることを意味します）、開発者は以下にアクセスできます。

• 実動サーバー
  • なし（SA / PMはスキーマのセットアップに適用され、エンドユーザーは初期化データを提供します）
• UATサーバー
  • なし（SA / PMはスキーマのセットアップとサンプルデータのシードに適用されます）
• テスト/ QAサーバー
  • 通常、開発者はスキーマセットアップスクリプトをQAチームに送信し、QAがテーブルを作成します
  • 開発者はデータベースに完全にアクセスできますが、ほとんど変更しません
  • 開発者は、QAの同僚が一部のデータをシード/パッチ/削除するのを助けることができます
• 開発サーバー/ localhost
  • 全権アクセス

開発者が本番サーバーにアクセスしない理由の主な理由は、何か問題が発生した場合、運用チームが責任を負いますが、開発者は責任を負わないことです。

あなたが仕事を成し遂げるために必要な絶対的な最低限。

すべての開発者が完全なDBアクセスを許可されている場合、データベースからしか読み取れない場合よりも、怒り（または酔っぱらったり、非常に疲れたり）深刻な損害を被る可能性がはるかに高くなります。

DBの書き込みアクセスがなくても仕事がほとんどできる場合（そして、ほとんどの場合、週にせいぜい数回の変更要求を意味します）、書き込みアクセスは本当に必要ありません。

すべての作業環境には2つの競合する欲求があります。

• 自分で問題を解決できるように、人々にアクセスを提供したいという願望。これにより、高速でセルフサービスになります。
• 損傷、ダウンタイム、またはデータの損失（意図的またはその他）を防ぐために、アクセスを制限および制御したい。

打たれた（またはとにかく）バランスを形作るものの一部は、開発者に設定された期待です。開発者が自分自身を制限するために期待していたすべてのものにアクセスできるすべての仕事で私は持っていました。何をしているかを知っている場合にのみ、システムにアクセスしてください。つまり、開発者とシステム管理者の両方の観点から、自分が何をしているかを知っていました。どちらのエリアでもわからない場合は、システムにアクセスするビジネスがありませんでした。

わからない場合は、簡単に再構築可能なdev systems以外のシステムにアクセスするべきではありません。知っている場合は、簡単に再構築可能な開発システム以外のシステムにアクセスしないでください。

開発者は、devデータベースへのフルアクセスが必要です（理想的にはローカルサーバーを実行している必要がありますが、常に可能であるとは限りません）。ビルド/ QAデータベースへのアクセス権が必要ですが、データへのアクセス権のみが必要です（構造を変更するには、許可を取得/チケットを送信する必要があります）。開発者は本番データベースに気軽にアクセスすることはできません（小規模な企業/プロジェクトであり、開発者も本番サポートを行っている場合を除く）。

ここで重要なのは、開発者の責任レベルです。多くの開発者がいる大規模な組織では、QA / Testへの読み取り専用アクセス権を持つ開発へのアクセス権しか持たない可能性があります。

ただし、開発チームにはすべての環境への完全なアクセス権を持つ人がいるはずです。これは通常、修正などを行う責任があります。これはややリスクがありますが、開発者をどれだけ信頼するか、どれだけ早く修正を望むか、システムの混乱やシステム内の情報の開示に伴うリスクのトレードオフです。 。

私は大規模なITショップで働いていましたが、ほとんどの人が本番環境にアクセスできました。リード開発者としての私には、本番データベースへのアクセス許可もありました。プロセスと事務処理に関しては、システム管理者やDBAと同じガイドラインに従う必要がありましたが、必要に応じて緊急の修正を行うこともできました。

私たちのほとんどが忘れている関連する問題があります-データベースを使用しているのは私たちだけではないかもしれません！私たちはこれを当たり前だと思っているが、そうすべきではない。小規模なサイトでも、レポート用のデータベースに対してサードパーティのツールを実行しているビジネスマンがいる場合があります。エンタープライズサイトでは、ほとんどの場合、データベーステーブルの複数のユーザーが存在し、「小さな」変更によってアプリケーションが破損する可能性があります。

したがって、これが最初の質問でなければなりません。2番目は利用可能なスタッフである必要があります。私は、芝生を保護しているシステム管理者がいるサイトで働いていましたが、実際にはそれほど良くありませんでした。（おそらく、これが彼らがとても領土的だった理由です-誰かが周りを見回すと、彼らは多くの熱をキャッチすることを知っていました。）時々、あなたが望むよりも多くのアクセスが必要です。

しかし、理想的な世界では、他の人の指摘に同意します。率直に言って、私は責任を負いたくないので、ライブデータにアクセスしたくない。考えてみてください-操作上のアクセス権があり、侵害があった場合、それとは何の関係もないことを証明するのに多くの時間を費やす必要があります。個人的な理由などでデータを切り取っていないことを示す必要があるかもしれません。多くのサイトはプライバシーを非常に真剣に考えています。政府のサイト。

テストグループのシステムへの書き込み/管理者アクセスも必要ありません。実稼働システムで何かを実行できない場合は、テストシステムで実行できないようにします。読み取りアクセスは例外です。何が起こっているのかを把握するために必要だからです。

開発システムは、個人でも部門でも、異なる話です。ただし、実際には、ここでも、すべての人が自分で作業するのではなく、すべてのデータベースの変更をポイントパーソンを通じて実行することが最善です。

「prodデータベースの開発者にとって可能な限り最小限の特権」と言って、私はすべての答えに完全に同意します。しかし、正直なところ、開発者がデータベースを入手したい場合、開発者がデータベースへのアクセスを拒否できるのは誰ですか。十分な意志（犯罪者であろうと善良であろうと）で、必要なアクセスが得られます。

誰が簡単なSQLエディターをアプリケーションに配置することを阻止できますか このようにして、アプリケーションの権限でデータベースを使用できます。ほとんどの場合、これで十分です。データベースを安全に構成すると、オブジェクトを作成または削除する権限を持たない場合がありますが、少なくともデータへの読み取りおよび書き込みアクセス権があります。

私はすでにopsの人々が泣いています。しかし、正直に言って、自分で作成しない限り、実稼働環境にデプロイされたアプリケーションを完全に制御することはできません（それでも、ライブラリーについては考えないでください）。そして、すべての開発者にとって、Erinが既に述べたように、あなたは運用環境だけでなく、運用環境にも責任があります。そのため、特権を賢く使用してください。