2010-02-28 9 views
1

두 테이블 : membersmembers_data이 있습니다.
둘 다 동일한 고유 한 자동 증분 id 키와 고유 한 username 필드를 공유합니다.두 개의 MySQL 테이블 병합 및 별칭

내가 한 members 테이블, 하지만 내가 members & members_data 참조를 사용하여 ~ 50 스크립트가로 두 테이블을 병합하려는

. 내 members_data 쿼리가 새로운 members 테이블을 가리 키도록 일부 별칭 설정이 필요합니다.

이것이 가능합니까?

답변

1

다른 테이블에서 SELECT *를 수행하는보기를 작성하면 실제로 다른 테이블에 별명을 지정할 수 있습니다. 이것은 안 좋은 일이 할, 그러나입니다 : (그들은 물론, 소스 코드에서보기 **를 볼 수 있습니다)

  • 정말 다른 테이블 뷰를함으로써 미래의 코드 메인테이너 혼란
  • 어떤 경우에는 최적화 프로그램에서 비효율적 일 수 있습니다.
  • 올바른 방법으로 리팩토링하는 것이 아닙니다.

그러나 "50 개의 스크립트"를 테스트하는 것이 얼마나 쉬운지, 얼마나 중요한지 (힌트 : 테스트하기 어려운 매우 중요한 코드는 효과적인 개발에 실질적인 영향을 줄 수 있음)보기를 생성합니다. 단기적으로는 실용적 일 수 있습니다 (그리고 단기 솔루션은 일반적으로 수년간 또는 실제 응용 프로그램에서 영원히 유지됩니다).

"50 개의 스크립트"를 변경하고 그러한 변경을 릴리스하는 데 필요한 모든 테스트를 수행하는 것이 좋습니다. 우리 팀에서는 "50 개의 스크립트"이상을 수정 한 변경 사항 (단일 릴리스에서)을 수행했지만 테스트는 물론 까다로운 (또는 시간이 많이 소요되는) 것으로 입증되었습니다.

응용 프로그램이 커지고 복잡 해짐에 따라 회귀 테스트가 더욱 어려워집니다. 리팩토링이 필요할 것이기 때문에 가능한 한 많이 생각하는 것이 중요합니다 (앱이 모두 개발되거나 유지된다고 가정 할 때). 회귀가 나쁘기 때문에 가능합니다.

** 모든 테이블, 뷰 등은 스크립트로 작성되어 있으며 물론 소스 코드 관리 시스템에서!

+0

업데이트 된 쿼리에서 작동하지 않으므로 뷰를 사용할 수 없습니다 (실제로 테이블을 제거한 후에 구성원을 업데이트하려면 member_data를 업데이트해야합니다.) 뷰가 최적화되지 않았다고 말하면서 스크립트를 변경해야하며 오랜 시간 동안 뷰를 최적화 할 수 없습니다. 도움을 주셔서 감사합니다 – Juddling

+0

업데이트가 의미가없는 방식으로 정의되어 있지 않으면보기를 업데이트 할 수 있어야합니다. "SELECT * from t"보기는 괜찮습니다. – MarkR

0

둘 다 동일한 고유 한 자동 증가 ID 키와 고유 한 사용자 이름 필드를 공유합니다.

이 문장은 의미가 없습니다. MySQL (또는 대부분의 rDBMS에서 두 테이블이 열을 공유 할 수있는 방법)이 없습니다.

질문에 대한 몇 가지 가능한 대답이 있지만 실제 스키마를 보지 않고서는 알기가 어렵다고 생각됩니다.

실제로 두 테이블 모두에 고유하고 두 테이블의 크기가 동일하고 두 테이블 모두에 id라는 자동 증가 열이있는 경우 두 가지 테이블이 훨씬 더 명확합니다. 기본 테이블 모두에서 컬럼을 구현하는 복합 테이블을 작성하고, 데이터를이 테이블로 이주하고 원래 테이블 2 개를 뷰로 대체하십시오.

c

+0

미안하지만 나는 공유를 말하지 말았어야했고, 내가 말했을 경우 그들은 둘 다 도움이되었을 행 수가 같았을 것입니다. – Juddling

+0

행? 아니, 그건 전혀 도움이 안돼. – symcbean

+0

각 구성원마다 고유 한 ID가 있습니다. 각 구성원에는 두 구성원과 members_data의 행이 있습니다. – Juddling