php - テーブル構造が変更された場合にプログラムが正常に実行できなくなるのはどのようなアーキテクチャですか?

Question

今日、フロントエンド担当者から、バックエンドがテーブル構造を変更すると (テーブルの削除やフィールドの変更など)、プログラムは実行されなくなると教えられました。上記の問題の発生を防ぎます。プログラムは正常に実行できますか? 各テーブルのフィールド マッピングを行う必要がありますか? それとも他のブラック テクノロジですか?

ちなみに、ここで起こった話は、私が設計したライブラリのメインテーブルを別の人が削除し、判定が必要ないくつかのフィールドの意味が変更されたというものです。その結果、フロントエンドから「コードが堅牢ではない」「何かが欠けても影響がない（Android）」と嘲笑され、非常に言葉を失いました。彼にそれを説明する方法を知っています。ところで、私は機能的デカップリングに対するダラオのアプローチについて知りたかったのです。どの程度が必要か

Answer 1

あなたの考えには非常に問題があるように感じます。
データテーブルの変更は、データやデータ構造自体の変更に相当し、この場合、元のコードの論理合理性に影響を及ぼすことは間違いなく、元のコードを修正する必要があります。 。テーブルの削除やフィールドの変更は言うまでもなく、それらのデータがロジック自体に大きな影響を与えない単なるデータ ディクショナリでない限り、プログラムにバグがあるのは普通のことです。
そして、フロントエンドは一体何を教育しているのでしょうか。フロントエンドとバックエンドは、データのやり取りを適切に行う必要があるだけであり、フロントエンドはデータを表示する責任を負います。テーブル構造の変更は、データとは何の関係もありません。フロントエンド。データ インターフェイスとインターフェイスによって提供されるデータが正常である限り、フロントエンドはバックエンドで何が起こったかを知りません。

Answer 2

データベース設計では、データベース パラダイムと 3 つのモードが考慮されます。
しかし、私が知っているアーキテクチャでは、データベースとプログラムの間の結合を完全に切り離すことは、アーキテクチャによってのみ軽減できます。この問題を解決する効果的な方法は、データベースを設計するときです。可能な限り要件を理解し、さらに考えてテーブルの変更を減らし、コードを標準化し、いくつかの設計パターンを採用してスケーラビリティを高めます。

Answer 3

データベースは削除されましたが、まだ正常に実行されると期待していますか?
データベースPDOで例外が発生した場合、インターフェースは直接ステータス=500などを返すことができると思います。本当の間違いはそうではありません。情報が公開されたら、それで終わりです。

フロントエンドや Android についてお話しましたが、私が作成したアプリは一度もクラッシュしたことがありませんか?
常に段階的にゆっくりと摂取してください。一口で太ることはできません。

Answer 4

フィールドを追加または削除すると、プログラムが実行できなくなると思います。これは個人的な問題ですが、プログラムがオンラインになる前は、要件や変更が不明瞭なためにテーブル構造の変更の問題が発生するのが通常です。モデル層は変更する必要があります。問題がある場合、それはプログラムの書き方があまりにも雑であるか、フロントエンドによってだまされていないことを意味するだけです。フロントエンドが即座に責任を負わせるだけです。具体的な問題を具体的に分析する必要があります。

完全に切り離す方法はありませんが、そのような不正行為の発生を減らすことはできます。

1. 必ずバージョン管理を行ってください。実際、これらのデータ変更は、要件が満たされたときに開発して実装する必要があるとおっしゃっていました。誰でもできるのであれば、データテーブルの構造を変更するのであれば、プロジェクトマネージャーの脳に何か問題があるはずです。したがって、バージョン管理には git、svn などを使用する必要があります。
2. ウェアハウスからオンラインへのデプロイのプロセスでの問題を回避するために、権限管理を適切に行うことが重要です。しなければならない。特にデータベースの変更、バージョンの追加、削除、変更に関しては、アクセス許可を持つユーザーの数が少ないほど、システムの安全性が高まることを覚えておいてください。

Answer 5

プログラム ロジックを改善し、例外処理を追加し、API インターフェイス メッセージ ステータス コードを改善し、エラー処理メカニズムをセットアップして、発生する可能性のあるエラーや例外が発生してもフロントエンドにエラー データを出力できるようにする必要があります。データベース層に関しては、まったく必要ありません。

Answer 6

