Eclipse 에서 포커스가 잡혀 있는 파일 업로드시
포커스가 잡힌 파일명을 돌려주는 Arguments
${file_prompt}
2006년 4월 17일 월요일
2006년 4월 4일 화요일
L2,L3,L4
http://cafe.naver.com/yjk017654/221 님의 글을 퍼왔습니다.
L2스위치, L3스위치,L4스위치 |
http://cafe.naver.com/yjk017654/221
예를 들어 A에서 보낸 팻킷이 포트 1로 들어왔다고 합시다.
그러면 L2 스위치는 포트 1에 A가 붙어있다는 정보를 얻게 됩니다.
그래서 나중에 A로 보내져야할 팻킷이 들어오게 되면 포트 1로 내보내게 됩니다.
L3의 경우는 L2와 달리 매우 넓은 범위까지 다루게 됩니다.
그래서 오가는 팻킷을 관찰해서는 충분한 정보를 얻을 수가 없습니다.
그래서 L3 스위치끼리 통신을 하면서 정보를 축적하게 됩니다.
예를 들어 포트 1에 연결되어 있는 스위치가 여기에는 팻킷이 많이 몰린다는
내용을 보낸다면, 그 내용을 받은 스위치는 팻킷을 포트 1 대신 다른 포트로
보내게 됩니다.
L4스위치
여러대의 서버에 똑같은 컨텐츠를 탑재하는 경우는 L4에서 서버의 부하를 체크해서 가장
여유있다고 판단되는 쪽으로 보내게 됩니다.(정책이 여러개 있는데, 이방식을 가장 많이 사용합니다.)
일반 기업에서 ERP서버나 업무용서버를 운영할 때 많이 사용하는 방식입니다.
서버별로 컨텐츠가 다르다면, L4에서 정책을 세워서 해당 서비스에 대한 요청이 오면 등록된 서비스로
보내주어서 전체 부하를 분산시키는 방식을 사용합니다. 대형 포탈의 경우 이런 방식을 사용하겠죠.
그리고 대부분 DB서버는 L4를 거치지 않고 웹서버와 직접 연결시켜서 사용합니다. DB서버 분산하는게 쉽지 않기 때문에 DB를 L4에 물리는 경우는 드물죠.
세그먼트(segment)에 대해 설명드리면, 한 컴퓨터에서 발생한 신호가 수신자에 상관없이 전달되는 범위를 말합니다. 즉, 내 컴퓨터에서 자료를 보내려고 신호를 내보내면 이 신호가 일정 지역내의 모든 컴퓨터에게 전달이 되는데 그 범위를 말합니다. 그런데, 하나의 세그먼트에서는 동시에 2개의 신호가 전달될 수 없습니다. 예를 들면, 두사람이 동시에 자기 얘기만 하면 무슨소린지 모르고 충돌이 발생하듯이 하나의 세그먼트 내에서 동시에 2개 이상의 전기적인 신호가 발생하면 충돌이 발생합니다.
그럼, 여기서 한가지 생각해 보시면, 하나의 세그먼트가 컴퓨터 1000대로 구성이 되어 있다고 보면 1000대중에서 내 컴퓨터가 자료를 보내려고 하면 많은 시간을 기다려야 할 수도 있고, 충돌이 자주 발생할 수도 있습니다. 그래서~ 세그먼트를 분리시키고자 등장한 장비가 브리지(스위치는 브리지를 개량한 장비)입니다.
브리지(bridge)는 한마디로 요약하면 세그먼트를 분리시켜주는 장비입니다. 예를 들면 1000대의 컴퓨터를 100대씩 묶어서 10개의 세그먼트을 만들어 주는 장비 입니다. 이렇게 분리된 세그먼트에서 자료 교환을 중재하는 역할을 브리지가 하게 됩니다.
예를 들어 세그먼트1에 있는 컴퓨터가 세그먼트1에 있는 컴퓨터로(즉, 같은 세그먼트)데이터를 전송하면 이 신호가 다른 세그먼트에 전송이 되지 못하도록 신호를 차단하구요, 세그먼트1에서 세그먼트2로 데이터를 보내면 브리지가 이 신호를 받아서 세그먼트2로 보내줍니다. 이렇게 하면 세그먼트가 분리되어서 컴퓨터끼리 자료 교환하는데에 충돌이나 기다림(병목현상?)이 줄어들겠지요.
이제, 스위치와 라우터에 차이점을 설명 드리면.. 세그먼트를 분리시킨다는 의미에서는 같다고 보시면 됩니다. 차이점은.. 어떤걸 기준으로 분리를 시키느냐 입니다.
스위치에 여러가지 포트(하나의 포트를 하나의 세그먼트로 보셔도 될겁니다.)가 있는데, 각 포트에 어떤 컴퓨터가 연결이 되어 있는지 판단하는 것은 MAC(Media Access Control)주소 입니다. 간단히 말하면 LAN카드 번호 입니다. 이 번호는 공장에서 나올때부터 고유하게 지정된 번호로써 전세게 LAN카드가 다 다른 번호를 가지고 있습니다. 스위치는 이 번호를 가지고 스위치 장비 내부에 '표'를 하나 만들어 놓고, 포트1에는 어떤 MAC주소가 있으며, 포트2에는 어떤 MAC주소가 있는지 적어 놓습니다. 그래서, 이 표를 기준으로, 스위치로 들어오는 신호를 읽어 들여서 같은 포트의 MAC주소를 목적지로 하고 있으면 다른 포트로 데이터를 보내지 않고, 다른 포트의 MAC주소를 목적지 주소로 가지고 있으면 그곳으로 연결 시켜 줍니다.
라우터는 세그먼트를 구분하는 기준이 IP입니다. 라우터도 내부적으로 표를 만들어 놓는데 기준이 IP입니다. 따라서, 라우터로 들어오는 신호를 읽어들여서 목적지가 같은 포트(즉, 같은 세그먼트)의 IP이면 다른 포트로 신호를 보내지 않으며 다른 포트의 세그먼트의 컴퓨터가 목적지 IP이면 그 포트로 연결시켜 주는 역활을 합니다.
라우터의 역할을 보시면 알겠지만, IP를 기준으로 세그먼트를 나눕니다. 그래서, 인터넷과 독립적으로 LAN을 구축할 경우 라우터는 필요 없습니다. 하지만, 인터넷과 연결시켜서 LAN을 구축할 경우 반드시 필요한 장비가 라우터 입니다
L2스위치, L3스위치,L4스위치 |
http://cafe.naver.com/yjk017654/221
예를 들어 A에서 보낸 팻킷이 포트 1로 들어왔다고 합시다.
그러면 L2 스위치는 포트 1에 A가 붙어있다는 정보를 얻게 됩니다.
그래서 나중에 A로 보내져야할 팻킷이 들어오게 되면 포트 1로 내보내게 됩니다.
L3의 경우는 L2와 달리 매우 넓은 범위까지 다루게 됩니다.
그래서 오가는 팻킷을 관찰해서는 충분한 정보를 얻을 수가 없습니다.
그래서 L3 스위치끼리 통신을 하면서 정보를 축적하게 됩니다.
예를 들어 포트 1에 연결되어 있는 스위치가 여기에는 팻킷이 많이 몰린다는
내용을 보낸다면, 그 내용을 받은 스위치는 팻킷을 포트 1 대신 다른 포트로
보내게 됩니다.
L4스위치
여러대의 서버에 똑같은 컨텐츠를 탑재하는 경우는 L4에서 서버의 부하를 체크해서 가장
여유있다고 판단되는 쪽으로 보내게 됩니다.(정책이 여러개 있는데, 이방식을 가장 많이 사용합니다.)
일반 기업에서 ERP서버나 업무용서버를 운영할 때 많이 사용하는 방식입니다.
서버별로 컨텐츠가 다르다면, L4에서 정책을 세워서 해당 서비스에 대한 요청이 오면 등록된 서비스로
보내주어서 전체 부하를 분산시키는 방식을 사용합니다. 대형 포탈의 경우 이런 방식을 사용하겠죠.
그리고 대부분 DB서버는 L4를 거치지 않고 웹서버와 직접 연결시켜서 사용합니다. DB서버 분산하는게 쉽지 않기 때문에 DB를 L4에 물리는 경우는 드물죠.
세그먼트(segment)에 대해 설명드리면, 한 컴퓨터에서 발생한 신호가 수신자에 상관없이 전달되는 범위를 말합니다. 즉, 내 컴퓨터에서 자료를 보내려고 신호를 내보내면 이 신호가 일정 지역내의 모든 컴퓨터에게 전달이 되는데 그 범위를 말합니다. 그런데, 하나의 세그먼트에서는 동시에 2개의 신호가 전달될 수 없습니다. 예를 들면, 두사람이 동시에 자기 얘기만 하면 무슨소린지 모르고 충돌이 발생하듯이 하나의 세그먼트 내에서 동시에 2개 이상의 전기적인 신호가 발생하면 충돌이 발생합니다.
그럼, 여기서 한가지 생각해 보시면, 하나의 세그먼트가 컴퓨터 1000대로 구성이 되어 있다고 보면 1000대중에서 내 컴퓨터가 자료를 보내려고 하면 많은 시간을 기다려야 할 수도 있고, 충돌이 자주 발생할 수도 있습니다. 그래서~ 세그먼트를 분리시키고자 등장한 장비가 브리지(스위치는 브리지를 개량한 장비)입니다.
브리지(bridge)는 한마디로 요약하면 세그먼트를 분리시켜주는 장비입니다. 예를 들면 1000대의 컴퓨터를 100대씩 묶어서 10개의 세그먼트을 만들어 주는 장비 입니다. 이렇게 분리된 세그먼트에서 자료 교환을 중재하는 역할을 브리지가 하게 됩니다.
예를 들어 세그먼트1에 있는 컴퓨터가 세그먼트1에 있는 컴퓨터로(즉, 같은 세그먼트)데이터를 전송하면 이 신호가 다른 세그먼트에 전송이 되지 못하도록 신호를 차단하구요, 세그먼트1에서 세그먼트2로 데이터를 보내면 브리지가 이 신호를 받아서 세그먼트2로 보내줍니다. 이렇게 하면 세그먼트가 분리되어서 컴퓨터끼리 자료 교환하는데에 충돌이나 기다림(병목현상?)이 줄어들겠지요.
이제, 스위치와 라우터에 차이점을 설명 드리면.. 세그먼트를 분리시킨다는 의미에서는 같다고 보시면 됩니다. 차이점은.. 어떤걸 기준으로 분리를 시키느냐 입니다.
스위치에 여러가지 포트(하나의 포트를 하나의 세그먼트로 보셔도 될겁니다.)가 있는데, 각 포트에 어떤 컴퓨터가 연결이 되어 있는지 판단하는 것은 MAC(Media Access Control)주소 입니다. 간단히 말하면 LAN카드 번호 입니다. 이 번호는 공장에서 나올때부터 고유하게 지정된 번호로써 전세게 LAN카드가 다 다른 번호를 가지고 있습니다. 스위치는 이 번호를 가지고 스위치 장비 내부에 '표'를 하나 만들어 놓고, 포트1에는 어떤 MAC주소가 있으며, 포트2에는 어떤 MAC주소가 있는지 적어 놓습니다. 그래서, 이 표를 기준으로, 스위치로 들어오는 신호를 읽어 들여서 같은 포트의 MAC주소를 목적지로 하고 있으면 다른 포트로 데이터를 보내지 않고, 다른 포트의 MAC주소를 목적지 주소로 가지고 있으면 그곳으로 연결 시켜 줍니다.
라우터는 세그먼트를 구분하는 기준이 IP입니다. 라우터도 내부적으로 표를 만들어 놓는데 기준이 IP입니다. 따라서, 라우터로 들어오는 신호를 읽어들여서 목적지가 같은 포트(즉, 같은 세그먼트)의 IP이면 다른 포트로 신호를 보내지 않으며 다른 포트의 세그먼트의 컴퓨터가 목적지 IP이면 그 포트로 연결시켜 주는 역활을 합니다.
라우터의 역할을 보시면 알겠지만, IP를 기준으로 세그먼트를 나눕니다. 그래서, 인터넷과 독립적으로 LAN을 구축할 경우 라우터는 필요 없습니다. 하지만, 인터넷과 연결시켜서 LAN을 구축할 경우 반드시 필요한 장비가 라우터 입니다
2006년 3월 22일 수요일
REF CURSOR
http://www.atmarkit.co.jp/fdb/rensai/odpdotnet01/odpdotnet04.html
REF CURSOR
REF CURSORは、OracleDataReader、DataSetまたはOracleRefCursorとして取得できます。OracleRefCursorオブジェクトとして取得されたREF CURSORは、OracleDataReaderの作成またはREF CURSORからDataSetへの移入に使用できます。REF CURSORにアクセスする際は、必ずOracleDbType.RefCursorとしてバインドします。以下にストアドプロシージャからREF CURSORを取得する方法、および DataGridオブジェクトに情報を表示する方法を説明します。
REF CURSORを使用したパッケージの作成
CREATE OR REPLACE PACKAGE SCOTT.pkg_ref AS
CURSOR c1 IS SELECT * FROM emp;
CURSOR c2 IS SELECT * FROM dept;
TYPE empCur IS REF CURSOR RETURN c1%ROWTYPE;
TYPE deptCur IS REF CURSOR RETURN c2%ROWTYPE;
PROCEDURE GetEmpDeptData(
EmpCursor in out empCur,
DeptCursor in out deptCur
);
END;
リスト18 REF CURSORを使用したパッケージ
CREATE OR REPLACE PACKAGE BODY SCOTT.pkg_ref AS
PROCEDURE GetEmpDeptData(
EmpCursor in out empCur,
DeptCursor in out deptCur) IS
BEGIN
OPEN EmpCursor FOR SELECT * FROM emp;
OPEN DeptCursor FOR SELECT * FROM dept;
END GetEmpDeptData;
END pkg_ref;
リスト19 REF CURSORを使用したパッケージ本体
ストアドプロシージャからREF CURSORを取得しDataGridオブジェクトに結果を表示するコードは以下のようになります。
Dim cmd As New OracleCommand("pkg_ref.GetEmpDeptData", cnn)
cmd.CommandType = CommandType.StoredProcedure
'REF CURSORパラメータのバインド
cmd.Parameters.Add("EmpCursor", _
OracleDbType.RefCursor, ParameterDirection.Output)
cmd.Parameters.Add("DeptCursor", _
OracleDbType.RefCursor, ParameterDirection.Output)
'SQL文の実行とRef Cursorの使用
Dim dsData As New DataSet
Dim da As New OracleDataAdapter(cmd)
da.Fill(dsData, "data")
'DataGridへ表示
DataGridEmp.SetDataBinding(dsData, "data")
DataGridDept.SetDataBinding(dsData, "data1")
リスト20 REF CURSORを取得しDataGridオブジェクトに結果を表示（VB.NET）
OracleCommand cmd =
new OracleCommand("pkg_ref.GetEmpDeptData", cnn);
cmd.CommandType = CommandType.StoredProcedure;
//REF CURSORパラメータのバインド
cmd.Parameters.Add("EmpCursor",
OracleDbType.RefCursor, ParameterDirection.Output);
cmd.Parameters.Add("DeptCursor",
OracleDbType.RefCursor, ParameterDirection.Output);
//SQL文の実行とRef Cursorの使用
DataSet dsData = new DataSet();
OracleDataAdapter da = new OracleDataAdapter(cmd);
da.Fill(dsData, "data");
//DataGridへ表示
dataGridEmp.SetDataBinding(dsData, "data");
dataGridDept.SetDataBinding(dsData, "data1");
リスト21 REF CURSORを取得しDataGridオブジェクトに結果を表示（C#）
上記のサンプルコードでは、REF CURSORからDataSetへデータを格納していますが、OracleRefCursorオブジェクトからOracleDataReaderオブジェクトへ格納することも可能です。
Dim cmd As New OracleCommand("pkg_ref.GetEmpDeptData", cnn)
cmd.CommandType = CommandType.StoredProcedure
'REF CURSORパラメータのバインド
cmd.Parameters.Add("EmpCursor", OracleDbType.RefCursor, _
ParameterDirection.Output)
cmd.Parameters.Add("DeptCursor", OracleDbType.RefCursor, _
ParameterDirection.Output)
cmd.ExecuteNonQuery()
'SQL文の実行とREF CURSORの使用
Dim dr1 As OracleDataReader = _
CType(cmd.Parameters(0).Value, OracleRefCursor).GetDataReader
Dim dr2 As OracleDataReader = _
CType(cmd.Parameters(1).Value, OracleRefCursor).GetDataReader
リスト22 REF CURSORを取得しOracleDataReaderへ結果を格納（VB.NET）
OracleCommand cmd =
new OracleCommand("pkg_ref.GetEmpDeptData", cnn);
cmd.CommandType = CommandType.StoredProcedure;
//REF CURSORパラメータのバインド
cmd.Parameters.Add("EmpCursor", OracleDbType.RefCursor,
ParameterDirection.Output);
cmd.Parameters.Add("DeptCursor", OracleDbType.RefCursor,
ParameterDirection.Output);
cmd.ExecuteNonQuery();
//SQL文の実行とREF CURSORの使用
OracleRefCursor cur1 =
(OracleRefCursor)cmd.Parameters[0].Value;
OracleRefCursor cur2 =
(OracleRefCursor)cmd.Parameters[1].Value;
OracleDataReader dr1 = cur1.GetDataReader();
OracleDataReader dr2 = cur2.GetDataReader();
リスト23 REF CURSORを取得しOracleDataReaderへ結果を格納（C#）
REF CURSOR
REF CURSORは、OracleDataReader、DataSetまたはOracleRefCursorとして取得できます。OracleRefCursorオブジェクトとして取得されたREF CURSORは、OracleDataReaderの作成またはREF CURSORからDataSetへの移入に使用できます。REF CURSORにアクセスする際は、必ずOracleDbType.RefCursorとしてバインドします。以下にストアドプロシージャからREF CURSORを取得する方法、および DataGridオブジェクトに情報を表示する方法を説明します。
REF CURSORを使用したパッケージの作成
CREATE OR REPLACE PACKAGE SCOTT.pkg_ref AS
CURSOR c1 IS SELECT * FROM emp;
CURSOR c2 IS SELECT * FROM dept;
TYPE empCur IS REF CURSOR RETURN c1%ROWTYPE;
TYPE deptCur IS REF CURSOR RETURN c2%ROWTYPE;
PROCEDURE GetEmpDeptData(
EmpCursor in out empCur,
DeptCursor in out deptCur
);
END;
リスト18 REF CURSORを使用したパッケージ
CREATE OR REPLACE PACKAGE BODY SCOTT.pkg_ref AS
PROCEDURE GetEmpDeptData(
EmpCursor in out empCur,
DeptCursor in out deptCur) IS
BEGIN
OPEN EmpCursor FOR SELECT * FROM emp;
OPEN DeptCursor FOR SELECT * FROM dept;
END GetEmpDeptData;
END pkg_ref;
リスト19 REF CURSORを使用したパッケージ本体
ストアドプロシージャからREF CURSORを取得しDataGridオブジェクトに結果を表示するコードは以下のようになります。
Dim cmd As New OracleCommand("pkg_ref.GetEmpDeptData", cnn)
cmd.CommandType = CommandType.StoredProcedure
'REF CURSORパラメータのバインド
cmd.Parameters.Add("EmpCursor", _
OracleDbType.RefCursor, ParameterDirection.Output)
cmd.Parameters.Add("DeptCursor", _
OracleDbType.RefCursor, ParameterDirection.Output)
'SQL文の実行とRef Cursorの使用
Dim dsData As New DataSet
Dim da As New OracleDataAdapter(cmd)
da.Fill(dsData, "data")
'DataGridへ表示
DataGridEmp.SetDataBinding(dsData, "data")
DataGridDept.SetDataBinding(dsData, "data1")
リスト20 REF CURSORを取得しDataGridオブジェクトに結果を表示（VB.NET）
OracleCommand cmd =
new OracleCommand("pkg_ref.GetEmpDeptData", cnn);
cmd.CommandType = CommandType.StoredProcedure;
//REF CURSORパラメータのバインド
cmd.Parameters.Add("EmpCursor",
OracleDbType.RefCursor, ParameterDirection.Output);
cmd.Parameters.Add("DeptCursor",
OracleDbType.RefCursor, ParameterDirection.Output);
//SQL文の実行とRef Cursorの使用
DataSet dsData = new DataSet();
OracleDataAdapter da = new OracleDataAdapter(cmd);
da.Fill(dsData, "data");
//DataGridへ表示
dataGridEmp.SetDataBinding(dsData, "data");
dataGridDept.SetDataBinding(dsData, "data1");
リスト21 REF CURSORを取得しDataGridオブジェクトに結果を表示（C#）
上記のサンプルコードでは、REF CURSORからDataSetへデータを格納していますが、OracleRefCursorオブジェクトからOracleDataReaderオブジェクトへ格納することも可能です。
Dim cmd As New OracleCommand("pkg_ref.GetEmpDeptData", cnn)
cmd.CommandType = CommandType.StoredProcedure
'REF CURSORパラメータのバインド
cmd.Parameters.Add("EmpCursor", OracleDbType.RefCursor, _
ParameterDirection.Output)
cmd.Parameters.Add("DeptCursor", OracleDbType.RefCursor, _
ParameterDirection.Output)
cmd.ExecuteNonQuery()
'SQL文の実行とREF CURSORの使用
Dim dr1 As OracleDataReader = _
CType(cmd.Parameters(0).Value, OracleRefCursor).GetDataReader
Dim dr2 As OracleDataReader = _
CType(cmd.Parameters(1).Value, OracleRefCursor).GetDataReader
リスト22 REF CURSORを取得しOracleDataReaderへ結果を格納（VB.NET）
OracleCommand cmd =
new OracleCommand("pkg_ref.GetEmpDeptData", cnn);
cmd.CommandType = CommandType.StoredProcedure;
//REF CURSORパラメータのバインド
cmd.Parameters.Add("EmpCursor", OracleDbType.RefCursor,
ParameterDirection.Output);
cmd.Parameters.Add("DeptCursor", OracleDbType.RefCursor,
ParameterDirection.Output);
cmd.ExecuteNonQuery();
//SQL文の実行とREF CURSORの使用
OracleRefCursor cur1 =
(OracleRefCursor)cmd.Parameters[0].Value;
OracleRefCursor cur2 =
(OracleRefCursor)cmd.Parameters[1].Value;
OracleDataReader dr1 = cur1.GetDataReader();
OracleDataReader dr2 = cur2.GetDataReader();
リスト23 REF CURSORを取得しOracleDataReaderへ結果を格納（C#）
2006년 3월 13일 월요일
code generator
http://www.codegeneration.net/
에서 괜찬은 내용 발견.
sql2java는 적용해 보고 있는중.
DB에 PK설정이 없으면 문제가 됨
유니크 키 설정을 PK설정으로 바꿔서 ant실행시 DB에 적용 코드생성
PK삭제
에서 괜찬은 내용 발견.
sql2java는 적용해 보고 있는중.
DB에 PK설정이 없으면 문제가 됨
유니크 키 설정을 PK설정으로 바꿔서 ant실행시 DB에 적용 코드생성
PK삭제
2006년 2월 20일 월요일
UniqueIndex VS PK
오라클's 낙공불락
cafe.naver.com/ocpgroup
님의 자료를 퍼왔습니다.
아주 설명이 잘되있는 걸 찾아서 부연설명해서 올립니다.
참고로 퍼온곳은 www.dbguide.net 이라는 곳인데, 질문답변란에 올리면
엔코아나, 기타 좀 이름있는 DB컨설팅 회사 사람들이 답변을 해줍니다.
메일링 가입하시면 좋은 정보 많이 얻으실겁니다.
유니크인덱스와 PK의 차이점? 조회: 413 2004-03-26
김윤선(covey02)
PK와 유니크 인덱스의 차이점은 뭔가요?
테이블에서 FK를 사용하지 않는다면 유닉스 인덱스 만으로도 가능한데..
굳이 PK를 잡는 이유는 뭔지 알고 싶습니다.
테이블을 대표하는 것을 나타내기위해 PK를 쓴다는 말이 있는데...
이건 유닉스 인덱스로 대치 할 수 없는건가요?
PK와 유니크 인덱스 중 유니크인덱스로만 구성했을때 퍼포먼스가 더 빠르다고 하던데 맞는 말인지 알고 싶습니다. 맞다면 어떻게 해서 더 빠른지두 알고 싶습니다.
유니크인덱스와 PK의 차이점? 2004-03-26
유기연(inyou2)
PK와 유니크 인덱스는 비교 하기엔 좀 무리가 있다고 보는데요
Table 생성시 PK에 자동적으로 유니크 인덱스가 생성 됩니다.
일반적인 유저가 생성하는 인덱스는 유닉스 인덱스로 만들지 않는것이
좋습니다.
만일 PK없이 유저가 유니크 인덱스만 만들었다고 해도 PK를 대신할수는 없습니다.
옵티마이져가 실행계획시 인덱스 안타고 FTS 하면 인덱스는 아무 소용이 없는거죠.
인덱스와 키는 개념 자체가 틀린겁니다.
테이블에서 FK를 사용 하지 않아도 PK는 필요합니다.
이유를 말하자면 모델링 측면에서는 Relational 개념에 부합하는거겠고
Database측면으로 보자면 옵티마이져가
빠른 실행계획을 만드는데 도움이 되겠죠...
굳이 따지자면 PK와 유니크키의 차이점을 물어 보시는듯 하는데요..
큰 차이점은 유니크키는 널 값을 허용 하는 겁니다.
키가 될수 있는 후보 키가 유니크키고 그중 가장 값을 유일하게 구별해 주는 넘을
PK라고 이해하시면 될듯 합니다.
PK없이 유니크인덱스로만 구성했을때 퍼포먼스가 더 빠르냐는 문제점은
당시 테이블의 데이타의 양 및 어떤 분포도를 가지냐에 따라
사례에 따라 천차 만별 달라집니다.
튜닝및 퍼포먼스 문제는 언제나 딱 잘라 절대적으로 말할수 없는 문제죠...
유니크인덱스와 PK의 차이점? 2004-03-26
김인호(yesino)
안녕하세요.. 이노입니다.
궁금해하시는 내용에 대한 답변은 예전 좀 다른 문제로 제가 답변을 올렸던 경우와
유사한 듯 하여 그때 내용을 간략하게 다시 올리겠습니다.
먼저 PK Index와 Unique Index의 차이는 간단하게 Nullable의 차이라고 하겠습니다.
쉽게 말해서 PK Index라는 것은 Unique Index + Not Null을 의미합니다. -> 뒷부분에서 근본적으로 차이가 있다라고 설명합니다.
반대로 Unique Index는 인덱스가 걸리는 필드에 대해서도 Null을 허용하죠.
즉, 특정 테이블의 컬럼에 대해 Unique 인덱스가 있다고 해서, 해당 필드에 Null 값을
Insert 못하지는 않습니다. 하지만, PK Index가 설정되어 있다고 한다면 자동으로
해당 필드에 대한 Not null 제약조건이 생기기 때문에 Null을 insert할 수 없죠.
이러한 이유로 인해, SQL의 경우에 따라서는 Unique Index임에도 불구하고 Table
Access를 하는 예도 있습니다. 해당 값이 Not Null임을 보장하지 못하기 때문이죠.
따라서 SELECT문의 경우 때로는 오히려 Unique보다 PK가 아주 근소한 차이지만 더
빠른 경우도 있습니다. 물론, INSERT의 경우 제약조건에 대한 체크로 인해 조금 더
느릴(?)수도 있겠지요..
실제 테스트를 해봐도, 특정 field의 값에서 max값을 추출하고자 하는데 null이 포함되어 있으면 실제로 index search에서 찾은 값이 null인지 값을 가지고 있는지는 테이블을 뒤져봐야 알 수 있는 정보가 됩니다. -> 그래서 질문할 때 말했던, unique index가 더 빠르다는 것은 경우에 따라서 반대로 primary key 일때 더 빠를 수 있다. 겠네요
그래서 PK Index인 경우에는 (null을 가진 필드가 없음을 보장해주기 때문에..)index 영역안에서 결과 값을 리턴해줄 수 있고, Unique의 경우에는 데이터 영역까지 가서 실제 값을 확인해봐야 하는 결과가 나옵니다.
(이러한 경우도 Analyze나 테이블에 대한 정확한 통계가 있다면 그렇지 않을수도..)
이상 짧은 제 소견이였습니다.
원하시는 답변이 어느 정도 되셨는지 모르겠습니다.
행복한 하루 되시기를~~
유니크인덱스와 PK의 차이점? 2004-03-27
조시형(oraking)
안녕하십니까? 엔코아 정보컨설팅에 근무하는 컨설턴트 조시형입니다.
우선 Primary Key와 Unique Index의 차이점을 설명하는 것은 부적절하다는 말씀을 드리고 싶습니다. 둘간의 상관관계를 설명하는 것이 맞는 개념입니다. 많은 개발자들이 PK는 왠지 부하를 준다는 잘못된 선입견을 가지고 있고 따라서 PK 대신 Unique Index를 사용하는 것으로 알고 있는데 매우 그릇된 관행(?)이라고 생각합니다. 따라서 앞에서 다른 분들이 좋은 설명 많이 해 주셨지만 부연해서 설명을 드리도록 하겠습니다.
Primary Key라고 하는 것은 논리적인 개념입니다. Primary Key는 해당 컬럼이 그 테이블의 식별자임을 나타내는 것으로서, 자신과 다른 레코드가 서로 다른 인스턴스임을 확인할 수 있게 해 주는 역할을 합니다. 즉, 해당 그 레코드의 존재자체인 것이지요.
원래 사람이름이라는 것이 '나'와 다른 사람을 식별하기 위해 사용하는 것인데, 다른 사람과 중복될 수 있으므로 나를 식별할 수 있는 속성으로서 주민등록번호라는 것을 대신 사용합니다. 따라서 주민등록번호는 나와 별개가 아닌 나의 존재 그 자체입니다. 철학적으로는 맞지 않는 설명이겠지만 적어도 ‘데이터의 세계’에서는 그렇습니다.
반면 PK constraint는 물리적인 개념입니다. "이 컬럼(들)은 다른 레코드와 구분짓는 식별자 역할을 하는 중요한 컬럼이므로 데이터는 중복을 허용해서는 안 되고(unique), null값을 허용해서도 안돼(not null)"라고 DB에게 정보를 주는 것입니다. primary key constraint를 설정하면 unique index와 not null constraint가 자동적으로 생성되는 이유도 여기에 있지요. -> 스터디할때 primary key는 논리적인 개념이고 index는 실제로 눈에 보이는 물리적인 것이라고 했는데, 설명을 좀 틀린것 같습니다. Primary Key가 논리적인 개념이며, PK Constraint 와 not null 등의 제약조건과 unique index 들이 물리적인 개념이라고 하는게 맞겠군요.
특히 인덱스는 PK 컬럼의 Unique성을 보장하기 위해 매우 필수적인 도구인데, 만약 인덱스 없이 해당 컬럼값이 중복되지 않도록 할 수 있는 방법을 생각해 보시기 바랍니다. 잘 떠오르지 않을 것입니다. 결론적으로 말씀드리면, 인덱스와 PK의 상관관계에 있어서 Unique이든 Non-Unique이든 Index라는 놈은 PK 컬럼의 Unique성을 보장하기 위해 사용하는 하나의 도구(Tool)에 지나지 않습니다.
어떤 의미에서만 본다면, 어느 한 컬럼에 Not Null Constraint를 주고, 그 컬럼에 Unique Index를 생성하였다면 primary key와 다를 것이 하나도 없어 보입니다.
하지만 primary key는 데이터베이스와 사용자 입장에서 매우 중요한 정보 역할을 하기 때문에 중요하다고 말씀드리고 싶습니다.
앞서 말씀드렸듯이, 원래 primary key는 “이 컬럼(들)이 테이블의 식별자(identifier)이므로 중복을 허용해서는 안 되고, null값을 허용해서도 안 된다”라는 의미론적(semantic) 인 의미에서 정의하는 것이며, DBMS는 이를 효과적으로 처리하기 위해서 index를 자동생성해서 사용하고 not null constraint를 정의하는 것입니다.
참고로 primary key를 위해서 반드시 unique index가 필요한 것은 아닙니다. non-unique index만 있더라도 새로운 값이 들어올 때 중복값이 있는지 체크하는 데에는 전혀 문제가 없으므로 기존에 이미 non-unique 인덱스가 정의되어 있는 상황이었다면 그 인덱스를 그대로 사용합니다. DW 시스템에서 대량의 데이터 로딩시 속도를 빠르게 하기 위해 PK Constraint를 일시적으로 Disable 시키는 경우가 있는데 이렇게 되면 Unique Index도 동시에 제거되므로 인덱스를 다시 생성해야 하는 부담이 생깁니다. 이러한 부담을 덜기 위해 의도적으로 non-unique index를 생성하는 경우가 있는데 이에 대해서는 더 깊이 언급하지 않겠습니다. -> 스터디할때 책에 나왔던 부분입니다. primary constraint key 를 생성하면 자동적으로 unique index가 생기는데, 주의할점은 primary constraint key를 해제할 때 unique index 도 자동적으로 삭제된다, 따라서 연기가능한 제약조건(맞나?) 등을 이용할 수 있다. 라는 부분이었습니다. 그때는 사람이 실수나, 다른 이유로 제약조건을 삭제할 때 인덱스까지 없어지므로 갑자기 느려지는 상황이 올 수 있다. 라고 말을 했었는데요, 그런 경우와 함께 DW 시스템 (OLAP) 에서 데이터 로딩 속도를 빠르게 하기 위해 PK Constraint 를 일시적으로 Disable 하는 경우가 있어서, 이것땜에 인덱스를 다시 생성하는 경우가 있다. 그래서 의도적으로 non-unique index 를 생성하는 경우가 있다.. 라고 하네요. 설명을 끝까지 하지 않아서 아쉽지만 어쨌든 공부한게 나왔네요
하여튼 primary key, foreign key, not null 등과 같은 integrity constraint 정보들은 plan을 생성하고, query rewrite(주로 DW에서 많이 사용되는 기능임)를 수행할 때, 그리고 기타 여러가지 용도로 데이터베이스에 의해 사용되어집니다.
그리고 OLAP Tool과 같이 데이터베이스에 접근하는 여러 tool들이 동적으로 ad-hoc query를 생성할 때 이 정보들을 활용합니다.
optimizer와 tool 입장에서 뿐만 아니라 데이터베이스를 사용하는 사용자 입장에서도 실제 document 역할을 하게 되므로 의미가 있습니다. ER Diagram을 보지 않고 data dictionary에 있는 정보만을 보고도 그 테이블의 식별자(Identifier)가 어떤 컬럼으로 구성되어 있는지 쉽게 확인할 수 있잖아요.
이런 좋은 기능과 역할을 하는데도 불구하고 unique index와 not null 만을 정의해서 primary key 기능을 대신하도록 할 이유는 없지 않을까요?
성능과 관련해서 말씀드리면, Not Null Constraint와 Unique 인덱스를 PK Constraint 대신 사용하는 것이 더 속도가 빠르다는 것은 전혀 근거없는 낭설에 불과합니다. 오히려 SQL 옵티마이저에게 더 많은 정보를 제공함으로써 더 좋은 실행계획을 만드는데 일조하게 되고 따라서 더 빨라지는 경우가 많겠지요...
cafe.naver.com/ocpgroup
님의 자료를 퍼왔습니다.
아주 설명이 잘되있는 걸 찾아서 부연설명해서 올립니다.
참고로 퍼온곳은 www.dbguide.net 이라는 곳인데, 질문답변란에 올리면
엔코아나, 기타 좀 이름있는 DB컨설팅 회사 사람들이 답변을 해줍니다.
메일링 가입하시면 좋은 정보 많이 얻으실겁니다.
유니크인덱스와 PK의 차이점? 조회: 413 2004-03-26
김윤선(covey02)
PK와 유니크 인덱스의 차이점은 뭔가요?
테이블에서 FK를 사용하지 않는다면 유닉스 인덱스 만으로도 가능한데..
굳이 PK를 잡는 이유는 뭔지 알고 싶습니다.
테이블을 대표하는 것을 나타내기위해 PK를 쓴다는 말이 있는데...
이건 유닉스 인덱스로 대치 할 수 없는건가요?
PK와 유니크 인덱스 중 유니크인덱스로만 구성했을때 퍼포먼스가 더 빠르다고 하던데 맞는 말인지 알고 싶습니다. 맞다면 어떻게 해서 더 빠른지두 알고 싶습니다.
유니크인덱스와 PK의 차이점? 2004-03-26
유기연(inyou2)
PK와 유니크 인덱스는 비교 하기엔 좀 무리가 있다고 보는데요
Table 생성시 PK에 자동적으로 유니크 인덱스가 생성 됩니다.
일반적인 유저가 생성하는 인덱스는 유닉스 인덱스로 만들지 않는것이
좋습니다.
만일 PK없이 유저가 유니크 인덱스만 만들었다고 해도 PK를 대신할수는 없습니다.
옵티마이져가 실행계획시 인덱스 안타고 FTS 하면 인덱스는 아무 소용이 없는거죠.
인덱스와 키는 개념 자체가 틀린겁니다.
테이블에서 FK를 사용 하지 않아도 PK는 필요합니다.
이유를 말하자면 모델링 측면에서는 Relational 개념에 부합하는거겠고
Database측면으로 보자면 옵티마이져가
빠른 실행계획을 만드는데 도움이 되겠죠...
굳이 따지자면 PK와 유니크키의 차이점을 물어 보시는듯 하는데요..
큰 차이점은 유니크키는 널 값을 허용 하는 겁니다.
키가 될수 있는 후보 키가 유니크키고 그중 가장 값을 유일하게 구별해 주는 넘을
PK라고 이해하시면 될듯 합니다.
PK없이 유니크인덱스로만 구성했을때 퍼포먼스가 더 빠르냐는 문제점은
당시 테이블의 데이타의 양 및 어떤 분포도를 가지냐에 따라
사례에 따라 천차 만별 달라집니다.
튜닝및 퍼포먼스 문제는 언제나 딱 잘라 절대적으로 말할수 없는 문제죠...
유니크인덱스와 PK의 차이점? 2004-03-26
김인호(yesino)
안녕하세요.. 이노입니다.
궁금해하시는 내용에 대한 답변은 예전 좀 다른 문제로 제가 답변을 올렸던 경우와
유사한 듯 하여 그때 내용을 간략하게 다시 올리겠습니다.
먼저 PK Index와 Unique Index의 차이는 간단하게 Nullable의 차이라고 하겠습니다.
쉽게 말해서 PK Index라는 것은 Unique Index + Not Null을 의미합니다. -> 뒷부분에서 근본적으로 차이가 있다라고 설명합니다.
반대로 Unique Index는 인덱스가 걸리는 필드에 대해서도 Null을 허용하죠.
즉, 특정 테이블의 컬럼에 대해 Unique 인덱스가 있다고 해서, 해당 필드에 Null 값을
Insert 못하지는 않습니다. 하지만, PK Index가 설정되어 있다고 한다면 자동으로
해당 필드에 대한 Not null 제약조건이 생기기 때문에 Null을 insert할 수 없죠.
이러한 이유로 인해, SQL의 경우에 따라서는 Unique Index임에도 불구하고 Table
Access를 하는 예도 있습니다. 해당 값이 Not Null임을 보장하지 못하기 때문이죠.
따라서 SELECT문의 경우 때로는 오히려 Unique보다 PK가 아주 근소한 차이지만 더
빠른 경우도 있습니다. 물론, INSERT의 경우 제약조건에 대한 체크로 인해 조금 더
느릴(?)수도 있겠지요..
실제 테스트를 해봐도, 특정 field의 값에서 max값을 추출하고자 하는데 null이 포함되어 있으면 실제로 index search에서 찾은 값이 null인지 값을 가지고 있는지는 테이블을 뒤져봐야 알 수 있는 정보가 됩니다. -> 그래서 질문할 때 말했던, unique index가 더 빠르다는 것은 경우에 따라서 반대로 primary key 일때 더 빠를 수 있다. 겠네요
그래서 PK Index인 경우에는 (null을 가진 필드가 없음을 보장해주기 때문에..)index 영역안에서 결과 값을 리턴해줄 수 있고, Unique의 경우에는 데이터 영역까지 가서 실제 값을 확인해봐야 하는 결과가 나옵니다.
(이러한 경우도 Analyze나 테이블에 대한 정확한 통계가 있다면 그렇지 않을수도..)
이상 짧은 제 소견이였습니다.
원하시는 답변이 어느 정도 되셨는지 모르겠습니다.
행복한 하루 되시기를~~
유니크인덱스와 PK의 차이점? 2004-03-27
조시형(oraking)
안녕하십니까? 엔코아 정보컨설팅에 근무하는 컨설턴트 조시형입니다.
우선 Primary Key와 Unique Index의 차이점을 설명하는 것은 부적절하다는 말씀을 드리고 싶습니다. 둘간의 상관관계를 설명하는 것이 맞는 개념입니다. 많은 개발자들이 PK는 왠지 부하를 준다는 잘못된 선입견을 가지고 있고 따라서 PK 대신 Unique Index를 사용하는 것으로 알고 있는데 매우 그릇된 관행(?)이라고 생각합니다. 따라서 앞에서 다른 분들이 좋은 설명 많이 해 주셨지만 부연해서 설명을 드리도록 하겠습니다.
Primary Key라고 하는 것은 논리적인 개념입니다. Primary Key는 해당 컬럼이 그 테이블의 식별자임을 나타내는 것으로서, 자신과 다른 레코드가 서로 다른 인스턴스임을 확인할 수 있게 해 주는 역할을 합니다. 즉, 해당 그 레코드의 존재자체인 것이지요.
원래 사람이름이라는 것이 '나'와 다른 사람을 식별하기 위해 사용하는 것인데, 다른 사람과 중복될 수 있으므로 나를 식별할 수 있는 속성으로서 주민등록번호라는 것을 대신 사용합니다. 따라서 주민등록번호는 나와 별개가 아닌 나의 존재 그 자체입니다. 철학적으로는 맞지 않는 설명이겠지만 적어도 ‘데이터의 세계’에서는 그렇습니다.
반면 PK constraint는 물리적인 개념입니다. "이 컬럼(들)은 다른 레코드와 구분짓는 식별자 역할을 하는 중요한 컬럼이므로 데이터는 중복을 허용해서는 안 되고(unique), null값을 허용해서도 안돼(not null)"라고 DB에게 정보를 주는 것입니다. primary key constraint를 설정하면 unique index와 not null constraint가 자동적으로 생성되는 이유도 여기에 있지요. -> 스터디할때 primary key는 논리적인 개념이고 index는 실제로 눈에 보이는 물리적인 것이라고 했는데, 설명을 좀 틀린것 같습니다. Primary Key가 논리적인 개념이며, PK Constraint 와 not null 등의 제약조건과 unique index 들이 물리적인 개념이라고 하는게 맞겠군요.
특히 인덱스는 PK 컬럼의 Unique성을 보장하기 위해 매우 필수적인 도구인데, 만약 인덱스 없이 해당 컬럼값이 중복되지 않도록 할 수 있는 방법을 생각해 보시기 바랍니다. 잘 떠오르지 않을 것입니다. 결론적으로 말씀드리면, 인덱스와 PK의 상관관계에 있어서 Unique이든 Non-Unique이든 Index라는 놈은 PK 컬럼의 Unique성을 보장하기 위해 사용하는 하나의 도구(Tool)에 지나지 않습니다.
어떤 의미에서만 본다면, 어느 한 컬럼에 Not Null Constraint를 주고, 그 컬럼에 Unique Index를 생성하였다면 primary key와 다를 것이 하나도 없어 보입니다.
하지만 primary key는 데이터베이스와 사용자 입장에서 매우 중요한 정보 역할을 하기 때문에 중요하다고 말씀드리고 싶습니다.
앞서 말씀드렸듯이, 원래 primary key는 “이 컬럼(들)이 테이블의 식별자(identifier)이므로 중복을 허용해서는 안 되고, null값을 허용해서도 안 된다”라는 의미론적(semantic) 인 의미에서 정의하는 것이며, DBMS는 이를 효과적으로 처리하기 위해서 index를 자동생성해서 사용하고 not null constraint를 정의하는 것입니다.
참고로 primary key를 위해서 반드시 unique index가 필요한 것은 아닙니다. non-unique index만 있더라도 새로운 값이 들어올 때 중복값이 있는지 체크하는 데에는 전혀 문제가 없으므로 기존에 이미 non-unique 인덱스가 정의되어 있는 상황이었다면 그 인덱스를 그대로 사용합니다. DW 시스템에서 대량의 데이터 로딩시 속도를 빠르게 하기 위해 PK Constraint를 일시적으로 Disable 시키는 경우가 있는데 이렇게 되면 Unique Index도 동시에 제거되므로 인덱스를 다시 생성해야 하는 부담이 생깁니다. 이러한 부담을 덜기 위해 의도적으로 non-unique index를 생성하는 경우가 있는데 이에 대해서는 더 깊이 언급하지 않겠습니다. -> 스터디할때 책에 나왔던 부분입니다. primary constraint key 를 생성하면 자동적으로 unique index가 생기는데, 주의할점은 primary constraint key를 해제할 때 unique index 도 자동적으로 삭제된다, 따라서 연기가능한 제약조건(맞나?) 등을 이용할 수 있다. 라는 부분이었습니다. 그때는 사람이 실수나, 다른 이유로 제약조건을 삭제할 때 인덱스까지 없어지므로 갑자기 느려지는 상황이 올 수 있다. 라고 말을 했었는데요, 그런 경우와 함께 DW 시스템 (OLAP) 에서 데이터 로딩 속도를 빠르게 하기 위해 PK Constraint 를 일시적으로 Disable 하는 경우가 있어서, 이것땜에 인덱스를 다시 생성하는 경우가 있다. 그래서 의도적으로 non-unique index 를 생성하는 경우가 있다.. 라고 하네요. 설명을 끝까지 하지 않아서 아쉽지만 어쨌든 공부한게 나왔네요
하여튼 primary key, foreign key, not null 등과 같은 integrity constraint 정보들은 plan을 생성하고, query rewrite(주로 DW에서 많이 사용되는 기능임)를 수행할 때, 그리고 기타 여러가지 용도로 데이터베이스에 의해 사용되어집니다.
그리고 OLAP Tool과 같이 데이터베이스에 접근하는 여러 tool들이 동적으로 ad-hoc query를 생성할 때 이 정보들을 활용합니다.
optimizer와 tool 입장에서 뿐만 아니라 데이터베이스를 사용하는 사용자 입장에서도 실제 document 역할을 하게 되므로 의미가 있습니다. ER Diagram을 보지 않고 data dictionary에 있는 정보만을 보고도 그 테이블의 식별자(Identifier)가 어떤 컬럼으로 구성되어 있는지 쉽게 확인할 수 있잖아요.
이런 좋은 기능과 역할을 하는데도 불구하고 unique index와 not null 만을 정의해서 primary key 기능을 대신하도록 할 이유는 없지 않을까요?
성능과 관련해서 말씀드리면, Not Null Constraint와 Unique 인덱스를 PK Constraint 대신 사용하는 것이 더 속도가 빠르다는 것은 전혀 근거없는 낭설에 불과합니다. 오히려 SQL 옵티마이저에게 더 많은 정보를 제공함으로써 더 좋은 실행계획을 만드는데 일조하게 되고 따라서 더 빨라지는 경우가 많겠지요...
피드 구독하기:
글 (Atom)