SI에서 혹은 SM에서 mybatis로 지치신 분이 대안으로 생각하는게 ORM일겁니다.
하지만 ORM의 경험자로써 이 글이 많은 부분이 맞다고 생각합니다. ORM vs mybatis or SQL은 편리함과 인간의 사고 방식의 차이라고 생각합니다.
약간의 역사
SQL은 "대규모"(읽기: 수백만 행) 데이터 저장소가 등장한 1970년대에 발명되었습니다 . 다른 쿼리 언어를 능가했기 때문이 아니라( 읽기가 더 쉬웠 지만) 표준이었기 때문입니다. 데이터 저장소를 구축하는 모든 사람은 모든 클라이언트와 고객을 다시 교육하지 않고도 SQL 표준에 쓸 수 있습니다. 전체적으로 마찰을 줄였습니다. 대성공이었습니다.
SQL이 어색하다
우리가 매일 사용하는 SQL이 아름답지 않다는 것은 피할 수 없습니다.
SQL이 실제로 표현하도록 설계된 것은 엄청나게 영리한 EF Codd (관계형 데이터베이스의 거의 모든 다른 이론적 토대와 함께)가 본질적으로 발명한 논리 유형인 관계형 대수 입니다. 익숙하지 않다면 관계 대수를 벤 다이어그램 으로 생각하는 것이 도움이 될 것 같습니다. 이는 집합이 교차하고, 결합하고, 빼고, 서로 결합하는 것에 관한 것입니다. 세트 A의 모든 과일을 세트 B의 가격으로, 세트 C의 농부가 재배한 과일을 찾으세요. 그런 종류의 것입니다.
실제로 사용 하지 않는 것은 데이터 세트의 조합, 집계, 특히 필터링입니다. count(*)가 그렇게 어색한 이유는 그것이 실제로 언어가 하도록 설계된 것이 아니기 때문입니다. GROUP BY 및 ORDER BY 절은 고정된 것처럼 보입니다(HAVING은 훨씬 더 심각한 해킹이고 UNIQUE는 재앙이며 LIMIT에서 시작하지 맙시다). 물론 데이터 세트를 정기적으로 사용하는 경우 거의 항상 이러한 작업을 수행하기를 원하기 때문에 SQL에서 이러한 작업을 제공합니다. 충성스러운 일꾼인 SQL은 의지가 없다면 아무 소용이 없습니다. 그러나 그것은 매우 빠르지 않을 수 있습니다.
그래서 당신이 옳다. 매일 작성하는 SQL은 보기 흉하고 어색합니다. 실제로 다리에 지옥처럼 보입니다. 그리고 그것은 종종 꽤 느립니다. 그리고 그것이 전부입니다. 언어가 실제로 수행하도록 설계되지 않은 작업을 수행하도록 요청하기 때문입니다( 엔진 이 수행하도록 설계되었는지 여부는 또 다른 질문입니다). 그러나 그것은 효과가 있으며, 발명 이후 40년 동안 우리는 개선 방법을 거의 찾지 못했고 대체할 만큼 충분히 강력하지는 않았습니다.
ORM은 어떻습니까?
나는 이것에 대해 아주, 아주 분명하게 말하고 싶습니다. ORM은 어리석은 생각입니다.
ORM의 탄생은 SQL이 추하고 위협적이라는 사실에 있습니다(관계형 대수학은 꽤 어렵고 대부분의 다른 유형의 프로그래밍과 매우 다르기 때문입니다). 우리 프로그램은 이미 객체 지향 모델을 가지고 있고 우리는 이미 하나의 프로그래밍 언어를 알고 있습니다. 왜 두 번째 언어와 두 번째 모델을 배워야 할까요? 이 아기 위에 추상화 계층을 던지고 그 아래에 RDBMS도 있다는 사실을 잊어버리자.
이것은 분명히 어리석은 일입니다. 기본 사용 사례와 일치하지 않는 방식으로 데이터를 저장했으며 배우고 싶지 않은 언어를 통해 액세스할 수 있습니다. 귀하의 솔루션은 상점과 언어를 유지하고 추상화로 포장하는 것입니다. 데이터가 레거시 시스템에 있고 새 프런트 엔드를 작성해야 하지만 사람들이 새 프로젝트 에 ORM을 적용하는 경우 그렇게 할 수 있습니다. 도대체 왜 그럴까요?
ORM은 추상화 계층이 항상 있기 때문에 SQL을 사용하는 것보다 느립니다. 그러나 더 빠른 개발로 성능 저하를 보완하는 다른 추상화 계층과 달리 ORM 계층은 거의 아무것도 추가하지 않습니다. 실제로 SELECT보다 더 복잡한 작업을 수행해야 하는 경우 기본 RDBMS에 실제로 수행하려는 작업을 알리기 위해 SQL 또는 유사 SQL 언어 조각을 작성하게 되는 경우가 많습니다.
OMADS: 애플리케이션과 일치하는 데이터 저장소
ORM은 멍청하고 사람들은 알아차렸습니다. 영리한 프로그래머는 이 말도 안되는 구조를 보고 진짜 문제를 깨달았습니다. 데이터 저장소와 사용 사례가 일치하지 않는다는 것입니다. 그래서 그들은 ORM, SQL, RDBMS를 버리고 멋진 새로운 키-값 저장소, 객체 저장소, 문서 저장소, 검색 가능한 인덱스 또는 그들이 시도한 것과 더 밀접하게 일치하는 6개의 다른 데이터 구조를 작성했습니다. 할 것. 그리고 이러한 데이터 저장소는 거의 모든 데이터 저장소가 SQL 인터페이스 RDBMS였을 때 모두 나타났기 때문에 실제 문제는 SQL 자체가 아니라 관계형 모델이었음에도 불구하고 "NoSQL"이라는 이름을 얻었습니다. 그리고 "분명히 더 적절한 데이터 저장소" 또는 OMADS가 충분히 매력적이지 않기 때문입니다. *
그래서 저는 NoSQL 스토어를 좋아합니다. 내 시작 은 말 그대로 memcache 없이는 작동할 수 없습니다 . 내 생각 에 Cassandra 는 Twitter 가 MySQL에서 전환하는 수고를 들일 가치가 없다고 생각 하더라도 훌륭 하다고 생각 합니다. Redis 가 약간 버그가 있으면 멋지다고 생각 합니다. MongoDB 는 굉장합니다. 저는 아마도 곧 이를 기반으로 하는 프로덕션 시스템을 구축할 것입니다. 매일 프로덕션에서 사용하는 HDFS 는 여전히 내 작은 마음을 아프게 합니다. 정말, 내가 그들에 대해 싫어하는 유일한 생각은 "NoSQL"이라는 레이블입니다. 많은 사람들이 이미 지적했듯이 자신이 무엇인지에 대해 아무 말도 하지 않습니다 ., 그들이 아닌 것. 또한 상황의 세부 사항에 익숙하지 않은 사람들이 SQL에 대해 뭔가 잘못되었거나 잘못되었거나 구식이라고 생각하게 하기 때문입니다. 그리고 프로그래머는 그런 것들을 사용하는 것을 싫어합니다.
어쨌든 관계형 데이터 모델은 무엇에 좋은가요?
따라서 데이터 저장소가 항상 응용 프로그램과 일치해야 하는 경우 RDBMS가 적합한 응용 프로그램은 무엇입니까? 정답은 모두, 그리고 없음입니다.
오늘날 우리는 이것을 당연하게 여기지만 관계형 모델은 매우 마술적입니다. 엔터티의 모델을 설정하고 여기에 데이터를 붓고 답을 얻으십시오. $100,000 이상을 벌지만 20명 미만의 학생을 가르치는 대학의 교사가 몇 명이나 될까요? 우리의 최신 제품을 구매한 고객 중 이전에 구매한 적이 없는 고객은 몇 명입니까? 지난 30개월 동안 화요일의 판매는 어땠습니까? 질문이 무엇인지 미리 알 필요는 없습니다. 모든 행을 검사하거나 결과를 결합하기 위한 가장 효율적인 전략을 찾기 위해 특별한 코드를 작성할 필요가 없습니다. 데이터베이스는 답을 알고 있습니다. 그 개념을 처음으로 골똘히 생각했을 때를 기억하고, 그것은 괴상한 기쁨으로 저를 채웠습니다.
응용 프로그램을 처음 작성할 때 저장소에 대해 잘못된 데이터 구조를 선택하면 마지막 작업에서 팀이 겪었던 것처럼 분산 문서 저장소에서 며칠 동안 미친듯이 깊이 우선 검색을 실행하게 될 수 있습니다. 총 개체 수를 얻는 것과 같은 기본 작업을 수행하기 위해. 따라서 데이터에 대해 물어봐야 할 모든 질문을 모르는 경우 가장 안전한 방법은 해당 질문을 RDBMS에 저장하는 것입니다. 그리고 프로젝트를 처음 시작할 때 물어봐야 할 모든 질문을 거의 알지 못합니다. 그래서 내 충고: 항상 RDBMS를 사용하십시오. RDBMS 만 사용 하지 마십시오 .
최적화하되 임시 쿼리에 대비하세요.
데이터가 정말 거대한 해시 조회에 불과합니까? 그러면 키-값 저장소가 원하는 것입니다. 주로 단일 키를 통해 관련 데이터에 액세스합니까? 그렇다면 문서 저장소는 당신을 위한 것입니다. 전체 텍스트 검색이 필요하십니까? 그런 다음, 신이시여, RDBMS가 아닌 텍스트 인덱싱 엔진 을 사용하십시오. 예측할 수 없는 데이터에 대한 질문에 미리 답해야 합니까? 그런 다음 데이터가 RDBMS에서도 끝나는지 확인하십시오. 실시간이 아닐 수도 있고, 원시 형태가 아니라 요약될 수도 있지만 어떻게든. 그런 다음 공동 창립자가 "Y에서 X가 몇 개나 발생했습니까?"라고 물으면 당신의 대답은 "어, 그것을 찾기 위해 코드를 작성하는데 반나절을 보내겠습니다"가 아닐 것입니다. SQL을 몇 개 던지면 답이 나옵니다. 단일 숫자를 반환하는 데 5분이 걸리지만 반나절보다 훨씬 빠릅니다.
그것이 SQL의 목적이기 때문입니다.
SQL 이후
맨 위로 스크롤하면 SQL을 탄생시킨 상황에 대한 설명이 표시됩니다. 한 번에 많은 새로운 데이터 저장소가 생겨났고 공통 언어의 부족으로 마찰과 단편화가 발생했습니다. 같은 일이 NoSQL 군중과 함께 다시 일어나고 있습니다. Cassandra를 사용하여 앱을 작성하기로 결정했다면 상점을 변경하면 모든 코드를 변경해야 하기 때문에 원하는 것이 맞는지 확인하는 것이 좋습니다. 그것은 궁극적 인 구속이며 사악한 독점 기업의 계획이 아니라 불행한 부작용 일뿐입니다.
곧 ORM이 터무니없는 해킹이라는 것을 알아차린 같은 종류의 영리한 사람들은 실제로 유용한 추상화 계층, 즉 모든 NoSQL 저장소에 액세스할 수 있는 단일 공통 API가 열리는 것을 알게 될 것입니다. 아마도 Thrift 또는 Avro 가 될 것입니다 . 하지만 확실하지 않습니다. 나는 그것이 다시 SQL이 될 가능성이 약 50-50이라고 말하고 싶습니다.
SQL 승리
그리고 왜 안되지? 어색할 수 있지만 SQL은 여러 줄의 API 호출이나 미친 수학 같은 관계형 대수 언어 보다 훨씬 더 간결하고 읽기 쉽습니다 . 그리고 언어 자체에 본질적으로 느린 것은 없습니다. Cassandra에서 "SELECT * FROM table WHERE ..."를 실행할 수 있다면 API 호출을 통해 동일한 조건을 지정하는 것보다 느리지 않을 것입니다. 실제로 API를 사용하는 방법을 설명하려고 할 때 MongoDB 설명서에는 동등한 SQL 쿼리가 나열되어 있습니다. 그것은 SQL의 유용성에 대한 아주 분명한 투표입니다.
컴퓨터 프로그래머는 새롭고 멋진 것을 정말 좋아합니다. 따라서 SQL과 같은 것이 거의 40년 동안 사용되었다는 것은 아무도 그것에 대해 신경을 쓰지 않는다는 것을 의미합니다. 제 생각에는 그렇지 않다는 것이 분명하다고 생각합니다.
그러니 앞으로 나아가서 OMADS를 사용하고 RDBMS를 뒷주머니에 보관하고 오래된 SQL에 대해 그렇게 비열한 행동을 하지 마십시오.
[광고] STEEM 개발자 커뮤니티에 참여 하시면, 다양한 혜택을 받을 수 있습니다.
Downvoting a post can decrease pending rewards and make it less visible. Common reasons:
Submit