다중 백엔드 (현재 MySQL 또는 XML)에 연결할 수있는 PHP 응용 프로그램이 있으며 MongoDB와도 작업하려고합니다. 내가 뚜렷하게 고심하는 한 가지 겉으로보기에는 사소한 문제는 몽고 위임장 '_id'가 기본 키의 이름이라는 것입니다. 백엔드는 일반적으로 애플리케이션에 의해 상당히 잘 추상화되어 있지만, 애플리케이션은 이드와 상당히 정기적으로 작업해야하므로, 지금까지 추상화가 잘된 $result['id']과 같은 코드를 사용하여 액세스합니다.MySQL app을 MongoDB에 포팅하고 _id 필드를 수용
하지만 이제는 (효율적으로!) 기본 키로 'ID'를 사용하지 못하게하는 DB를 처리하려고하는데 가장 좋은 옵션이 무엇인지 잘 모릅니다. 여기에 지금까지 생각했습니다 내용은 다음과 같습니다
- 그냥 혼자 몽고의 '_id'값을두고 백엔드에 따라
"id"또는"_id"에$id변수 응용 프로그램을 설정합니다. 응용 프로그램은"id"하드 코드 대신 ID 필드에 액세스하려면$id을 사용해야합니다. 다른 모든 필드는 문자열 이름 (예 :$result['user'])으로 액세스되므로 응용 프로그램의 규범을 위반하게됩니다.장점 : 가능한 경우 MongoCursor 객체를 직접 반환 할 수 있으므로 메모리 사용을 최소화하고 데이터에 빠르게 액세스 할 수 있습니다.
단점 : 하위 호환성이 없으므로이 응용 프로그램을 사용하여 코드를 리팩토링해야합니다 (상당히 지루한).
"_id"이 적절하게 매핑 된 각 항목을 반환하는 새 반복기 클래스에서 반환 된 MongoCursor 개체를 적절하게 줄 바꿈하십시오."id". Mongo와 통신 할 때 응용 프로그램은"id"으로 인바운드 호출을 다시"_id"으로 매핑합니다.장점 : 대부분의 하위 호환성 문제를 방지하면서 대부분의 메모리 효율성을 1로 유지합니다.
단점 : 이러한 개체를 구현하는 방법을 명확히 밝히지 않았거나 확실하게 수행 할 수 없다거나 실제로 상상할 수있는대로 작동하지 않을 수 있습니다. 그것을 올바르게하기 위해, 나는 다른 백엔드를위한 유사한 반복자 래퍼를 구현하기를 원할 것이다.
MongoCollection.find()에서 설명한대로 결과를iterator_to_array()으로 메모리에로드하고 변환을 수행 한 다음 배열을 반환하십시오.장점 : 개념적으로 2보다 간단합니다. 내 앱의 나머지 부분과 잘 작동합니다.
단점 : 분명히 메모리 측면에서 좋지 않은 선택입니다. 앱이 제공되는 세상 끝은 아니지만 여전히 이상적은 아닙니다.
이러한 옵션 중 어떤 옵션이이 문제에 대해 합리적이고 강력한 해결책으로 눈에 띄게합니까? 누구든지 백엔드에 종속되지 않는 방식으로 기본 키를 처리하는 다른 대안을 제안 할 수 있습니까? 추가 백엔드는 향후 가능할 수 있으므로 다른 데이터 저장 시스템과 관련된 주어진 방법의 문제점 또는 이점도 환영합니다.
저는 현재 2 세에 몸을 기울이고 있습니다. 그러나 나는 당신의 생각을 환영합니다.
_id 전체를 무시하고 MongoDB 문서에서 "id"를 사용하고 {id : 1} 색인을 추가하기 만하면됩니다. 내가 생각할 수있는 유일한 단점은 사용되지 않은 _id 색인입니다. "id"는 MongoDB에서 유효하지 않은 필드 이름이 아닙니다. –
'_id'의 동작을 정확히 복제하는 것은 비효율적이고 구현이 잘못되었습니다. 나는 그렇게 나쁘지는 않지만 단지 나에게 맞지 않는 것 같아. – dimo414
음. "오른쪽"은 여러 스토리지 솔루션을 추상화하려고 시도했을 때 창 밖으로 나왔습니다.) 서로 다른 스토리지 솔루션이 기능적으로 다른 스위트 룸을 가지고 있기 때문에 항상 최적의 방법으로 사용하지 못할 것입니다. 나는 그것이 완벽하지 않다고 동의하지만 그것은 당신이 제안한 세 가지보다 더 좋고 더 효율적인 해결책입니다. –