php - 테이블 구조가 변경될 때 프로그램이 정상적으로 실행되는 것을 방지할 수 있는 아키텍처는 무엇입니까?

Question

오늘 프론트엔드님께서 백엔드에서 테이블 구조를 조금 변경하면(테이블 삭제, 필드 변경 등) 프로그램이 실행되지 않는다는 교육을 받았습니다. 그러면 어떻게 되는지 알고 싶습니다. 위의 문제가 발생하지 않도록 하려면 각 테이블마다 필드 매핑을 수행해야 합니까? 아니면 다른 기술이 필요한가요?

추가로 제가 디자인한 라이브러리의 메인 테이블이 다른 사람에 의해 삭제되었고, 심사해야 할 일부 필드의 의미가 색상 심사와 유사한 상태로 변경되었다는 이야기가 나왔습니다. , 판단 모양으로 변경되었고 결과는 다음과 같습니다. 프런트 엔드에서 코드가 충분히 견고하지 않다고 조롱하면서 프로그램에 뭔가가 빠졌고 영향이 없다고(안드로이드) 말문이 막혔습니다. 그나저나 나는 Dalao와 다른 사람들이 기능적 디커플링에 관해 무엇을 해야 하는지 알고 싶었습니다

.

Answer 1

당신의 아이디어는 매우 문제가 있는 것 같습니다.
프로그램 자체가 데이터를 처리합니다. 데이터 테이블의 변경은 데이터 및 데이터 구조 자체의 변경과 동일합니다. 이 경우 원본 코드의 논리적 합리성에 확실히 영향을 미치므로 원본 코드를 수정해야 합니다. . 테이블을 삭제하거나 필드를 변경하는 것은 말할 것도 없고, 해당 데이터가 논리 자체에 큰 영향을 주지 않는 단순한 데이터 사전이 아닌 이상 프로그램에 버그가 있는 것은 정상입니다.
그리고 도대체 프론트엔드에서 뭘 교육받고 있는 걸까요. 프런트엔드와 백엔드는 데이터 상호 작용만 잘하면 됩니다. 백엔드는 데이터를 제공하고, 프런트엔드는 이를 표시하는 역할을 담당합니다. -end. 데이터 인터페이스와 인터페이스에서 제공하는 데이터가 정상이라면 프런트 엔드는 뒤에서 무슨 일이 일어나고 있는지 알 수 없습니다.

Answer 2

데이터베이스 설계는 데이터베이스 패러다임과 세 가지 모드를 고려합니다.
하지만 제가 아는 아키텍처 중 그 어떤 것도 완전히 분리될 수는 없습니다. 데이터베이스와 프로그램 간의 결합은 아키텍처를 통해서만 줄어들 수 있습니다. 이 문제를 해결하는 효과적인 방법은 데이터베이스를 설계할 때입니다. 요구 사항을 최대한 이해하고, 더 많이 생각하고, 테이블 변경을 줄이고, 코드를 표준화하고 일부 디자인 패턴을 채택하여 확장성을 높이십시오.

Answer 3

데이터베이스가 삭제되었는데 어떻게 정상적으로 실행될 수 있다고 생각하시나요?
예외를 잘 처리해야 한다고 생각합니다. 데이터베이스 PDO에 예외가 있으면 페이지에 [Server is down] 등이 직접 표시될 수 있고, 인터페이스에서는 상태 = 500 등을 직접 반환할 수 있습니다. 실제 오류는 정보가 노출되면 그게 전부가 아닙니다.

제가 말씀드린 프론트엔드나 안드로이드의 경우, 제가 작성한 앱이 충돌한 적이 없나요?
항상 천천히 차근차근 따라가세요. 한입에 살이 찌지는 않습니다.

Answer 4

필드를 추가하거나 삭제하면 프로그램이 실행되지 않는 것 같아요. 프로그램이 온라인 상태가 되기 전에는 요구 사항이 불분명하고 수정 후에는 테이블 구조 수정 문제가 발생하는 것이 정상입니다. 쿼리를 수정해야 합니다. 문제가 있는 경우에는 프로그램을 너무 지저분하게 작성했거나 API를 테스트하지 않았다는 의미일 뿐입니다. 단지 프런트엔드가 즉시 당신에게 책임을 전가한다는 것뿐입니다. 구체적인 문제는 여전히 구체적이어야 합니다

.

완전히 분리할 수 있는 방법은 없지만, 이런 부정 행위의 발생을 줄일 수는 있습니다.
1. 버전 관리를 꼭 하세요. 사실 다른 사람이 메인 테이블의 변경 사항을 삭제했다고 하더군요. 이러한 변경 사항은 요구 사항이 통과되면 다음 버전에서 개발 및 구현되어야 합니다. 누구나 할 수 있는 일이라면, 데이터 테이블 구조를 바꾼다면 프로젝트 관리자의 두뇌에 문제가 있는 게 틀림없다. 따라서 버전 관리를 위해서는 git, svn 등을 사용해야 합니다.
2. 웨어하우스에서 온라인으로 배포하는 과정에서 문제가 발생하지 않도록 권한 관리를 잘하는 것이 좋습니다. 해야 하다. 특히 데이터베이스 변경, 버전 추가, 삭제 및 수정과 관련하여 권한을 가진 사람이 적을수록 시스템이 더 안전하다는 점을 기억하십시오.

Answer 5

프로그램 로직을 개선하고, 예외 처리를 추가하고, API 인터페이스 메시지 상태 코드를 개선하고, 오류 처리 메커니즘을 설정하여 가능한 오류나 예외가 여전히 프런트 엔드에 오류 데이터를 출력할 수 있도록 합니다. 충분히 강력합니다. 데이터베이스 계층은 전혀 필요하지 않습니다.

