개발숭이

INDEX란? 저장된 데이터를 가지고 서비스할 때 검색 성능을 높이기위한 기술 테이블의 동작속도(조회)를 높여주는 자료구조 UPDATE, INSERT, DELETE의 속도는 저하되며 저장 공간(DB의 10%정도) 차지한다는 단점이 있음 왜? 레코드를 추가, 삭제, 수정할 때 생성된 인덱스에도 데이터 동기화를 해주어야해서 오버헤드가 생기기 때문 INDEX의 종류? 클러스터형, 보조 인덱스 클러스터형은 테이블당 한개만 생성가능. 우리가 Primary Key로 지정하는 컬럼이 클러스터형 인덱스. 생성과 동시에 오름차순으로 정렬됨. NOT NULL Unique 제약조건도 클러스터형 인덱스가 될 수 있지만 Primary Key와 동시에 만든다면, Primary Key가 우세함으로 클러스터형 인덱스가 됨 보조 인덱..

-- 스키마에 있는 KEY 조회 SELECT * FROM information_schema.table_constraints WHERE constraint_schema = '스키마이름'; -- FK 설정 되어있을 때 속성 변경 -- 제약조건 끄기 SET FOREIGN_KEY_CHECKS = 0; SET GLOBAL FOREIGN_KEY_CHECKS=0; -- 실행할 구문 /* 예시 ALTER TABLE obs_info CONVERT TO CHARACTER SET utf8; ALTER TABLE obs_hist CONVERT TO CHARACTER SET utf8; */ --제약조건 키기 SET FOREIGN_KEY_CHECKS = 1; SET GLOBAL FOREIGN_KEY_CHECKS=1 -- FK 삭..

문제 상황: AJAX 요청을 하고 JSON 응답을 기대할 때 파싱 오류. 특히 JSON 형식이 올바른 것처럼 보일 때 이러한 오류는 더욱 당혹스럽습니다. 데이터베이스 데이터에 개행 문자가 포함되어 있는 것이 흔한 원인 중 하나입니다. 제가 겪은 문제도 엑셀 파일에서 CSV로 가져온 데이터에 원치 않는 개행 문자가 포함되어 발생한 문제였습니다. JSON 데이터는 JSON 검사기를 통해 확인했을 때 완벽해 보였는데 AJAX는 계속해서 파싱 오류를 발생시켰습니다. 이로 인해 문제가 JSON 형식 자체가 아니라 데이터베이스에서 가져온 내용에 있다는 것을 깨달았습니다. 문제의 진짜 원인은 데이터베이스에서 SELECT 쿼리를 실행할 때 개행 문자가 포함되어 오는 것이었습니다. 눈에 보이지 않는 이 문자들이 JSON..