MySQL에 꼭 알아야 할 8가지 함정

Mysql은 설치가 쉽고 빠르며 기능이 풍부합니다. 또한, 오픈 소스 운동의 벤치마크이기도 하며, 오픈 소스 코드를 기반으로 성공적인 회사를 구축할 수 있다는 점을 보여줍니다.

그런데 MySQL을 사용해본 사람이라면 누구나 모니터를 향해 주먹을 휘두르곤 했을 것이다. 그러나 초당 수천 행의 인터넷 데이터를 오류 없이 저장할 수 있는 기술을 개발할 수는 없습니다.

올 여름을 즐겁게 보내기 위해 오픈 소스 관계형 데이터베이스에 대해 불평해야 할 8가지 이유를 나열합니다. 아래 나열된 이유는 MySQL에만 국한되지 않으며 일부는 관계형 데이터베이스에만 해당됩니다. 관계형 데이터베이스와 MySQL을 이해하지 못한다면 우리는 항상 1990년대의 생각에 갇혀 있을 것입니다. 우리는 이것을 허물고 다시 재건해야 합니다. 또는 아래와 같은 여러 가지 이유를 정당화할 만큼 오래되지 않은 최근 인기 있는 데이터베이스를 사용합니다.

뿌리 깊은 버그

큰 패키지에는 버그가 있습니다. 하지만 조금 더 깊이 파고들어보면 MySQL과 관련된 버그들은 자립적이라는 것을 알 수 있습니다. NULL이 같은 방식으로 나타나지 않고, 외래 키 제약 조건이 생각한 대로 수행되지 않으며, 기본 키 자동 증가조차 잘못되기 때문에 갑자기 주의를 기울여야 합니다.

작은 문제는 많고 항상 해결 가능한 것은 아니기 때문에 목록을 작성하는 사람들도 있습니다. 다행스럽게도 MySQL은 아주 좋은 버그 보고 시스템을 유지하고 있기 때문에 우리는 우리가 상상할 수 없는 일들을 알 수 있고, 다른 사람들도 같은 시련을 겪고 있다는 것을 알 수 있습니다.

관계형 테이블의 경직성

관계형 테이블은 체계적으로 구성되어 있지만 구성은 양호합니다. 그러나 이로 인해 프로그래머는 열에 정의된 스키마에 일부 데이터를 구성하거나 묶어두어야 합니다. NoSQL이 점점 더 대중화되는 이유 중 하나는 프로그래머에게 데이터베이스 사용 속도를 높일 수 있는 충분한 유연성을 제공하기 때문입니다. 거리 주소에 추가 행이 필요한 경우 해당 행을 NoSQL 문서에 쉽게 삽입할 수 있습니다. 완전히 새로운 데이터 블록을 추가하려는 경우, 포함된 내용에 관계없이 문서 모델은 필요한 데이터 형식으로 변경하지 않고도 데이터를 변경하지 않고 받아들일 수도 있습니다.

모든 우편번호가 정수 형식으로 포함된 테이블을 생성한다고 상상해 보세요. 이 테이블은 매우 효율적이며 적용되는 규칙도 매우 좋습니다. 갑자기 누군가 하이픈을 사용한 9자리 우편번호를 업로드했습니다. 아니면 캐나다에 있는 고객으로부터 우편번호가 적힌 편지를 받을 수도 있습니다.

이때 모든 것이 혼란스러웠습니다. 상사는 몇 시간 내에 웹사이트를 다시 복구하고 운영할 것을 요구합니다. 그러나 데이터베이스를 다시 구축할 시간이 없습니다. 프로그래머는 무엇을 할 수 있나요? 아마도 해커를 사용하여 캐나다 우편 번호를 base64 디지털 형식에서 base 10 형식으로 변경할 수 있을까요? 아니면 실제 우편번호 등을 표시하기 위해 이스케이프 코드를 사용하는 보조 테이블을 설정하시겠습니까? 누가 알겠어요? 해커는 어디에나 있고 위험합니다. 하지만 그것을 알아낼 시간이 없습니다.

MySQL의 연관 규칙은 모든 사람을 정직하고 조심스럽게 유지하지만 공격과 속임수에 취약한 문제를 피하도록 강요합니다.

JOIN 공동 쿼리

옛날에는 데이터를 별도의 테이블에 저장하는 것은 컴퓨터 과학 역사상 큰 혁신이었습니다. 분리된 테이블은 구조가 간단할 뿐만 아니라 사용도 간편합니다. 하지만 쿼리에는 조인 문을 사용해야 합니다.

SQL은 일련의 조인을 통해 구성된 복잡한 쿼리로 개발자를 혼란과 절망의 나락으로 몰아넣습니다. 또한 스토리지 엔진은 최적의 방식으로 조인 문을 효율적으로 구문 분석해야 합니다. 개발자는 쿼리 문을 작성하기 위해 머리를 써야 하며, 그런 다음 데이터베이스가 이를 구문 분석합니다.

이것이 실행 속도에 중점을 두는 많은 개발자가 데이터 하위 테이블을 버리고 대신 비표준 데이터 테이블을 사용하는 이유입니다. 복잡한 쿼리를 방지하려면 데이터 엔터티를 구분하지 말고 모든 데이터를 하나의 큰 테이블에 저장하세요. 이것은 정말 빠르며 서버의 메모리가 부족하지 않습니다.

요즘 디스크 공간이 저렴해요. 8TB 디스크는 이미 판매 중이며 더 큰 디스크도 곧 출시될 예정입니다. 더 이상 조인을 사용하기 위해 머리를 쓸 필요가 없습니다.

