database.sarang.net
UserID
Passwd
Database
DBMS
ㆍMySQL
PostgreSQL
Firebird
Oracle
Informix
Sybase
MS-SQL
DB2
Cache
CUBRID
LDAP
ALTIBASE
Tibero
DB 문서들
스터디
Community
공지사항
자유게시판
구인|구직
DSN 갤러리
도움주신분들
Admin
운영게시판
최근게시물
MySQL Columns 13171 게시물 읽기
 News | Q&A | Columns | Tutorials | Devel | Files | Links
No. 13171
PostgreSQL vs. MySQL
작성자
정재익(advance)
작성일
2001-10-22 22:46
조회수
11,377

이 주제는 Linuxer 들에게는 아주 진부한 것이다. 예전부터 끊임없이 싸워온 문제이기 때문이다. 하지만 현실적으로 MySQL 은 Linux Web Server 에서 가장 많이 채택되고 있는 DBMS 이다. 하지만 개인적으로 PostgreSQL 의 그 뛰어난 기능에 찬사를 보내지 않을 수 없다.

다음 글은 이 진부한 내용을 가지고 다시 새롭게 조명한 점이 맘에 들어서 이렇게 번역하여 올려 둔다. 한번 관심을 가지고 읽어 보기 바란다.

 

=============

PostgreSQL 대 MySQL

 

원본 출처 : http://www.webtechniques.com/archives/2001/09/jepson/

 

좀더 나은 데이터베이스를 만들기 위해서

 

By Brian Jepson

번역 : 정재익

 

대부분의 사람들은 PostgreSQL 과 MySQL 을 비슷한 서로다른 database 로 여긴다. 둘다 상당한 대중적인 지명도를 얻고 있다. 옛날버전의 기록대로 보면 PostgreSQL 의 속도와 MySQL 내구성에 대해서 많은 논쟁이 있었다. 이들 두 패키지는 모두 그동안에 많은 발전이 있었고, 서로 많이 비슷해 졌기 때문에 응용 프로그램 작성시에 둘 중 어느것을 선택할 것인지 망설이게 된다.

 

MySQL 은 내장 SQL 함수와 같은 논리적인 기능들을 제공하는데 80/20의 법칙을 따르고 있다. 응용프로그램의 80%에서 사용하는 20%의 SQL 명령어만을 지원한다. 단순한 응용 프로그램 개발자들은 stored procedure 나 subquery 와 같은 나머지 사양들은 없어도 충분하며, 필요할 경우 client-side 프로그래밍으로서 어느 정도 해결이 가능하다.

 

한편 PostgreSQL 은 MySQL 보다는 좀더 많은 기능을 제공한다. 좀더 많은 SQL 함수들을 지원하며, server-side procedural language 들도 지원하며, 좀더 편리한 날짜 처리방법을 제공한다. PostgreSQL 은 객체-관계형 사양을 지원하며, 지리 자료형도 지원한다. 만약 여러분들이 좀더 복잡한 사업 목적을 가진 응용프로그램을 작성할려고 생각한다면 PostgreSQL 은 database server 에서 좀더 논리적으로 업무를 처리할수 있도록 해 줄 것이다.

 

ACID 테스트

 

데이터에비스를 서로 구분하고, 전반적인 quality 검사를 하는 좋은 방법중 하나가 ACID test 를 하는 것이다. ACID test 는 데이터에비스 시스템의 4가지 성질을 기술하는 것이다: atomicity, consistency, isolation 그리고 durability

 

1. Atomicity 라고 하는 것은 전체반응-또는-전체무시 의 성질을 말한다.

(Atomicity is an all-or-none proposition)

 

