간단한 질문 일 수는 있지만 예상보다 어려울 수 있습니다. 사용자 및 비즈니스의 위도와 경도를 추적하려고한다고 가정 해 보겠습니다. 지금은 locTable이라는 테이블이 있습니다.이 테이블에는 인덱스, 위도, 경도의 세 열이 있습니다.데이터베이스의 공유 테이블 또는 다중 데이터? DB에 실제 위치 저장
사용자 및 비즈니스 정보를 저장하는 테이블에는 locTable에 대한 FK가 포함되어 있습니다. 이렇게하면 하나의 테이블을 사용하여 위치 데이터를 저장할 수 있지만이 데이터에 대한 쿼리를 수행하는 것이 어려울 수도 있습니다.
이제는 사용자 및 기업의 각 테이블에 위도 및 경도 정보를 저장할 수 있지만 데이터를 변경해야하는 경우 2 개 이상의 다른 테이블과 함께 쿼리를 업데이트해야합니다.
무엇을 제안 하시겠습니까? 정보를 별도로 공유하거나 저장 하시겠습니까?
먼저, 위도/경도가 "조회"표인지 확인하십시오. 위도/경도를 조회로 간주하지 않습니다. 이것이 의미하는 바는 가능한 모든 위도/경간 콤보의 철저한 목록을 저장하지 않는다는 것입니다. 그들은 종종 4 자리 소수로 지정됩니다. 이론 상으로는 무한 규모의 무한한 위도/경간 콤보가있을 수 있습니다.
두 테이블에 lat/long을 저장하는 중복을 고려하지 않았습니다. 생년월일을 생각해보십시오. 생년월일 중복을 피하기 위해 지난 300 년 동안 매일 행이있는 "생년월일"테이블을 가질 수 있습니다. 이것은 사람, 개 및 회사의 BirthDay 중복을 피할 것입니다. 그러나 "조회 (lookup)"의미와 중복되는 것은 아닙니다.
나는 위도/경도를 자체 테이블에 저장하는 것이 잘못된 것이라고 제안하지 않습니다. 나는 두 테이블 모두에 위도/경도를 저장하는 중복으로 간주하지 않을 것을 제안합니다.
위치가 변경 되었습니까? 그렇다면, 외래 키를 반대로하십시오. 위치 테이블에 사용자 및 비즈니스 테이블에 외래 키가 있어야합니다. 위치 테이블에 날짜 열을 추가하고 새로운 위치를 추가하는 것만으로 시간을 추적 할 수 있습니다.
모델에서 위치를 업데이트하기 위해 잠재적으로 두 테이블을 업데이트해야합니다. 외래 키를 전환하면 위치가 변경 될 때 위치 테이블에 새 행을 추가하기 만하면됩니다.
이론적으로 위치는 모두 예를 변경했을 수 있습니다. –
그런 다음 위치 테이블에 새 행을 추가하면 더 쉽게 작업 할 수 있습니다. 사용자 및 비즈니스 테이블은 전혀 변경하지 않아도됩니다. 또는 시간 경과에 따른 위치의 변경 사항을 추적하지 않으려는 경우 위치 행을 업데이트 할 수 있습니다. – MonkeyWrench
참. 나는 또한 도시에도 위치가 있다는 것을 잊는다. 여러 위치 (도시마다 다른 우편 번호가 있으며 우편 번호를 기반으로 함). 나는 실제로 얼마나 악몽 같은 질문이 될 수 있는지 궁금 할뿐입니다. 예를 들어 두 사용자의 위치가 동일한 테이블에있는 경우 사용자와 비즈니스 간의 거리를 파악하려고 시도합니다. –