[hatelove님의 JBBS 알고리즘 강좌 9]
작성자 : 김영철
등록날짜 : 2009.01.14 22:41
1,069
결합인덱스의 개념 & 인덱스 컬럼 선정시 유의점을 알아봅시다...
[ 작성자 : hatelove | 등록일 : 2001년 07월 05일 | 조회 : 824 ]
[ 이메일 : love at zeezon.net ]
안녕하세요...
오늘은 단일 인덱스를 응용한 결합인덱스의 개념에 대해서 알아봅시다...
결합인덱스란 용어가 정확히 맞는 말인지는 모르겠습니다...
사실 그냥 붙여본 이름인데... 따지는 사람들이 없어서 맞나부다 생각중입니다...
혹시 정확한 용어를 아시는 분은 아래 의견란을 이용해서 좀 가르쳐 주세요...
인덱스의 개념이 아직도 안잡히신 분들은 첨부터 100번씩만 읽어보시기 바랍니다...
인덱스는 결코 어려운 개념이 아니니까요...
결합인덱스는 왜 필요할까요?
대부분의 자료는 유일하지 않다는 것 때문입니다...
지금은 그렇지 않았지만...
옛날 천하장사 씨름은 비겼을 경우에 몸무게가 덜 나가는 사람이 이겼습니다...
이름순으로 출석부를 만들때.. 같은 이름이 있다면 생일이 빠른 사람이 앞번호가 된다든지...
생일까지도 같을땐... 성격이 좋은 사람(? 이것은 기준이 될 수 없지만)이 앞번호가 된다든지...
이렇듯... 혹시 있을 수도 있는 같은 값의 데이터에도 순서를 주기 위해서 결합인덱스는 필요합니다...
결합인덱스는 1순위 2순위 3순위... 순으로 결합적으로 생성합니다...
만약 다음과 같은 자료가 있다고 봅시다...
이름 | 키 | 몸무게
a | 123 | 100
b | 125 | 33
c | 192 | 187
c | 123 | 56
c | 192 | 12
d | 178 | 63
d | 179 | 56
e | 183 | 77
이름순으로 정렬을 하고 싶습니다...
a 다음 b 다음 c
그런데 c라는 이름을 가진 사람이 3명이 됩니다...
따라서 이름만을 가지고 순서를 정하는 것은 먼가 허전한 느낌이 듭니다...
################## 참고 ######################################################################
order by ASC 의 정렬에서 만약 동일 순서값을 가지고 있다면 입력순에 의해서 정렬이 됩니다..
order by DESC 의 정렬에서는 반대가 되겠죠... 이건 대단히 중요한 문제입니다...
앞으로 유용하게 쓰일 것이니까요...
즉, 인덱스로 잡아주지 않더라도 젤 마지막 순위의 인덱스는
자료 등록시간이라는 것이지요...
이걸 이용하면 JBBS에서처럼 사용 아스키코드 수 253개를 무시하고 제한을 없앨 수 있게 되는 것입니다...
JBBS는 깊이의 제한은 3차 인덱스의 자료의 BYTE수와 동일하지만...
응답글의 수에는 제한이 없습니다... 앞으로 더 자세하게 공부합니다...
##############################################################################################
물론... 자료가 등록된 순서로 항상 정확히 정렬되기에 큰 문제는 없지만...
나름대로의 기준을 가지고 싶습니다....
c만 추려서 다시 써보죠....
c | 192 | 187
c | 123 | 56
c | 192 | 12
이렇게 1차 인덱스의 값이 같을때 두번째 순서의 기준을 잡아줄 수 있습니다...
여기서는 키로 할수 있겠죠... 키순을 2차로 정렬하게 됩니다...
결합인덱스 (1순위:이름, 2순위:키)
그럼 c | 123 | 56 이 가장 최초의 순번을 가지겠네요....
다음 두사람의 키가 같네요?
역시 등록순으로 자동 정렬이 되지만... 경우에 따라서....
결합인덱스 (1순위:이름, 2순위:키, 3순위:몸무게)처럼 생성해 줄수도 있습니다...
예전의 MYSQL에서는 15개 까지의 결합인덱스를 잡을수 있다라도 들은 것 같은데...
최신버전에서는 어떤지 잘 모르겠네요... 한번 알아보시고 아래 의견란에 적어주심 고맙죠...
자... 인덱스의 개념... 생성... 사용... 결합인덱스의 개념을 꼭 이해하시고 넘어가시기 바랍니다...
그럼 경험상 알게된 인덱스 컬럼 선정시의 유의점을 알아보는 것으로 오늘은 마무리를 하겠습니다...
1. 꼭 필요한 컬럼만 인덱스로 생성하라....
#########################################
구두회사의 예를 들때를 생각하시면 됩니다...
쓰일 일이 없는 것까지 인덱스로 생성하면 안됩니다...
인덱스는 출력을 빠르게 하지만 저장공간을 많이 차지하고..
입력시 부하가 가중됩니다...
데이터 베이스 설계당시 모든 상황을 고려해서...
최적화된 컬럼만을 산정하여 인덱스로 생성해야 합니다...
2. 최대로우수를 예측하라...
############################
항상 인덱스로 생성해야 한다는 압박감은 좋지 않습니다...
동아리 회원관리에서 최대회원수가 100명인데 인덱스를 생성할 필요는 없겠죠?
나만의 개인홈페이지에 쓰일 게시판
일년에 글이 100개가 올라오지도 않는 게시판을 위하여
데이터베이스 설계를 할때 굳이 인덱스를 생성할 필요는 없겠죠...
불특정 대다수를 위한 프로그램이 아니라...
특수 목적의 최대로우수를 예측할 수 있는 프로그램 설계시에...
과연 인덱스 생성이 얼마나 도움을 주는가를 먼저 고려해야 합니다...
3. 인덱스 컬럼의 자료형은 최대한 작게하라...
#############################################
초기에 데이터베이스의 자료형(문자형, 수치형)을 설명할때를 상기하면...
자료형은 작을 수록 좋다는 것을 아실겁니다...
만약에 월을 입력하는 컬럼을 인덱스로 생성할때는...
tinyint(1Byte)만으로도 충분하다는 거죠...
만약 남자와 여자를 저장하는 컬럼을 만들때...
남자를 m 으로 여자를 w로 기호화 한다면... char(1) 만으로도 충분하다는 얘기입니다...
또 한걸음 더 발전한다면 enum으로 선언하면 더 빠르죠...
enum은 내부적으로 integer로 처리하므로 검색이 빨라 집니다...
수치형과 문자형에서 수치형이 유리하다는 것은 이제 아실 겁니다...
따라서 남자를 1, 여자를 2 처럼 수치화 할 경우에는
tinyint만으로도 가능합니다...
tinyint로 분류를 다룬다면.... 256가지의 경우를 1Byte만으로 가능하다는 얘기죠...
JBBS에서 분류는 tinyint로 처리합니다....
분류=array("자유마당","토론마당","유머마당","홍보마당","기타마당"); 로 미리 선언해놓고
tinyint로 선언한 분류 컬럼에 0,1,2,3,4 식으로만 넣으면 되죠...
만약 분류 컬럼에 자유마당... 등등을 다 담으려면 문자형의 여러바이트가 필요합니다...
4. 인덱스 컬럼은 항상 not null로 선언하라
#########################################
null은 값이 정해져 있지 않음입니다.. 값이 없음이 아니라는 건 저번에 언급한 적이 있습니다...
not null로 선언하면 값이 정해져 있지 않은 컬럼이 없으므로 모든 컬럼이 비교대상이 됩니다...
따라서 비교대상이 될수없는 null컬럼을 찾는 연산이 한번 줄겠죠... 빠릅니다...
물론 1비트만큼 절약되구요...
따라서 인덱스 컬럼 뿐만이 아니라 대부분의 컬럼을 설계할때 not null과 default값을 정해주는게 좋습니다..
물론 3.22버전까지는 null컬럼은 아예 인덱스 생성을 할 수가 없습니다...
하지만 3.23버전에서는 가능합니다만...
생성이 가능하다고 하는 것 보다는 꼭 not null로 선언하는 습관을 가지는 것이 좋습니다...
5. 가변형(varchar)보다는 고정형(char)를 사용하고 테이블을 분리 조인하라
#######################################################################
가변형이 고정형자료타입보다 잇점을 주는 것은 딱 한가지 입니다...
물리적 저장공간을 덜 차지한다는 것이죠...
요즘은 물리적 저장매체의 비용이 많이 감소했으므로 큰 이득도 아닙니다...
고정형은 테이터가 안정적이며... 입력, 수정, 삭제, 검색 등 거의 모든 부분에서
가변형보다 빠릅니다...
최대로우수가 얼마 되지 않는다면 그 속도의 차이를 느낄수 없지만...
자료가 쌓이면 쌓일수록 더욱 안정적이며 빠릅니다...
하지만 아쉽게도 하나의 테이블에 하나의 가변형타입만 있더라도...
그 테이블은 가변형 테이블이 되어 버립니다...
따라서 하나의 가변형 때문에 고정형 타입을 쓸수 없는 것이죠...
또한 text나 blob타입이 하나라도 포함 되어 있으면 더더욱 그렇습니다...
따라서... 고정형타입과 검색, 정렬시에 꼭 필요한 자료를 하나의 고정형 테이블로 만들고
나머지 자료와 가변형... text, blob 등의 자료형은 따로 구성하는 것이 좋습니다...
테이블의 물리적 저장 용량이 커지면 스캔 범위도 넓어지므로 느려집니다...
테이블을 사용용도나 목적에 맞게 분리하고 조인하는 것은 대단히 유용한 방법입니다...
6. 테스트테이블을 생성 가동해보고 분석하여 그 결과를 토대로 설계하라
####################################################################
모든 데이터베이스를 설계하고 실제 운영하다 보면...
잘못 설계된 것을 나중에 발견하게 됩니다...
이미 많은 실제 데이터가 있으므로 다시 설계 후 만든다는 것도 어렵습니다...
이때 많이 쓰게 되는 것이 alter table인데...
alter table는 차선은 되지만 최선은 아닙니다...
어쩔수 없이 alter table를 했을 경우는 꼭... mysqldump를 이용해서 백업받고...
테이블을 삭제후 복구 하시기 바랍니다... 이유는 잘 생각해 보시구요...
따라서 설계후 제작 보다는..
가상설계 ==> 테이터베이스 생성 ==> 가동 ==> 분석 ==> 분석결과를 토대로 재 설계 ==> 실제 제작...
순이 좋습니다...
따라서 테스트 테이블 생성후...
실제 입력이 예측되는 자료를 실제와 같은 상황으로 입력해 봅니다...
그런 후에 분석하여... 잘못 설계된 부분을 찾아냅니다...
잘못 선언된 자료형... 모자라게 선언된 자료형... 너무 넘쳐나는 자료형....
잘못 생성된 인덱스 등을 철저하게 분석하여서...
그 결과를 토대로 재 설계를 하는 것이 좋습니다...
또한 3.23버전이상에서 부터 지원되는 분석도구..
PROCEDURE ANALYSE()를 이용하는 것도 좋습니다...
select * from 테스트테이블 PROCEDURE ANALYSE(); 을 해보면...
각 컬럼의 최대값,최소값,평균값뿐만 아니라... 그 값을 기준으로 생각되는
가장 최적화된 추천 컬럼 타입을 보여줍니다...
위에서 분석한 결과와.. PROCEDURE ANALYSE()의 결과를 토대로 최적화된 데이터베이스를 설계할 수 있습니다..
오늘은 이만 줄이겠습니다.... 다시한번 강조하는데...
인덱스는 개념의 이해가 중요합니다... 개념을 꼭 자기 것으로 만들고 넘어가기 바랍니다...
다음 시간부터는 그 개념을 이용해서... 실제로 JBBS의 알고리즘에 접근해 보겠습니다...
그리고 그것이 끝나면...
처음에 언급했던...
이상적인 데이터베이스를 현실 웹프로그램에 어떻게 적용할까를 같이 생각해 보겠습니다...
사실 JBBS는 테스트용으로 만든 것이고...
실제 웹 프로그램에서는 이상적인 데이터베이스 모델을 적용하는 것이 더 좋을 듯 합니다...
오늘 행복한고 활기차고 기억에 남는 그런 하루가 되십시요... 담에 봐용... 빠잇~~~~~~~~~~~~~~~~~~~~
기타 의견 있으시면 알려주세요! 공유합시다!
[ 이름 : 프쉬케^^ | 작성일 : 2001-07-06 ]
결합인덱스가 compound key?
복합속성기본키라고하는
compound key 말하는건가요?
[ 이름 : 꼭지 | 작성일 : 2001-07-07 ]
결합인덱스 -> 복합 색인(Composite Index)
영한 사전참조:
-----------------------------------------
composite [kempzit｜kmpez-]
adj.
1 각종 요소[부분]로 된[이루어진], 합성[혼성, 복합]의. ∼ authorship (여러 사람의) 합동 저작, 합작.
4 [數] 합성 함수의, 합성수의.
n.
1 합성[복합, 혼합]물; 합성화(畵), 합성 사진.
------------------------------
한 컬럼에만 색인(Index)을 만든것을 단일 컬럼 색인이라 하고, 둘 이상의 컬럼에 색인을 만드는 것을 복합 컬럼 색인 또는 복합 색인(Composite Index)라고 합니다.
흥수형, 좋은 강좌 ~~~!!
[ 이름 : 손님 | 작성일 : 2001-07-07 ]
복합인덱스 MySQL에 명시된 단어는 --> multiple index column
훔.. 암튼 복합색인 이란 말두 맞긴하지만 검색해보면
MySQL에 써잇는건 저걸루 써있네염
[ 작성자 : hatelove | 등록일 : 2001년 07월 05일 | 조회 : 824 ]
[ 이메일 : love at zeezon.net ]
안녕하세요...
오늘은 단일 인덱스를 응용한 결합인덱스의 개념에 대해서 알아봅시다...
결합인덱스란 용어가 정확히 맞는 말인지는 모르겠습니다...
사실 그냥 붙여본 이름인데... 따지는 사람들이 없어서 맞나부다 생각중입니다...
혹시 정확한 용어를 아시는 분은 아래 의견란을 이용해서 좀 가르쳐 주세요...
인덱스의 개념이 아직도 안잡히신 분들은 첨부터 100번씩만 읽어보시기 바랍니다...
인덱스는 결코 어려운 개념이 아니니까요...
결합인덱스는 왜 필요할까요?
대부분의 자료는 유일하지 않다는 것 때문입니다...
지금은 그렇지 않았지만...
옛날 천하장사 씨름은 비겼을 경우에 몸무게가 덜 나가는 사람이 이겼습니다...
이름순으로 출석부를 만들때.. 같은 이름이 있다면 생일이 빠른 사람이 앞번호가 된다든지...
생일까지도 같을땐... 성격이 좋은 사람(? 이것은 기준이 될 수 없지만)이 앞번호가 된다든지...
이렇듯... 혹시 있을 수도 있는 같은 값의 데이터에도 순서를 주기 위해서 결합인덱스는 필요합니다...
결합인덱스는 1순위 2순위 3순위... 순으로 결합적으로 생성합니다...
만약 다음과 같은 자료가 있다고 봅시다...
이름 | 키 | 몸무게
a | 123 | 100
b | 125 | 33
c | 192 | 187
c | 123 | 56
c | 192 | 12
d | 178 | 63
d | 179 | 56
e | 183 | 77
이름순으로 정렬을 하고 싶습니다...
a 다음 b 다음 c
그런데 c라는 이름을 가진 사람이 3명이 됩니다...
따라서 이름만을 가지고 순서를 정하는 것은 먼가 허전한 느낌이 듭니다...
################## 참고 ######################################################################
order by ASC 의 정렬에서 만약 동일 순서값을 가지고 있다면 입력순에 의해서 정렬이 됩니다..
order by DESC 의 정렬에서는 반대가 되겠죠... 이건 대단히 중요한 문제입니다...
앞으로 유용하게 쓰일 것이니까요...
즉, 인덱스로 잡아주지 않더라도 젤 마지막 순위의 인덱스는
자료 등록시간이라는 것이지요...
이걸 이용하면 JBBS에서처럼 사용 아스키코드 수 253개를 무시하고 제한을 없앨 수 있게 되는 것입니다...
JBBS는 깊이의 제한은 3차 인덱스의 자료의 BYTE수와 동일하지만...
응답글의 수에는 제한이 없습니다... 앞으로 더 자세하게 공부합니다...
##############################################################################################
물론... 자료가 등록된 순서로 항상 정확히 정렬되기에 큰 문제는 없지만...
나름대로의 기준을 가지고 싶습니다....
c만 추려서 다시 써보죠....
c | 192 | 187
c | 123 | 56
c | 192 | 12
이렇게 1차 인덱스의 값이 같을때 두번째 순서의 기준을 잡아줄 수 있습니다...
여기서는 키로 할수 있겠죠... 키순을 2차로 정렬하게 됩니다...
결합인덱스 (1순위:이름, 2순위:키)
그럼 c | 123 | 56 이 가장 최초의 순번을 가지겠네요....
다음 두사람의 키가 같네요?
역시 등록순으로 자동 정렬이 되지만... 경우에 따라서....
결합인덱스 (1순위:이름, 2순위:키, 3순위:몸무게)처럼 생성해 줄수도 있습니다...
예전의 MYSQL에서는 15개 까지의 결합인덱스를 잡을수 있다라도 들은 것 같은데...
최신버전에서는 어떤지 잘 모르겠네요... 한번 알아보시고 아래 의견란에 적어주심 고맙죠...
자... 인덱스의 개념... 생성... 사용... 결합인덱스의 개념을 꼭 이해하시고 넘어가시기 바랍니다...
그럼 경험상 알게된 인덱스 컬럼 선정시의 유의점을 알아보는 것으로 오늘은 마무리를 하겠습니다...
1. 꼭 필요한 컬럼만 인덱스로 생성하라....
#########################################
구두회사의 예를 들때를 생각하시면 됩니다...
쓰일 일이 없는 것까지 인덱스로 생성하면 안됩니다...
인덱스는 출력을 빠르게 하지만 저장공간을 많이 차지하고..
입력시 부하가 가중됩니다...
데이터 베이스 설계당시 모든 상황을 고려해서...
최적화된 컬럼만을 산정하여 인덱스로 생성해야 합니다...
2. 최대로우수를 예측하라...
############################
항상 인덱스로 생성해야 한다는 압박감은 좋지 않습니다...
동아리 회원관리에서 최대회원수가 100명인데 인덱스를 생성할 필요는 없겠죠?
나만의 개인홈페이지에 쓰일 게시판
일년에 글이 100개가 올라오지도 않는 게시판을 위하여
데이터베이스 설계를 할때 굳이 인덱스를 생성할 필요는 없겠죠...
불특정 대다수를 위한 프로그램이 아니라...
특수 목적의 최대로우수를 예측할 수 있는 프로그램 설계시에...
과연 인덱스 생성이 얼마나 도움을 주는가를 먼저 고려해야 합니다...
3. 인덱스 컬럼의 자료형은 최대한 작게하라...
#############################################
초기에 데이터베이스의 자료형(문자형, 수치형)을 설명할때를 상기하면...
자료형은 작을 수록 좋다는 것을 아실겁니다...
만약에 월을 입력하는 컬럼을 인덱스로 생성할때는...
tinyint(1Byte)만으로도 충분하다는 거죠...
만약 남자와 여자를 저장하는 컬럼을 만들때...
남자를 m 으로 여자를 w로 기호화 한다면... char(1) 만으로도 충분하다는 얘기입니다...
또 한걸음 더 발전한다면 enum으로 선언하면 더 빠르죠...
enum은 내부적으로 integer로 처리하므로 검색이 빨라 집니다...
수치형과 문자형에서 수치형이 유리하다는 것은 이제 아실 겁니다...
따라서 남자를 1, 여자를 2 처럼 수치화 할 경우에는
tinyint만으로도 가능합니다...
tinyint로 분류를 다룬다면.... 256가지의 경우를 1Byte만으로 가능하다는 얘기죠...
JBBS에서 분류는 tinyint로 처리합니다....
분류=array("자유마당","토론마당","유머마당","홍보마당","기타마당"); 로 미리 선언해놓고
tinyint로 선언한 분류 컬럼에 0,1,2,3,4 식으로만 넣으면 되죠...
만약 분류 컬럼에 자유마당... 등등을 다 담으려면 문자형의 여러바이트가 필요합니다...
4. 인덱스 컬럼은 항상 not null로 선언하라
#########################################
null은 값이 정해져 있지 않음입니다.. 값이 없음이 아니라는 건 저번에 언급한 적이 있습니다...
not null로 선언하면 값이 정해져 있지 않은 컬럼이 없으므로 모든 컬럼이 비교대상이 됩니다...
따라서 비교대상이 될수없는 null컬럼을 찾는 연산이 한번 줄겠죠... 빠릅니다...
물론 1비트만큼 절약되구요...
따라서 인덱스 컬럼 뿐만이 아니라 대부분의 컬럼을 설계할때 not null과 default값을 정해주는게 좋습니다..
물론 3.22버전까지는 null컬럼은 아예 인덱스 생성을 할 수가 없습니다...
하지만 3.23버전에서는 가능합니다만...
생성이 가능하다고 하는 것 보다는 꼭 not null로 선언하는 습관을 가지는 것이 좋습니다...
5. 가변형(varchar)보다는 고정형(char)를 사용하고 테이블을 분리 조인하라
#######################################################################
가변형이 고정형자료타입보다 잇점을 주는 것은 딱 한가지 입니다...
물리적 저장공간을 덜 차지한다는 것이죠...
요즘은 물리적 저장매체의 비용이 많이 감소했으므로 큰 이득도 아닙니다...
고정형은 테이터가 안정적이며... 입력, 수정, 삭제, 검색 등 거의 모든 부분에서
가변형보다 빠릅니다...
최대로우수가 얼마 되지 않는다면 그 속도의 차이를 느낄수 없지만...
자료가 쌓이면 쌓일수록 더욱 안정적이며 빠릅니다...
하지만 아쉽게도 하나의 테이블에 하나의 가변형타입만 있더라도...
그 테이블은 가변형 테이블이 되어 버립니다...
따라서 하나의 가변형 때문에 고정형 타입을 쓸수 없는 것이죠...
또한 text나 blob타입이 하나라도 포함 되어 있으면 더더욱 그렇습니다...
따라서... 고정형타입과 검색, 정렬시에 꼭 필요한 자료를 하나의 고정형 테이블로 만들고
나머지 자료와 가변형... text, blob 등의 자료형은 따로 구성하는 것이 좋습니다...
테이블의 물리적 저장 용량이 커지면 스캔 범위도 넓어지므로 느려집니다...
테이블을 사용용도나 목적에 맞게 분리하고 조인하는 것은 대단히 유용한 방법입니다...
6. 테스트테이블을 생성 가동해보고 분석하여 그 결과를 토대로 설계하라
####################################################################
모든 데이터베이스를 설계하고 실제 운영하다 보면...
잘못 설계된 것을 나중에 발견하게 됩니다...
이미 많은 실제 데이터가 있으므로 다시 설계 후 만든다는 것도 어렵습니다...
이때 많이 쓰게 되는 것이 alter table인데...
alter table는 차선은 되지만 최선은 아닙니다...
어쩔수 없이 alter table를 했을 경우는 꼭... mysqldump를 이용해서 백업받고...
테이블을 삭제후 복구 하시기 바랍니다... 이유는 잘 생각해 보시구요...
따라서 설계후 제작 보다는..
가상설계 ==> 테이터베이스 생성 ==> 가동 ==> 분석 ==> 분석결과를 토대로 재 설계 ==> 실제 제작...
순이 좋습니다...
따라서 테스트 테이블 생성후...
실제 입력이 예측되는 자료를 실제와 같은 상황으로 입력해 봅니다...
그런 후에 분석하여... 잘못 설계된 부분을 찾아냅니다...
잘못 선언된 자료형... 모자라게 선언된 자료형... 너무 넘쳐나는 자료형....
잘못 생성된 인덱스 등을 철저하게 분석하여서...
그 결과를 토대로 재 설계를 하는 것이 좋습니다...
또한 3.23버전이상에서 부터 지원되는 분석도구..
PROCEDURE ANALYSE()를 이용하는 것도 좋습니다...
select * from 테스트테이블 PROCEDURE ANALYSE(); 을 해보면...
각 컬럼의 최대값,최소값,평균값뿐만 아니라... 그 값을 기준으로 생각되는
가장 최적화된 추천 컬럼 타입을 보여줍니다...
위에서 분석한 결과와.. PROCEDURE ANALYSE()의 결과를 토대로 최적화된 데이터베이스를 설계할 수 있습니다..
오늘은 이만 줄이겠습니다.... 다시한번 강조하는데...
인덱스는 개념의 이해가 중요합니다... 개념을 꼭 자기 것으로 만들고 넘어가기 바랍니다...
다음 시간부터는 그 개념을 이용해서... 실제로 JBBS의 알고리즘에 접근해 보겠습니다...
그리고 그것이 끝나면...
처음에 언급했던...
이상적인 데이터베이스를 현실 웹프로그램에 어떻게 적용할까를 같이 생각해 보겠습니다...
사실 JBBS는 테스트용으로 만든 것이고...
실제 웹 프로그램에서는 이상적인 데이터베이스 모델을 적용하는 것이 더 좋을 듯 합니다...
오늘 행복한고 활기차고 기억에 남는 그런 하루가 되십시요... 담에 봐용... 빠잇~~~~~~~~~~~~~~~~~~~~
기타 의견 있으시면 알려주세요! 공유합시다!
[ 이름 : 프쉬케^^ | 작성일 : 2001-07-06 ]
결합인덱스가 compound key?
복합속성기본키라고하는
compound key 말하는건가요?
[ 이름 : 꼭지 | 작성일 : 2001-07-07 ]
결합인덱스 -> 복합 색인(Composite Index)
영한 사전참조:
-----------------------------------------
composite [kempzit｜kmpez-]
adj.
1 각종 요소[부분]로 된[이루어진], 합성[혼성, 복합]의. ∼ authorship (여러 사람의) 합동 저작, 합작.
4 [數] 합성 함수의, 합성수의.
n.
1 합성[복합, 혼합]물; 합성화(畵), 합성 사진.
------------------------------
한 컬럼에만 색인(Index)을 만든것을 단일 컬럼 색인이라 하고, 둘 이상의 컬럼에 색인을 만드는 것을 복합 컬럼 색인 또는 복합 색인(Composite Index)라고 합니다.
흥수형, 좋은 강좌 ~~~!!
[ 이름 : 손님 | 작성일 : 2001-07-07 ]
복합인덱스 MySQL에 명시된 단어는 --> multiple index column
훔.. 암튼 복합색인 이란 말두 맞긴하지만 검색해보면
MySQL에 써잇는건 저걸루 써있네염
"쇼핑몰·홈페이지·오픈마켓
블로그·페이스북·이메일 등의 각종 마케팅 글쓰기, 각종 광고, 영업, 판매, 제안서, 전단지 반응율 3배×10배 이상 높이는 마법의 8단계 공식" |
|
| ☞자세히보기 |
|
|
|