Answer 6

그런 생각은 하지 마세요. 이 오류를 방지하려면 라이브로 전환하기 전에 API 커버에 대한 스모크 테스트 실행을 고려해야 합니다.

Answer 7

위 답변들은 모두 '위대한 신들'인 것으로 확인되었습니다! 왜냐하면 저의 제한된 이해로는 데이터 테이블이 변경되었으므로 비즈니스와 코드를 조정해야 한다는 의미라고 생각하기 때문입니다. 데이터 테이블이 변경되어 코드를 수정할 필요가 없다면 다음과 같이 묻고 싶습니다. 데이터 테이블을 수정하면 무슨 의미가 있습니까? (포스터의 데이터시트가 누군가의 실수로 인해 발생한 것인지는 고려하지 말자.) 프로그램에 잡기 예외를 많이 추가할 수 있다는 것은 부인할 수 없습니다. 그렇다면 그러한 예외를 포착하는 이유는 무엇입니까? 500 오류를 반환하지 않으려면? 따라서 데이터베이스를 조정해야 하는 경우 코드도 그에 맞게 조정해야 하는지 확인해야 하며, 문제가 없는지 확인한 후 두 가지가 동시에 업데이트됩니다.
프론트 얘기를 해보자면, 그는 말을 많이 하고 장님이 될 줄만 아는 바보일 뿐입니다. 그에게 물어보세요. 인터페이스 정의가 이름이라는 필드 이름을 반환하고 어느 날 백엔드가 이를 제목으로 자연스럽게 변경하면 프런트엔드가 그에게 알리지 않고 자동으로 이를 인식하고 오류를 보고하지 않을 수 있습니까?
간단히 말하면 프론트엔드, 백엔드, 데이터베이스에 변경사항이 있을 경우 먼저 차이나 유니콤을 통해 테스트를 거쳐서 문제가 없으면 함께 런칭하게 됩니다. 원작 포스터와 같은 상황은 2B 동료의 인간적인 행동에 의해 발생했다고밖에 할 수 없다.

Answer 8

이제 프론트엔드 수준이 점점 낮아지는군요... 물론 데이터베이스를 삭제한 동료도 이 프론트엔드와 거의 같습니다

Answer 9

어떤 회사인가요? 테이블을 마음대로 삭제할 수 있나요? 나도 확신한다. 또한 앞부분은 충분히 견고하지 않다는 이유로 백엔드 코드를 조롱하고 있다. 당신 회사의 인재는 정말 엉망입니다.

Answer 10

우선 당신의 생각은 출발점부터 틀렸다는 점을 말씀드리고 싶습니다.

1. 먼저, 테이블 구조가 변경된 후에도 프로그램이 여전히 오류 없이 실행될 수 있다는 점을 인정해야 합니다. 백엔드 로직에서 데이터를 처리하기 전에 내결함성 처리 및 오류 캡처를 추가하면 오류 정보가 프런트엔드로 직접 전송되어 프런트엔드가 충돌하는 것을 방지할 수 있습니다.

2. 그러나 프로그램이 오류를 보고하지 않는다고 해서 해당 기능에 오류가 없다는 의미는 아닙니다. 상황을 예로 들어보겠습니다. 기본 테이블이 주문 테이블이라고 가정하면 원래 주문 제목 필드가 존재하지 않습니다. 오류 허용 처리가 있기 때문에 오류는 보고되지 않지만 주문 제목 데이터는 기록되지 않습니다. 데이터베이스. 이런 경우에는 프론트엔드와 백엔드 운영자를 디버깅할 때 프로그램이 정상적으로 실행되기 때문에 문제가 발견되지 않았을 수도 있습니다. 그런 다음 고객이 사용할 수 있도록 프로그램을 온라인에 게시하고 고객이 이 문제를 발견하면 실제 버그가 있는 것입니다. name，后来你把这个数据库字段改成了title，而没有改变后端的代码。由于后端有容错处理，所以下单还是可以正常下单的，但是由于原本标题写入name字段，现在name

3. 또 다른 주문 예를 들어보겠습니다. 동료가 메인 테이블을 삭제했다고 하더군요(아마도 메인 주문 테이블을 삭제한 것 같습니다). 코드에서 주문 작업은 기본 테이블을 먼저 추가한 다음 기본 테이블이 성공적으로 추가되면 다른 테이블에 데이터를 추가하는 것입니다. 메인 테이블 추가에 실패하면 바로 튀어나옵니다. 이 경우, 메인 테이블을 삭제하더라도 오류가 보고되지 않습니다. 그러나 이런 방식으로 개발 후 테스트 과정에서 프런트엔드, 백엔드, 운영 및 유지 관리 모두가 이 기능이 이전에 좋았고 다시 테스트할 필요가 없다고 느끼면 다른 기능을 테스트합니다. 온라인에 올리면 온라인 버전이 주문을 제출할 수 있지만 실제로는 주문 데이터가 생성되지 않습니다(기본 테이블이 성공적으로 작성되지 않았기 때문입니다). 이 BUG는 고객사에서 발견된 이후 생산사고로 간주되었습니다.

4. 그래서 저는 개인적으로 백엔드에서 코드 내결함성 및 오류 캡처가 필요하다고 생각하지만, 프런트엔드 프로그램이 육안으로 보이는 문제가 없다고 해서 코드만 변경하면 된다는 의미는 아닙니다. 관련 로직을 수정하지 않고 데이터베이스를 수정합니다. 데이터베이스를 수정하고 프런트엔드 및 백엔드 로직을 수정한 후 전체 독립 기능을 다시 테스트하여 온라인 상태가 되기 전에 올바른지 확인해야 합니다.