そう思ってはいけません。このエラーを回避するには、ライブにする前に API カバーのスモーク テストを実行することを検討する必要があります。

Answer 7

上記の返信はすべて「偉大な神」であることがわかりました！なぜなら、私の限られた理解では、「データテーブルが変更されたということは、ビジネスとコードを調整する必要があることを意味する」と考えているからです。データ テーブルが変更されてもコードを変更する必要がない場合は、「データ テーブルを変更する意味は何ですか?」と尋ねたいと思います。 (元の投稿者のデータシートが他人の間違いによるものであるかどうかは考慮しません)。キャッチする例外をプログラムに多数追加できることは否定できません。では、このような例外をキャッチすることに何の意味があるのでしょうか? 500 エラーを返さないようにするためだけですか? したがって、データベースを調整する必要がある場合は、それに応じてコードも調整する必要があることを確認し、問題がないことを確認した後、両方を同時に更新する必要があります。
フロントエンドについて話しましょう。彼は口数が多く、盲目になる方法しか知らないただの愚か者です。あなたは彼にこう尋ねます。インターフェース定義が name というフィールド名を返し、ある日バックエンドが何気なくそれを title に変更した場合、フロントエンドは通知することなく自動的にそれを認識し、エラーを報告しないで済むでしょうか?
つまり、フロントエンド、バックエンド、データベースに変更がある場合は、まずチャイナユニコムを通じてテストする必要があり、問題がなければ、それらは一緒に起動されます。元の投稿者のような状況は、2B の同僚の人為的行為によって引き起こされたとしか言えません。

Answer 8

フロントエンドのレベルがどんどん下がっているということですね…もちろん、データベースを削除したあなたの同僚もこのフロントエンドとほぼ同じです

Answer 9

どこの会社？テーブルは自由に削除できますか?また、フロント部分はバックエンドのコードが十分に堅牢ではないことを嘲笑しています。あなたの会社の人材は本当にひどいです。

Answer 10

まず、あなたの考えは出発点から間違っていると言わざるを得ません。

1. まず、テーブル構造を変更した後も、プログラムは引き続きエラーなしで実行でき、これは実現可能であることを認めなければなりません。バックエンド ロジックでは、データを処理する前にフォールト トレランス処理とエラー キャプチャを追加することで、エラー情報がフロントエンドに直接送信されてフロントエンドがクラッシュするのを防ぐことができます。

2. ただし、プログラムがエラーを報告しないからといって、関数にエラーがないことを意味するわけではありません。例として、メインテーブルが注文テーブルであると仮定します。フォールトトレランス処理があるため、エラーは報告されませんが、注文タイトルデータは書き込まれません。データベース。この場合、演算子を含めたフロントエンドおよびバックエンドの演算子をデバッグすると、プログラムは正常に動作するため、問題が発見されなかった可能性があります。その後、顧客が使用できるようにプログラムがオンラインに公開され、顧客がこの問題に気づいたとき、実際のバグが存在します。 name，后来你把这个数据库字段改成了title，而没有改变后端的代码。由于后端有容错处理，所以下单还是可以正常下单的，但是由于原本标题写入name字段，现在name

3. 注文の別の例を考えてみましょう。同僚がメインのテーブルを削除したと言いました (彼はメインの注文テーブルを削除したと思います)。コードでの順序操作は、最初にメイン テーブルを追加し、メイン テーブルが正常に追加された場合は他のテーブルにデータを追加することです。メインテーブルの追加に失敗した場合は、直接飛び出します。この場合、メインテーブルが削除されてもエラーは報告されません。しかし、このように、開発後のテスト中に、フロントエンド、バックエンド、運用保守のすべてが、この機能は前から良かったので再テストする必要がないと感じた場合は、他の機能をテストします。オンラインにすると、オンライン バージョンで注文を送信できますが、実際には注文データは生成されません (メイン テーブルが正常に書き込まれていないため)。このバグは顧客によって発見された後、製造上の事故とみなされました。

4. したがって、私は個人的にはバックエンドでコードのフォールトトレランスとエラーキャプチャを行う必要があると信じていますが、フロントエンドプログラムに目に見える問題がないからといって、フロントエンドプログラムを変更するだけでよいという意味ではありません関連するロジックを変更せずにデータベースを構築します。データベースを変更し、フロントエンドとバックエンドのロジックを修正した後、オンラインにする前に、独立した関数全体を再テストして、それが正しいことを確認する必要があります。