한 열의 유형이 int이고 say의 값이 10 인 경우 다른 열은 varchar 유형이며 값은 '10'입니다. 이 값 (mySql)에 가입하는 것이 안전합니까? 둘 다 int 유형과 value 10 유형 인 경우와 동일한 결과를 얻을 수 있습니까?다른 유형의 열에 가입 하시겠습니까?
하나의 테이블에서 열이 자동 증가 키 (int이어야 함)이기 때문에 여러 유형이 필요합니다. 다른 열 (다른 테이블에 있음)에 문자가 포함 된 값이 포함될 수 있으므로 varchar로 지정해야합니다. 이 문제로 큰 문제를 떠올리거나 내 스키마를 재고해야합니까?
이 방법으로 두 가지 문제가 있습니다
MySQL은 같은 조인에 인덱스를 사용하지 않습니다 - 또는 상황 (테이블 크기/쿼리/등등에 따라 큰 거래를하지 않을 수 있습니다 .. .)
데이터베이스 디자인 - 현명한 냄새가 난다. 아마 그것은 나의 가난한 상상력이다 :-) 그러나 나는 이런 것을 무언가가 정당화 될 수있는 예를 생각할 수 없다. 한 테이블의 기본 키인 경우 다른 테이블의 외래 키 여야합니다. 좀 더 자세하게 설명하려고 할 수 있습니까?
비교 데이터가 동등한 데이터 유형으로 끝나기 위해 데이터를 명시 적으로 변환해야합니다.
설명에 따라 비교하기 전에 int 데이터 유형을 varchar로 변환해야합니다. 공란을 제거하고 DB에 대문자가 설정된 경우주의하십시오. 또한 int 비교는 varchar 비교보다 훨씬 빠릅니다.
틀렸어. 명시 적이든 묵시 적이든 상관없이 변환은 도움이되지 않습니다 - 색인은 여전히 참여를 위해 사용되지 않습니다 : http://dev.mysql.com/doc/refman/6.0/en/mysql-indexes.html. 그렇다고해서 데이터베이스를 모델링 할 이유가 전혀 없다는 것은 아닙니다. – ChssPly76
색인 생성에 관한 질문에서 아무 것도 보지 못했습니다 ... 결과 집합에 관한 op의 질문에 대답하려고했습니다. 예, 그는 명시 적 변환을 수행하여 비교를 수행하여 올바른 결과를 얻을 수 있습니다. 나는 당신의 마음 속에 당신이 가지고있는 질문에 대해 나의 대답이 틀렸다고 말하지 않았지만 그 질문은 대답하기가 어렵습니다. 운영자가 설명 된 방식으로 시스템을 설계해야하는 이유가있을 수 있습니다. 나는 그것이 최적의 해결책이 아니라는 것에 동의하지만, 문제가되는 도메인에 대한 정보가 부족하여 판단을 내릴 수 없습니다. – mson
또한 당신의 대답은 잘못된 것입니다. 왜냐하면 제가 생각하기에 인생의 의미가 무엇인가하는 것이기 때문입니다 ... – mson
내 접근 방식이 결함이 있다고 생각합니다. 다른 테이블의 인덱스와 세션 ID로 사용하여 테이블 중 하나에 열을 저장하려고했습니다. 비즈니스 논리에 따라 테이블이나 개체에서 다른 테이블을 참조해야하는 경우가 있으며 때로는 영숫자가 필요합니다. 세션 ID). 하지만 세션 ID에 대해 varchar 유형의 다른 열을 만들고 null 값을 허용하는 것이 더 좋습니다. –
가장 확실합니다. 의미가 다른 값은 거의 항상 다른 열에 속합니다 (예외가 있지만 그 중 하나가 아님) – ChssPly76