UPDATE, INSERT 또는 DEETE 구문을 포함하고 있는 트랜젝션을 정의했다고 가정해 보자. Automicity 라고 하는 것은 이들 구문들을 하나의 유닛 (single unit) 으로서 처리하는 것이다. 그리고 consistency (ACID 중 C) 측면에서 보면 오로지 두가지 결과만이 가능하다: 데이터베이스에 모든 변화를 적용시키던지 또는 전혀 변화를 반영시키지 않는 것이다. 이것은 은행에서 계좌간 이체를 하는 등의 트랜젝션 처리시에 대단히 중요하다. 만약 적절한 INSERT 가 수행되기 전에 DELETE 를 시행후에 서버가 다운되어 버린다면 대단히 큰일이 발생하기 때문이다.

 

2. Consistency 라는 것은 데이터베이스에서 트랜젝션이 결코 절반만 완료한 상태에서 종료되지 않도록 보증해주는 것이다.

(Consistency guarantees that a transaction never leaves your database in a half-finished state)

 

만약 트랜젝션의 일부가 실패한다면, 대기중인 모든 변화들이 원상복구 (roll back) 되고, 데이터베이스는 트랜젝션을 시작하기 전 상태로 될 것이다. 예를 들면, 고객의 레코드를 지웠다면, 여러분들은 그 고객의 레코드와 관련된 테이블 내의 모든 레코드들을 삭제해야 할 것이다.(예를 들면, invoices, line items 등등) 적절하게 설정된 데이터베이스는 여러분들이 직접 이러한 고객들의 레코드를 삭제할 필요가 없다. 즉 invoices 등과 같은 연관된 레코드들은 그냥 남겨 두어도 된다는 것이다.

 

3. 독립성이라고 하는 것은 트랜젝션이 종료될때까지는 서로 독립된 것으로서 취급하는 기능을 말한다.