브랜치의 혼란

예, 견고하고 잘 지원되는 MySQL 포크는 경쟁과 선택을 가져올 수 있지만 혼란과 혼란을 야기할 수도 있습니다. 설상가상으로 Monty Widenius가 관리하는 MariaDB라는 MySQL 포크가 있습니다. 그는 또한 MySQL 작성에도 참여하고 있습니다. 그렇다면 MariaDB는 진정으로 독립적이고 우리의 지원을 받을 가치가 있습니까? 아니면 MySQL인가요? 원래 MySQL 데이터베이스를 만든 조직에서 운영하는 핵심 코드를 고수해야 할까요? 아니면 더 똑똑하다고 여겨지는 종종 멋진 탈북자들과 합류해야 할까요?

그리고 호환성에 대한 정보는 어떻게 얻나요? 한편으로 우리는 MariaDB와 MySQL이 매우 유사하다고 확신합니다. 반면에 우리는 차이점이 있다고 믿어야 합니다. 그렇지 않으면 왜 모두가 그것에 대해 논쟁을 벌이는 걸까요? 성능과 쿼리 범위 측면에서 두 캠프 모두에서 동일한 방식으로 작동할까요? 그러나 아마도 그들은 다를 수도 있고, 미래에는 달라질 수도 있습니다.

스토리지 엔진 혼란

MySQL은 사실상 동일한 데이터베이스가 아니며, 여러 데이터베이스로 구성되어 있으며 대부분의 세부 정보는 균일한 표면에 의해 가려져 있습니다. 처음에는 MyISAM 엔진이 있었는데 속도는 빠르지만 일관성 측면에서 완전하지는 않았습니다. 때로는 속도가 필요하고 일관되지 않은 결과를 수용할 수 있는 경우에 좋습니다.

사람들이 더 필요로 할 때 완전한 트랜잭션 지원 기능을 갖춘 InnoDB가 등장했습니다. 그러나 이것만으로는 충분하지 않습니다. 이제 데이터베이스 관리자를 미치게 만들기에 충분한 20개의 스토리지 엔진 선택이 있을 수 있습니다. 물론 SQL을 다시 작성할 필요 없이 서로 다른 스토리지 엔진 간에 전환하는 것이 좋을 때도 있지만 전환 후에는 항상 혼란이 발생합니다. 이 테이블의 엔진으로 MyISAM 또는 innoDB를 선택해야 합니까? 아니면 출력하기로 결정한 데이터가 CSV 형식이 되나요?

이익 동기

MySQL은 성공적인 오픈 소스 제품이지만 여전히 이를 통해 돈을 받는 전문 개발자들로 가득 찬 사업입니다. 대부분의 사용자는 오픈 소스 라이선스가 제공하는 최고의 경험을 계속 즐기고 있지만 이 회사가 여전히 운영을 유지하기에 충분한 돈을 벌기 위해 고군분투하고 있다는 것은 의심의 여지가 없습니다. 이로 인해 "커뮤니티 에디션"과 기업에 판매되는 전체 제품 사이에 무료 코드가 이상하게 분기됩니다.

내야하나요? 여기서 돈을 얼마나 벌어요? 커뮤니티 버전에서 운영하는 것이 공정합니까? 엔터프라이즈 버전의 추가 기능은 우리가 더 많은 비용을 지불하도록 유도하기 위한 속임수에 불과합니까? 이는 적어도 대답해야 할 또 다른 질문이 있다는 것을 보여줍니다. 어떤 버전을 선택해야 할까요? 어떤 라이센스에 따라? 어떤 기능 세트를 사용해야 합니까?

최신 데이터 스토리지 계층은 JSON으로 직접 통신하는 경우가 많습니다. 이제 MySQL과 MariaDB에는 SQL의 JSON 부분을 구문 분석하는 기능이 있지만 이것만으로는 충분하지 않으며 기본 JSON 인터페이스는 이미 CouchDB, MongoDB 또는 최신 도구에서 널리 사용되고 있습니다.

폐쇄 소스 및 독점 모듈의 부상

MySQL이 오픈 소스라고 언급했나요? 일부 새로운 비오픈 소스 코드와 "오픈 소스 코어"를 중심으로 개발된 독점 모듈을 제외하고는 그렇습니다. 프로그래머는 밥을 먹어야 하고, 오라클은 노력의 결실을 돈으로 바꿔야 합니다. 이것이 비즈니스의 현실 중 하나입니다. MySQL을 사용하여 무료로 진료를 받는 병원과는 다릅니다. MySQL을 사용하여 식량을 기부하는 농부와는 다릅니다.

오픈 소스 성공이 함정이 될 수 있기 때문에 MySQL에 항상 매우 높은 표준을 유지하도록 요구하는 것은 다소 불공평합니다. 그것은 단지 처음부터 자유로울 수 있기 때문일 뿐, 그렇다고 해서 항상 그렇게 될 수 있다는 의미는 아닙니다. 기업이 많은 새로운 기능을 원한다면 어떤 식으로든 그에 대한 비용을 지불해야 합니다. 때로는 코드를 직접 작성하는 것보다 Oracle에 비용을 지불하는 것이 더 저렴할 때도 있습니다. 때로는 상업용, 비오픈 소스 코드가 의미가 있는 경우도 있습니다. 사실은 스스로를 말해줍니다.

위 내용은 꼭 말해야 할 8가지 MySQL 트랩입니다. 더 많은 관련 내용은 PHP 중국어 홈페이지(www.php.cn)를 참고해주세요!