(Isolation keeps transactions separated from each other until they're finished)

 

Transaction isolation 은 일반적으로 여러가지 모드로 설정할 수 있다. 예를 들면, 다른 트랜젝션이 종료될때까지 트랜젝션을 금지시키는 모드가 있다. 또 다른 모드는 트랜젝션이 안쓰이는 데이터 (데이터베이스가 트랜젝션이 시작되기 이전 상태로 부터) 를 참조할수 있는 모드가 있다. 사용자가 고객을 삭제하는 경우를 생각해 보자. 그리고 그 고객의 invoice 가 삭제되기 전에 두번째 사용자가 invoice 를 갱신하는 경우를 고려해 보자. 트랜젝션 금지 시나리오에서는 두번째 사용자는 갱신을 하기 전에 먼저 사용자의 삭제 작업이 끝날때까지 기다려야 한다. 두번째 사용자는 그 고객의 레코드가 이미 삭제 되었다는 것을 알게 될 것이고, 그것을 알지 못하고, 변경작업을 날리는 것 보다는 훨씬 더 나은 결과를 얻을 수 있다.

 

4. 내구성이라는 것은 서버가 비정상적인 종료로 부터 회복될 때 그 이전에 데이터베이스에 가해진 변경을 보존시켜 주는 것을 말한다.

(Durability guarantees that the database will keep track of pending changes in such a way that the server can recover from an abnormal termination)

 

데이터베이스 서버가 비록 트랜젝션 중간에 플러그가 뽑히는 경우가 발생하더라도, 서버는 재 시작시 무결 상태로 돌아 갈것이다. 데이터베이스는 트랜젝션 로그 내에 이 트랜젝션을 comitt 가 되지 않은 상태로서 보관하기 때문에 가능한것이다. Consistency 라는 측면에서 보면 (위에서 설명한 것 처럼), 비정상적인 종료를 한 경우 부분적으로 진행된 트랜젝션은 데이터베이스에 그 변경사항이 기록되지 않아야 한다. 그러나 이러한 비정상적인 종료후, 데이터베이스가 재시작 할때 트랜젝션 로그를 검사해서 commit 되지 않은 완료된 트랜젝션을 찾아서 그들의 변경 사항을 데이터베이스에 적용시켜 준다.

 

PostgreSQL 은 ACID 를 만족시켜 준다. 표준 MySQL 은 consistency, isolation, durability 등을 지원하지 않기 때문에 ACID 를 만족시키지 못한다. 그러나 기본적으로 table lock 을 통해서 atomicity 는 지원해 주고 있다. 그리고 운이 좋게도 MySQL 은 테이블을 다루는 데 있어서 다양한 정도의 유연성을 지원해 준다. 나중에 언급하겠지만 NuSphere 의 Gemini 테이블 핸들러는 완전히 ACID 를 지원 가능하게 해 준다. 그리고 최근 MySQL 버전에는 Berkeley DB 와 InnoDB 테이블 핸들러가 추가되었다. 만약 여러분들이 이들 테이블 핸들러를 사용한다면, 그들에게 특수하게 컴파일된 MySQL 버전을 얻든지 또는 이들 핸들러를 지원하도록 컴파일해야 한다. MySQL 문서에 보면 CREATE TABLE 구문을 통하여 어떻게 이런 핸들러들에서 이들을 사용하는지에 대해 설명하고 있다 (http://www.mysql.com/documentation 참조)

 

이러한 제한된 사양 때문에 MySQL 은 대단히 빠르다. 여러분들은 in-memory table 을 적용시킬 경우 엄청난 속도를 낼수도 있다. Durability 라는 측면에서 볼때 트랜젝션 중간에 플러그를 뽑게 된다면 어느 정도 자료의 소실을 초래할 수 있다. PostgreSQL 은 많은 기능을 지원해 주고 있으며, 여러분의 자료가 안전하다는 것을 보장해 준다. 그러나 여러분들이 이런 사양을 한꺼번에 모두 구현한다면, 여러분들의 응용프로그램은 퍼포먼스 문제로 고통을 당하게 될 것이다. 운이 좋게도 최근의 PostgreSQL 은 상당한 퍼포먼스의 향상을 기하고 있다.

 

Shrink-Wrapped

 

비록 PostgreSQL 과 MySQL 이 소스가 공개된 제품이라고 하더라도, 두 데이터베이스 모두 자신만의 사양을 가지고 상업적으로 많이 배포하고 있다. 이와 같은 데이터베이스들의 목록을 볼려면 다음을 참조하기 바란다.

 

===========================

Sidebar: Open source database 로는 충분치 않다.

 

PostgreSQL, MySQL 그리고 Borladn Interbase 등과 같은 소스가 공개된 데이터베이스들이 최근에 큰 발전이 있었다. 그들이 성숙되어 감에 따라 이들 저비용의 패키지들은, 높은 비용을 지불해야 하는 기존의 상용 소프트웨어의 대용으로 웹개발자들에게 특히 관심을 끌고 있다. 그러나 때로는 최저가의 solution 이 능사는 아니다. Oracle, Sybase, IB< 그리고 Microsoft 등과 같은 밴더들은 그들 각자의 제품을 개발하고 연구하기 위해서 많은 비용을 투자하고 있다. 결과적으로 상용 데이터베이스들은 전형적으로 소스가 공개된 제품들에 비해서 좀더 나은 성능을 보이고 있으며, 경쟁이 되질 않고 있는 것이다.

 

예를 들면 :

 

속도

데이터베이스의 퍼포먼스를 높이려면 좀더 강력한 CPU 와 더 빠른 하드디스크에서 시작한다. 그러나 속도가 절대적으로 중요할 때에는 추가적인 소프트웨어를 필요로 하기도 한다. 상용 데이터베이스들이 이러한 하드웨어적인 병목을 해결하는 한가지 방법은 clustering 이다. 이것은 몇개의 서버들이 한개의 자료 저장장치에 걸리는 부하를 나누어서 처리하는 방식이다. 또다른 기법은 raw file system 을 사용하는 것이다. 이것은 데이터베이스가 운영체계를 무시하고 디스크에 직접적으로 접근하는 것을 말한다.

 

규모

적절한 량의 데이터를 가진 하나의 서버에서 하나의 데이터베이스 인스턴스만을 운영하는 것은 쉽다. 여러분들의 요구사항이 이러한 단순한 설정을 넘어서 점차 커지면 여러분들은 소프트웨어도 점차 더 커지길 원하게 될 것이다.

 

회사에서 수 테라바이트의 크기를 가진 데이터베이스 호스트를 보는 것은 그렇게 힘든 일이 아니다. 대체로 소스가 공개된 데이터베이스들은 이런 대용량의 정보를 제대로 취급하질 못한다. 때로는 각각의 레코드가 수 킬로 바이트 정도로 한정되는 경우도 흔하다. 여러분들이 하나이상의 서버가 필요한 경우도 있다. 그럴때에는 replication 을 지원하는 데이터베이스를 원하게 될수도 있다. 소스가 공개된 데이터베이스에서는 몇개의 서버간에 자료를 서로 복사하고 동기화를 유지하기는 쉽지 않다.

 

신뢰성

만약 서버를 늘 가동해야 한다면, 사용 패키지는 여러분들이 자고 있는 방동안에도 잘 동작할수 있는 failover solution 도 필요로 하게 된다. 가장 진보된 시스템은 만약 일차 데이터베이스 서버가 동작을 멈출경우 즉시 대기중인 서버가 동작할수 있는 hot standby 서버의 서치가 가능하게 한다. 상용 데이터베이스는 데이터베이스가 기동중에도 hot backup 이 가능하며, 서버 관리자가 자료가 파괴되기 직전에 정확하게 자료를 재구성할수 있도록 해 주는 point-in-recovery 도 가능하다.

 

프로그래밍의 편리성

SQL 이 비록 산업 표준이기는 하지만 대부분의 데이터베이스 패키지는 이러한 기본 사양으로 넘어서 outer join, inner join, subselect 같은 좀더 진보된 질의를 가능하게 한다. 비록 모든 밴더들이 이와 형태로 지원하고 있지만, Oracle 의 PL/SQL 은 이런 편리한 질의언어의 한 예이다. Oracle 은 JAVA code 를 데이터베이스 내에 내장 하는 등 데이터베이스 프로그래밍에서 좀 더 진보된 사양을 선보이고 있다.

 

지원

대부분의 소스가 공개된 소프트웨어들에서 지원은 뉴스그룹이나 메일링 리스트를 이용한 개별적 양상을 띠고 있다. 일부 Open-source database 의 상업적 지원에도 불구하고, 많은 업체들이 큰회사의 서비스를 받기를 원하고 그래서 그들의 제품을 선택하고 있다. 오늘날 오라클이나 IBM 과 같은 대형밴더들은 서로 싸우지 않는다. 메뉴얼 작성에 주력하고 있다. 여러분들은 더 이상 오라클에 관한 많은 수의 책들을 다 볼 필요가 없다. PostgreSQL 의 경우는 그렇지는 못하다. 만약 뜻이 있다면 비용을 들여서 상용 수준의 문서를 작성하는 것도 좋을 것이다.

 

Neil McAllister, Web Techniques Technical Editor

============================

 

나는 개발자 커뮤너티가 지원하는 정도를 알기 때문에 open-source 데이터베이스들에 대해서 편안함을 느낀다. 그리고 나는 실험적 버전의 소프트웨어로 작업을 하던지 또는 수작업으로 패치를 가하고, 나 스스로 컴파일하고 실행파일을 설치하는 작업을 겁내지 않는다. 많은 사람들은 커뮤너티 내에서 지원받을수는 없으며, 지원을 받기 위한 전화를 걸기 보다는 조절되지 않은 메시지 보드를 보아야 한다. 이런 경우에는 상용 배포판들이 장점을 가진다.

 

당신의 DBA (database administrator) 에 대한 욕구를 없앨수 있는 상용 배포판은 없다. 그러나 상용으로 지원되는 데이터베이스는 여러분들의 DBA 가 C library와 kernel의 조합, 데이터베이스가 가장 바쁠때 제대로 동작 중인지에 대해 신경쓰기 보다는 여러분들의 데이터베이스 내에 있는 것들에 신경 쓸수 있도록 해 준다. 여러분들이 고려해 볼수 있는 몇가지 상업적인 배포회사가 있다: Great Bridge, PostgreSQL, NuSphere, AbriaSoft 그리고 MySQL AB 는 그 중에서 가장 보편화된 배포장소 이다.

 

Great Bridge (http://www.greatbridge.org)는 몇개의 리눅스 배포판을 위한 PostgreSQL 배포를 지원하고 있다. CD 와 메뉴얼을 포장하여 제공한다. 여러분들은 이 배포판을 Great Bridge's 의 웹사이트로 부터 다운로드 받을 수 있다. 게다가 Great Bridge 는 PostgreSQL 사용자들에게 자문 서비스를 제공하고 있다.

 

Great Bridge 는 PostgreSQL 개발 사이트를 후원하고 있다. 이 사이트는 CVS archive, bug tracking, mailing lists 그리고 다른 협력 툴들을 포함한 PostgreSQL 과 관련된 open-source project 를 무료로 호스팅 해 주고 있다. 2001년 1월 Linux Weekly News 가 시행한 Great Bridge 부사장 Bruce Momjian 과의 인터뷰에서 Great Bridge 가 개발한 모든 코드는 open source 라이센스하에서 배포 될 것이라고 한다.

 

PostgreSQL, Inc. (http://www.pgsql.com) 은 1999년 데이터베이스 호스팅을 제공하고 PostgreSQL 사용자들에게 서비스를 제공하기 위해서 설립되었다. 여기서는 PostgreSQL 의 새로운 사양들이 개발되고 있으며, 이들중 일부는 PostgreSQL 프로젝트에 기여되고 있다. 2000년 12월 회사는 PostreSQL 을 위한 open-source replication server 를 발표했다.

 

PostgreSQL 회사는 미래에 독점적인 소프트웨어의 개발 가능성을 남겼다. 그러나 모든 독점적으로 개발된 소프트웨어들은 2년 내에 open-source 화 될 것이라는 공약을 남겼다.

 

NuSphere (http://www.nusphere.com)는 다양한 지원옵션을 가진 MySQL 을 배포하는 회사이다. 여기서는 교육과 consulting services 도 제공한다. NuSphere MySQL 은 Progress Software (NuSphere 의 모회사) 에서 개발한 Gemini 라고 부리는 보다 향상된 테이블 핸들러를 포함하고 있다. Gemini table 은 비정상적인 종료시에 진행된 갱신들을 자동으로 회복시킬수 있는 트랜젝션 로그를 포함한 제대로 된 트랜젝션을 지원한다.

 

비록 Gemini table 이 MySQL source 배포에 포함되지는 않았지만, MySQL 문서는 다음버전의 데이터베이스에서는 배포시 포함될 것이라고 말하고 있다. 그때까지 NuSphere 가 Gemini table 의 유일한 제공자이다.

 

NuSphere 에서 배포하는 MySQL 에는 인쇄된 메뉴얼, 몇개의 포켓 참고소, 그리고 리눅스, 솔라리스 SPARC 그리고 윈도우즈를 위한 소프트웨어를 포함하고 있다. 여러분들은 NuSphere 홈페이지로 부터 이 것을 다운로드 받을수 있다. MySQL Server 에 추가적으로 Apache Web server (SSL 지원 포함), PHP, Perl 그리고 그래픽화 된 관리툴들도 같이 포함하고 있다.

 

Abria Soft (http://www.abriasoft.com) 는 Merlin 서버와 MySQL, Perl, PHP 그리고 Apache 를 포함한 데스크탑 제품을 내놓았다. SSL 지원은 서버 버전에서 이용할 수 있으며, 이곳에는 다양한 관리 와 개발 패키지들을 포함하고 있다. Merlin 은 Windows 또는 Linux 상에서 동작하며, 이것은 구매 하던지 또는 다운로드 받을 수 있다. AbriaSoft 는 다양한 지원 패키지, 자문 서비스 그리고 교육을 제공하고 있다.

 

MySQL AB (http://www.mysql.com) 는 MySQL 을 GNU GPL 하에서 배포하고 있으며, 상업적인 교육코스, 자문 그리고 MySQL 에 대한 지원을 제공하고 있다. MySQL 의 상용 라이센스는 GPL 을 적용할 수없는 무엇인가가 있는 경우 (예를 들면 내장형 MySQL 을 GPL 이 아닌 소프트웨어에 사용하는 경우) 에 이용할 수 있다. 비록 이것은 GPL 에 위배 되는 것처럼 보이지만, 저작권에는 (이 경우 MySQL AB) 그 소프트웨어에 대해서 하나 이상의 저작권을 적용할 수 있도록 하고 있다.

 

SQL 방언

 

PostgreSQL 과 MySQL 이 다른 큰 하나의 영역은 SQL 구문 내에서 사용할 수 있는 함수이다. SQL 이 표준적인 자료 질의어이기 때문에 여러분들은 그것을 서로 다른 데이터베이스들에 대해서도 서로 적용할 수 있기를 원할 것이다. 불행하게도 표준안에 대한 접근은 SQL database 에서 가장 이루고 싶어 하는 것이다. 그들은 모두 SELECT, INSERT, UPDATE 또는 DELETE 구문과 같은 기본적인 것들에 대해서는 모두 근본적으로 동의하는 것 같이 보인다. 그러나 일단 여러분들이 이러한 기본적인 단계를 넘고 나면 SQL 의 구현은 각기 다른 길을 가기 시작한다. 문법이 서로 다를 뿐만 아니라 실제로 지원되는 사양도 서로 상이하다.

 

전형적으로 여러분들은 어떠한 데이터베이스에서라도 약간의 작업만으로도 같은 것들이 실행되길 원할 것이다. 예를 들면 날자형은 아주 다양하다. 많은 데이터베이스 시스템들은 그들이 지원하는 데이터 포맷에 대해서 어느 정도 유연성을 가지고 있다. 그러나 모든 시스템들이 같은 포맷을 지원하는 것은 아니다. 날자에 대해 좀더 이해를 위한 예를 들자면, 본 저자가 2000년 Web Techniques 에 기고한 글인 "Same Time Next Month?" (http://www.webtechniques.com/archives/2000/09/jepson/) 글을 읽어 보기 바란다.

 

내가 앞에서 언급한 것 처럼 PostgreSQL 은 MySQL 보다 더 다양한 SQL 방언을 지원한다. PostgreSQL 에서 차이 나는 것중 하나는 subquery 에 대한 지원이다. 개발자들은 종종 좀더 복잡한 작업을 수행하기 위해서 이러한 subquery 를 사용한다. SELECT 문장이 복잡한 조건문을 이용하여 동적인 자료들을 생성할수 있는 반면에, subquery 는 좀더 세련된 방법으로 동적인 자료를 생성해 낸다.

예를 들면 employeesalary 라는 두개의 테이블이 있다고 가정하자. 그리고 이들 두개의 테이블은 employee_id 라는 키에 의해 서로 연결되어 있다고 가정하자. 이제 고용인의 월급을 두 테이블을 join 하여 알아 내고자 한다고 가정하자. 이제 여러분들은 고용인의 가장 높은 월급을 75%로 감봉하고자 한다고 가정하자. 이것을 하기 위해서 여러분들은 가장 높은 월급을 찾아야 하며, 이 값을 어딘가에 저장하고, 후에 update 를 시행할때 이 값을 이용해야 할 것이다. 이러한 과장을 다음 예제 1에서 JAVA code 로 구현해 보았다.

 

예제 1

=================================

// Find the highest salary:

rs = stmt.executeQuery("SELECT MAX(salary.salary) " +

"FROM salary");

rs.next();

int max_salary = rs.getInt(1);

 

// Downgrade all employees with that salary:

stmt.execute("UPDATE salary " +

"SET salary = salary * .75" +

"WHERE salary = " + max_salary);

=================================

 

이 예제는 두개의 동작 (자료 추출 과 삭제)이 하나의 유닛 (atomic unit) 으로서 합쳐지지 않았기 때문에 좋은 접근 방법이 아니다. 이론적으로, 여러분들이 가장 높은 월급을 추출하고 나서 그 사람의 월급을 감봉시키기 전에, 누군가가 다른이의 월급을 더 올릴 수도 있는 것이다. 만약 subquery 를 사용한다면 이 동작은 하나의 문장으로서 해결이 가능하다. (예제 2를 보라)

 

예제 2

=================================

UPDATE salary

SET salary = salary * .75

WHERE salary = (SELECT MAX(salary.salary) FROM salary);

=================================

 

비록 MySQL 은 subquery를 실행할 수는 없지만, 임시 테이블이 여러분들이 SELECT 구문에서 이 subquery 를 흉내 낼수 있도록 도와 줄 것이다. 왜냐하면 SELECT 구문은 여러가지 테이블을 join 할 수 있기 때문이다. (subquery 를 사용하지 않고는 여러분들은 부가적인 테이블에서 UPDATE 또는 DELETE 를 사용할 수 없다) Subquery 의 내용을 temporary table 내에 저장하고, temporary table 에 대해서 outer join 을 시키면 구현이 가능하다. MySQL 은 예제3 에 보인 PostgreSQL 의 subquery 를 예제4 에서와 같이 temporary table 을 이용해서 구현할 수 있다. 어떤 경우에는 subquery 동작을 흉내내기 위해서 지역변수 (local variables)를 사용할수도 있다. 만약 여러분들이 subquery 를 이용해서 단 한줄 만을 받아 오는 경우라면 예제 5 처럼 구현할 수도 있다. (이러한 예제를 제공해 준 monty@mysql.com 에게 감사를 전한다).

 

예제 3

=================================

/* Find the employees who have the highest salary. */

SELECT employee_name

FROM employee, salary

WHERE employee.employee_id = salary.employee_id

AND salary = (SELECT MAX(salary.salary) FROM salary);

=================================

 

예제 4

=================================

# Create a temporary table and put the highest salary

# into it.

#

CREATE TEMPORARY TABLE max_salary

SELECT MAX(salary.salary) as max_salary FROM salary;

 

# Join the employee and salary table to the

# max_salary table to get the names of the

# employees with the highest salary.

#

SELECT employee_name

FROM employee, salary, max_salary

WHERE employee.employee_id = salary.employee_id

AND salary = max_salary

=================================

 

예제 5

=================================

SELECT @salary:=MAX(salary.salary) FROM salary;

UPDATE salary SET salary = salary * .75 WHERE salary = @salary;

=================================

 

MySQL 의 임시 테이블은 각각의 사용자들의 접속에 대해서 개적으로 생성되기 때문에 다중 사용자 환경에서도 안전하게 동작한다. 이것은 만약 두 사용자자가 max_salary 라고 불리는 임시 테이블을 만들어도 그들은 서로 충돌하지 않는다는 것을 의미한다.

 

비록 ACID 를 지원한다고 선언한 데이터베이스에서라도, 누구에게나 데이터가 파괴 (corrupt) 될 수 있는 위험성은 있다. 그러나 여러분들은 가짜 자료로 부터 보호 받을수는 없다. 어떻게 존재하지 않는 고객들에 대한 invoice 를 저장하는 것으로 부터 여러분들을 보호할수 있을 것인가? 그리고 누군가가 실수로 해결되지 않은 부채를 가진 고객을 지웠다면 어떻게 될 것인가? 여러분들의 시스템은 그러한 계정은 영원히 잊어 버릴 것이다. 그리고 이것은 사업에 좋지 않은 영향을 미칠 것이다. 비록 ACID 의 지원이 자료의 파괴로 부터는 보호해 줄수 있겠지만자료의 무결성은 여러분들이 구현시에 그러한 관계에 대해서 어떻게 노력하느냐의 여부에 달려 있다. (예를 들면, 지급되지 않은 부채를 가진 record 는 절대로 누군가가 지우지 못하게 한다던지 하는 등의...) ACID 를 제대로 지원하는 데이터베이스를 선택하면 여러분들이 요구는 비교적 오랫동안 만족될 것이다. 그러나 여러분들의 일을 모두 해결할 수는 없다. 이것은 보다 중대한 문제점에 대해 생각할 시간을 사 줄수는 없다. 그러나 여러분들의 응용 프로그램이 가짜 자료를 방지하는데는 도움이 될 것이다.

 

하나의 문 또는 두개의 문

 

두개의 데이터베이스는 모두 많은 유사점을 가지고 있다. 그럼 어떻게 최상의 선택을 할수 있을 것인가? 나는 두개의 데이터베이스를 모두 사용해 보았고, 이것과 저것을 모두 사용하도록 각각 권장도 해 보았다. (그리고 잘못 인도한 죄로 질책도 받아 보았다)

 

만약 여러분들이 weblog 또는 portal 에 적절한 데이터베이스를 찾는다면 (2001 년 1월에 webtechnology 에 기고한 "Blog Rolling Competitions" (http://www.webtechniques.com/archives/2001/01/jepson/ 글을 읽어 보기 바란다) MySQL 에 의존한 그러한 패키지를 많이 발견할 수 있을 것이다. 이것을 PostgreSQL 로 이전하는 것은 간단히 할수 있다. 그러나 여러분들이 완성된 패키지를 찾는다면 그러한 포팅 노력은 하지 않는 것이 좋다.

 

만약 여러분들이 Oracle, Sybae, Microsoft SQL 서버로 부터 이전을 계획하고 있다면 PostgreSQL 을 권장한다. 언급한 데이터베이스들 처럼 PostgreSQL 은 trigger, stored procedure 를 지원하고, 다양한 내장 함수들 (날자를 다루는 다양한 함수들을 포함한) 을 가지고 있다. 만약 여러분들이 Oracle 의 PL/SQL 이나 SQL Server 의 Transact-SQL 에 익숙하다면 PostgreSQL 의 procedural language 는 배우기가 용이할 것이다.

 

나는 나자신의 웹사이트네은 MySQL 을 사용한다. MySQL 은 웹 개발자들에게 맞추어서 개발되어져 있다. PostgreSQL 은 좀더 다양한 응용 프로그램 개발자들에게 맞추어져 있는 것 같다. 나는 가끔 보다 복잡한 데이터베이스 응용 프로그램을 개발하기 위해서 나의 아내의 컴퓨터 공학과 대학원생들을 접하게 된다. (일부는 웹에서 하고, 일부는 아니기도 하다). 이러한 프로젝트에 대해서는 나는 언제나 PostgreSQL 을 권장한다. 이론적으로 여러분들은 여러분들의 응용 프로그램에 두 데이터베이스 시스템을 다 사용할 수 있다. 그러나 성미에 맞지 않게만 가지 않는다면 좀더 인생을 편안하게 할수 있을 것이다.

[Top]
No.
제목
작성자
작성일
조회
16394MySQL에서도 Procedure를 MyLua [1]
김주현
2002-07-03
9512
13686MySQL 을 지원하는 Database Design Tool [3]
정재익
2001-11-19
11169
13195PostgreSQL vs. MySQL
정재익
2001-10-23
9051
13171PostgreSQL vs. MySQL
정재익
2001-10-22
11377
Valid XHTML 1.0!
All about the DATABASE... Copyleft 1999-2023 DSN, All rights reserved.
작업시간: 0.048초, 이곳 서비스는
	PostgreSQL v16.1로 자료를 관리합니다