어떤것이 데이터베이스란건지..

dummy999의 이미지

저는 그냥 MSSQL, 오라클 이런것이 데이터베이스라고 생각했었는뎅 엑세스도 데이터베이스쪽에 포함이되는거같네요.
오픈오피스2.0의 소개를 잠깐봤는데 거기에도 데이터베이스가 있더라구요..

솔직히 MSSQL이나 엑세스나 제가봤을땐 별반 다른게 없었습니다. 물론 MSSQL은 서버로서 엑세스는 사용할때만 여는건 다르지만요

관계설정하고, 테이블 만들고, 폼만들고, 보고서만들고 하는건 오히려 엑세스쪽이 더 나아보였습니다.
또한 DB쪽 프로그래밍도 가능했고요.

근데 정말 궁금합니다. 왜 이렇게 두부류로나눴을까요?
분명오라클에도 엑세스같은 프로그램이있을텐데..
엑세스, 파워빌더, 비베, 이런걸 하나의 DB관련프로그램으로 구분해도되는걸까요?

서로간의 존재의 이유가궁금합니다.
아시는분있다면 답변좀부탁드리겠습니다.

espereto의 이미지

DataBase의 의미가 무언지 생각해보시면...

Access는 DB 맞습니다. 그리고, DB 관련 작업 이외의 다른 작업은 거의 불가능합니다.

VB는 DB가 아닙니다. DB 프로그래밍은 가능합니다. ODBC를 쓰건, 직접 DB 엔진을 구현하건... 가능하지만 VB가 DB는 아닙니다. 범용 언어(개발툴)로 봐야하죠.

파워빌더... 안 써 봤고 뭔지 본 적도 없어 모르겠습니다. -_-;

다크슈테펜의 이미지

dummy999 wrote:
저는 그냥 MSSQL, 오라클 이런것이 데이터베이스라고 생각했었는뎅 엑세스도 데이터베이스쪽에 포함이되는거같네요.
오픈오피스2.0의 소개를 잠깐봤는데 거기에도 데이터베이스가 있더라구요..

솔직히 MSSQL이나 엑세스나 제가봤을땐 별반 다른게 없었습니다. 물론 MSSQL은 서버로서 엑세스는 사용할때만 여는건 다르지만요

관계설정하고, 테이블 만들고, 폼만들고, 보고서만들고 하는건 오히려 엑세스쪽이 더 나아보였습니다.
또한 DB쪽 프로그래밍도 가능했고요.

근데 정말 궁금합니다. 왜 이렇게 두부류로나눴을까요?
분명오라클에도 엑세스같은 프로그램이있을텐데..
엑세스, 파워빌더, 비베, 이런걸 하나의 DB관련프로그램으로 구분해도되는걸까요?

서로간의 존재의 이유가궁금합니다.
아시는분있다면 답변좀부탁드리겠습니다.


우선 액세스는 간편한 디비 사용을 위한 겁니다.
즉 관계설정이나 그런거는 액세스나 아니면 MSSQL이나 가능합니다.액세스는 프로그래밍상에 간편한 디비 사용 즉 가계부나 아니면 기타 인명록 관리 쪽에 사용할수 있도록 파일 기반 디비입니다.
그런데 이런 엑세스와 일반 디비 서버와의 다른점은 우선 세션이 하나입니다.즉 연결을 하나만 생성할수 있습니다.그래서 디비 오픈후에 다시 디비를 오픈하게 되면 에러가 발생하게 됩니다.즉 일반 적인 디비는 레코드를 수정하는 도중에 다른 연결이 디비 값을 수정할려고 하면 레코드 라킹정도를 하게 됩니다만 엑세스는 연결조차 되지 않습니다.즉 전체가 파일 라킹이 되어 버리는 거겠죠.즉 액세스는 처음부터 단일 연결을 위한 설계로 되어 있다고 보시면됩니다.
두번째 저장 프로시저의 사용입니다.일반 적인 디비는 저장 프로시저의 사용이가능합니다.일반적인 디비서버는 저장 프로시저의 사용이 가능해서 거기에 쿼리를 저장하고 파싱없이 바로 실행시키는 것이 가능합니다.그래서 속도를 높힐수 있습니다만 액세스는 자체 내의 함수수준에서만 지원합니다.
종합해보면 일반 적인 디비서버는 다중 사용자를 위한 데이터 저장소를 위한 솔루션이고 엑세스는 단일 간편 사용자를 위한 솔루션입니다.아마 오픈오피스2에 들어있는 디비도 이것과 같은 개념의 디비라고 생각합니다.
만약 정말 간단 디비를 만든 다고 하면 텍스트 파일도 가능합니다.어떤 분은 텍스트 파일로 데이터를 저장하고 불러들이고 하시더군요.물론 레코드라킹이나 아니면 데이터 정령에 대한 규칙도 세워져야 겠지요.
그리고 물론 엑셀 문서도 엑세스와 같은 형태로 사용할수는 있지만 데이터 작업에서는 엑세스 보다도 약간 제약이 더 있습니다.
일반 디비 서버로도 역시나 액세스와 같은 형태의 작업을 가능하도록 만드는 것이 있습니다.
간편하게 사용할수 있는거는 SQLGate(상용),토드(상용),아쿠아 데이터 베이스 스튜디오,이클립스 플러그인등등 솔루션이 있으며 비지오로도 디비 설계를 하는 것이 가능합니다.UML툴에서도 역시나 가능하구요.
파워빌더는 디비 프로그램밍을 위한 개발툴입니다.디비프로그래밍을 하는데 파워빌더만큼 간편하게 하는 것도 드물다고 하더군요.나중에 C오메가나 아니면 제네릭 C#에서도 이것을 도입하는 걸로 알고 있습니다.

인생이란게 다 그런게 아니겠어요....? 뭘(?)
http://schutepen.egloos.com

sDH8988L의 이미지

dummy999 wrote:
저는 그냥 MSSQL, 오라클 이런것이 데이터베이스라고 생각했었는뎅 엑세스도 데이터베이스쪽에 포함이되는거같네요.
오픈오피스2.0의 소개를 잠깐봤는데 거기에도 데이터베이스가 있더라구요..

솔직히 MSSQL이나 엑세스나 제가봤을땐 별반 다른게 없었습니다. 물론 MSSQL은 서버로서 엑세스는 사용할때만 여는건 다르지만요

관계설정하고, 테이블 만들고, 폼만들고, 보고서만들고 하는건 오히려 엑세스쪽이 더 나아보였습니다.
또한 DB쪽 프로그래밍도 가능했고요.

근데 정말 궁금합니다. 왜 이렇게 두부류로나눴을까요?
분명오라클에도 엑세스같은 프로그램이있을텐데..
엑세스, 파워빌더, 비베, 이런걸 하나의 DB관련프로그램으로 구분해도되는걸까요?

서로간의 존재의 이유가궁금합니다.
아시는분있다면 답변좀부탁드리겠습니다.

머... 용량과 기능 차이라고 봐야죠...

DB로서 본연의 기능은 거의 비슷하지만, 처리 용량, Detail한 서비스가 다른 겁니다...

똑같은 차라고 승용차하고 버스하고 용도가 다른 것과 마찬가지입니다...

PowerBuilder, VB는 범용 프로그래밍 언어와 Tool입니다... 단지, 그것들을 사용하는 목적이 대부분 DB 관련 Project들인지라 PowerBuilder, VB하면 거의 DB 관련 프로그래밍으로 보는 것이지요.

coyday의 이미지

Quote:

DB로서 본연의 기능은 거의 비슷하지만, 처리 용량, Detail한 서비스가 다른 겁니다...

예를 들어 MS 엑세스를 금융권 계정계 업무 같은 코어 업무에 사용하진 않습니다. DB의 기본적인 정의는 같지만.. 사실상 기업 인프라에 해당되는 엔진이기 때문에 안정성과 정합성, 처리 능력 등이 중요하죠.

북한산(X) 삼각산(O) 백운대(X) 백운봉(O)

dummy999의 이미지

엑세스에서도 프로시져를 작성할수있습니다. (엑세스2000이상은 가능한걸로 보임)
다중으로 DB를 여는것은 외부연결로해서 가능하긴하는데
이때 사용가능한것은 DB, 스프레드쉬트파일 등이 연결가능하더군요.
이부분은 아래에 제가 아는부분으로 따로 기술해놨습니다.
------------------------------
아. 그리고 레코드라킹이라는 용어에대해 궁금합니다.
첨보는겁니다.
------------------------------
제가 파워빌더를 DB쪽에 넣은것은 자체적으로 사이베이스(델파이가 사이베이스인가?)
라는 DB를 가지고있어서입니다.
그렇기때문에 DB쪽으로봐버린거고요.. 이것자체도 어떻게보면 엑세스랑 크게 다르지않는
인터페이스를 제공하고있다는걸알수있습니다.
엑세스에서 폼만들고하는게 거의 비슷한 패턴이라서..
또 일반적으로 파워빌더로 일반 응용프로그램 짠다는사람 거의 못봤습니다.
코딩방식도 VB또는 어떤언어랑 상당히 비스무리한걸로 기억되네요(5년전일이라.. -_-;;;)

VB는 상대적으로 파워빌더보다는 거리감이있습니다.
DB쪽에만봤을때 파워빌더보다는 더불편한 인터페이스를 제공하죠.
다시말하자면 거의 범용으로 많이 쓰이고있다는겁니다.

------------------------------
SQL게이트, 토드는제가 써봤는데 관계설정하는것은되지않는거같습니다.
글쎄요 제가 방법을 몰라서일까요? 엑세스수준의 그림으로 보이는 관계설정은 안되는듯..
------------------------------

오라클의 디스커버리나 디벨로퍼, 익스프레스등에대해서 혹시 아시는분이있나요?
이것들중 어떤것은 SQL게이트와 비슷한프로그램도있고 어떤것은 엑셀이나 파워빌더같이 프로그래밍이가능한 것도있고 어떤것은 무슨 통계내는 spss와같은 프로그램도있다고하는데..
자세한걸 모르겠습니다. 다만 제가알기로는 디스커버리와 익스프레스가 기능이 비슷하다는것이고
디벨로퍼는 디벨로퍼2000이라는 버전을 듣기만했는데 파워빌더처럼 프로그래밍이가능하다고하네요.
--------------------------------

그리고 제나름대로 정리된 엑세스류와 DB류에대한 분류는 이렇습니다.

<<엑세스의 특징>>
- 사용 :: 개인만이 쓸수있는 형태
- 포그라운드에서 작업중이어야만함(일반적인 응용프로그램형태임)
- DB연결 :: 한번에 1개만 활성화 가능하며 나머지는 종속적인형태로 연결의 구조를 가짐
(그런걸 토폴로지라고하던가요? 다른것과 연결형태의 구조에대해서말입니다.)

<< 공통점 >>
- 프로시져작성및 함수사용가능
(엑세스류는 2000이상에서는 그렇게 알고있습니다. 이전버전은 어떤지 모르겠음)

<<DB의 특징>>
- 사용 :: 멀티유저 형태
- 백그라운드에서사용가능(일반적인 서버형태임)
- 다른 DB연결 :: 여러DB를 읽어 활성화 할수있음. 모든 DB가 대등한형태를 가짐
(하나 비활성화해도 다른것들도 연달아 죽지않는다는 말임, 물론 영향이 있을수 있겠지만)

서버의 특징
- 멀티유저기능
- 백그라운드 작동하는방식(데몬서비스라고 하던가요?)

-----------------------------------
역시 틀린점에대해 알고싶습니다.

------------------------------------
F/OSS bless you... ^^*

dgkim의 이미지

Office에 포함된 Access는 다른 것과 마찬가지로, 일반 사무(?) 용도로 사용되기 위해 개발된 것이며, Data를 관리하는데 필요한 기능들을 간단하게 많이 쓰이는 부분만 추려낸 핸디툴입니다.

그리고, 현재 일반적으로 데이터베이스라고 하면, SQL을 사용하는 RDBMS가 많이 사용되며, Database의 기능으로 보면, Backend의 기능을 수행합니다. 그래서, 일반적으로 사용자 인터페이스(Frontend)가 제공되지 않으며, PowerBuilder와 같은 프로그램을 통해 Backend와 사용자 인터페이스 간의 연결을 구현합니다.

예전에는 dBase같은 것도 사용되었으며, 현재는 한글(한글과컴퓨터社)에서 dBase에 접근가능합니다.

조금 다른 용도의 데이터베이스는 디렉토리 서버가 있습니다.

다크슈테펜의 이미지

Record Locking은 우선 한 사용자가 레코드에 값을 수정하는 도중에 다른 사용자가 동일한 레코드에 값을 수정할려고 하면 에러가 발생하게 됩니다.
즉 만약 서울과 부산에서 같은 시간대에 1장남은 예약 티켓을 동시에 예약한다고 하면 만약 레코드 라킹을 하지 않으면 둘다 1장이 예약되거나 아니면 둘다 에러를 발생하게됩니다.어짜피 둘다 에러이지만요.
그래서 우선 어떤 사용자가 레코드에 값을 수정할려고 하면 그 레코드에대해 수정하는 동안 디비가 락을 걸어 버립니다.그래서 두번째 사용자가 같은 값을 수정할려고 하면 대기 상태가 됩니다.그리고 첫번째 사용자가 수정을 완료하면 그때 두번째 사용자가 값을 수정할수 있도록 됩니다.
이것을 레코드 라킹이라고 합니다.
비슷한 경우로 일반 프로그램중에 설정파일이 열려 있는 동안 다른 프로그램이 접근해서 열려고 하면 안열리는 경우가 있습니다.이런것을 프로그램상에서 구현하는 것을 파일 라킹이라고 합니다.

인생이란게 다 그런게 아니겠어요....? 뭘(?)
http://schutepen.egloos.com

정태영의 이미지

더미999 님은... 다른 사람들과 언제나 반대방향으로 보는게 아닐까 싶습니다...

데이타베이스 라는 것이 무엇인지는 database 에 대해서 자세하게 기술되어 있는 책이 한두권도 아니고 수십 수백권인데 말이죠 ;)

오라클이나 인포믹스니 이런 특정 db에 대한 책이 아닌... 데이타베이스라는 것에 대한 이론 서적을 한 번 읽어보시길 강력하게 추천해드립니다...

오랫동안 꿈을 그리는 사람은 그 꿈을 닮아간다...

http://mytears.org ~(~_~)~
나 한줄기 바람처럼..

소타의 이미지

Quote:
오라클이나 인포믹스니 이런 특정 db에 대한 책이 아닌... 데이타베이스라는 것에 대한 이론 서적을 한 번 읽어보시길 강력하게 추천해드립니다...

동감입니다. 차라리 DB개론책을 한번 보세요..
DB와 DBMS는 다릅니다.. -_-;
MS-SQL이 DB입니까? DBMS입니까?
DB는 어떤 프로그램들의 일부 기능이 아니라 개념입니다..

내가 별로 보지 못했다고 남들이 안쓰는것도 아니고 불편하다고 범용인건 아닙니다...
방대한 개념을 주관적으로 풀어나가고 싶으신 모양인데 장님이 코끼리 더듬는 걸로 보입니다..
구글을 친구 삼아보세요

ps: 파워빌더, 델파이는 개발도구이고 사이베이스는 유명한 DBMS입니다. 레코드라킹(?)은 row level lock인것 같은데 구글에서 찾아보시면 많이 나올겁니다..

shyxu의 이미지

DB에 대한 설명
http://www.terms.co.kr/database.htm

DBMS에 대한 설명
http://www.terms.co.kr/DBMS.htm

;)

Since 2003.
지금은 맥유저...
---
http://jtjoo.com

dummy999의 이미지

책을 보면 깊게 들어가야합니다. 책자체가 깊게 들어가는 책이 많죠.
저역시 그런점에서 보면 폭넓은 지식이 필요할뿐이지 폭깊은 지식은 필요하지않습니다.
물론 필요하다면 그렇게 파고들어야죠.
다만 제가 궁금한것은 깊게파고들면 기존에 존재하는 지식이 무의미한체 새로운용어가
등장한다는거죠.

DB와 DBMS는 분명차이가 있습니다.
그러나 그것을 달리보겠다는것은 하나하나 집어보겠다는 말과같습니다.
transaction, job, task, process를 달리보겠다는 말과 비슷하다고 생각되네요
물론 약간의 어감은 틀립니다. 그러나 그것들이 근본적으로 지칭하는바는 같지않겠습니까?
마찬가지로 DB와 DBMS가 똑같을수도 틀릴수도있는건 시각차라고 생각됩니다만..
같다고 보는사람은 큰틀에서 DB라고 말하는 바이고
다르다고 보는 사람은 데이터베이스 개념적인면에서 봤을때의 차이를 말하는거겠죠.
위에서 말씀드렸듯이 깊은 지식은 필요할때가 있을때 접근하도록 하겠습니다.

소위짜투리지식이라고하는데 네이버 지식검색이 그런거 해결하는데는 상당한 도움을 준다고 생각합니다. 물론 거기서 찾기에 한계가있어서 여기에서 질문한거지만요.

그리고 개인적인 생각이지만 지식을 파는데있어서
어려운 책 특히나 영어책을 보는것에는 부정적입니다.
언젠가 어떤사람이 "영어공부절때로 하지말아라" 라는 책을 비판하면서 이런비유를 들더군요
들리는것에는 두가지종류가있는데 음성과 음향이라고. 음성은 들었을때 이해할수있는
의미적인 소리의 집합체를 말하는것이고 음향은 들어도 그의미를 파학하지못하는 집합체를
음향이라고 하더라구요.
그러면서 아무리 영어테잎 듣기를 반복한다해도 의미자체를 모르는데 어떻게 귀가뚤리느냐라는 말을 하더라구요.
다시말하면 동물의 소리를 녹음시켜놓고 수십년간을 듣는다해서 어느날갑자기 그소리가
의미로서 접근되는건 아니라고 말하더라구요.

제가 아무리 어려운책을 사서 공부한다해서 어느날갑자기 그것을 이해할수있는건 아니라고 생각합니다.
그기본지식조차 없으면서 어려운책을 보는것은 몇십년을 공부해도 하얀것은 종이고 검은것은 글자일뿐이라고 생각되네요.

점진적으로 접근하는 방법이 필요하고 궁극적으로 그것들이 의미하는 의미를 파악하지못한이상은
누구말대로 갑과 을의 공통점과 차이점 즉 비교할수있는 능력이 없다고 생각됩니다.
이런것은 제가 한때 UI에대해 그것이 중요하다라고말한바와 비슷한목적을
가진말과 같았다는 느낌이 들었습니다.

다른분들의 감정을 건드려고 쓴바는 아닙니다.
있는 그대로 썼을뿐이고요.

이런제생각을 이해해주셨음하는바에서 글을쓴겁니다.
아마 이것관련한 글은 예전에도 썼던것같습니다만..

------------------------------------------------------------

dgkim님 질문있습니다.
백엔드와 프론트엔드에대한 설명좀부탁드립니다.
제가맞는지 모르겠군요. 백엔드는 엔진지향형프로그램이고
프론트엔드는 사용자지향형프로그램이 맞는건지요?

좀더 이부분에대해서 구체적인 용어정리좀 부탁드립니다.

------------------------------------
F/OSS bless you... ^^*

Prentice의 이미지

잠금에 한표!

도저히 생산적인 접근이 불가능할 것 같습니다.

shineyhj의 이미지

dummy999 wrote:
책을 보면 깊게 들어가야합니다. 책자체가 깊게 들어가는 책이 많죠.
저역시 그런점에서 보면 폭넓은 지식이 필요할뿐이지 폭깊은 지식은 필요하지않습니다.
물론 필요하다면 그렇게 파고들어야죠.
다만 제가 궁금한것은 깊게파고들면 기존에 존재하는 지식이 무의미한체 새로운용어가
등장한다는거죠.

DB와 DBMS는 분명차이가 있습니다.
그러나 그것을 달리보겠다는것은 하나하나 집어보겠다는 말과같습니다.
transaction, job, task, process를 달리보겠다는 말과 비슷하다고 생각되네요
물론 약간의 어감은 틀립니다. 그러나 그것들이 근본적으로 지칭하는바는 같지않겠습니까?
마찬가지로 DB와 DBMS가 똑같을수도 틀릴수도있는건 시각차라고 생각됩니다만..
같다고 보는사람은 큰틀에서 DB라고 말하는 바이고
다르다고 보는 사람은 데이터베이스 개념적인면에서 봤을때의 차이를 말하는거겠죠.
위에서 말씀드렸듯이 깊은 지식은 필요할때가 있을때 접근하도록 하겠습니다.

소위짜투리지식이라고하는데 네이버 지식검색이 그런거 해결하는데는 상당한 도움을 준다고 생각합니다. 물론 거기서 찾기에 한계가있어서 여기에서 질문한거지만요.

그리고 개인적인 생각이지만 지식을 파는데있어서
어려운 책 특히나 영어책을 보는것에는 부정적입니다.
언젠가 어떤사람이 "영어공부절때로 하지말아라" 라는 책을 비판하면서 이런비유를 들더군요
들리는것에는 두가지종류가있는데 음성과 음향이라고. 음성은 들었을때 이해할수있는
의미적인 소리의 집합체를 말하는것이고 음향은 들어도 그의미를 파학하지못하는 집합체를
음향이라고 하더라구요.
그러면서 아무리 영어테잎 듣기를 반복한다해도 의미자체를 모르는데 어떻게 귀가뚤리느냐라는 말을 하더라구요.
다시말하면 동물의 소리를 녹음시켜놓고 수십년간을 듣는다해서 어느날갑자기 그소리가
의미로서 접근되는건 아니라고 말하더라구요.

제가 아무리 어려운책을 사서 공부한다해서 어느날갑자기 그것을 이해할수있는건 아니라고 생각합니다.
그기본지식조차 없으면서 어려운책을 보는것은 몇십년을 공부해도 하얀것은 종이고 검은것은 글자일뿐이라고 생각되네요.

점진적으로 접근하는 방법이 필요하고 궁극적으로 그것들이 의미하는 의미를 파악하지못한이상은
누구말대로 갑과 을의 공통점과 차이점 즉 비교할수있는 능력이 없다고 생각됩니다.
이런것은 제가 한때 UI에대해 그것이 중요하다라고말한바와 비슷한목적을
가진말과 같았다는 느낌이 들었습니다.

다른분들의 감정을 건드려고 쓴바는 아닙니다.
있는 그대로 썼을뿐이고요.

이런제생각을 이해해주셨음하는바에서 글을쓴겁니다.
아마 이것관련한 글은 예전에도 썼던것같습니다만..

------------------------------------------------------------

dgkim님 질문있습니다.
백엔드와 프론트엔드에대한 설명좀부탁드립니다.
제가맞는지 모르겠군요. 백엔드는 엔진지향형프로그램이고
프론트엔드는 사용자지향형프로그램이 맞는건지요?

좀더 이부분에대해서 구체적인 용어정리좀 부탁드립니다.


노력부족이며, 아집입니다.
감정을 건드리려고 쓴게 아니라고 하시지만, 항상 감정을 건드리십니다.

뭔가를 얻으려면 지금까지 들인 노력보다 더 많은 노력을 하시길 바랍니다.

자신의 노력이나 능력이 부족하다는걸 인정하시거나,
그런 말들이 듣기 싫으시다면 게시판에서 괜시리 푸념하지 마시고,
몇배 더 노력하세요.

- 야간비행.

수정.
잠금요청 했었는데, 철회할 수 있을까요?

The Feynman algorithm :

1. Write down the problem.
2. Think real hard.
3. Write down the solution.

-_-;;;

kslee80의 이미지

Quote:
책을 보면 깊게 들어가야합니다. 책자체가 깊게 들어가는 책이 많죠.
저역시 그런점에서 보면 폭넓은 지식이 필요할뿐이지 폭깊은 지식은 필요하지않습니다.
물론 필요하다면 그렇게 파고들어야죠.
다만 제가 궁금한것은 깊게파고들면 기존에 존재하는 지식이 무의미한체 새로운용어가
등장한다는거죠.

혹시, 책을 한번 보기 시작하면 끝까지 다 봐야 한다는 생각을 가지셨나요? (물론, 소설처럼 처음부터 끝까지 다 봐야하는것 제외)
특정 DB 나 DBMS 에 대한 책이 아닌, DataBase 자체를 다루는 책들은
보통 처음부분에서는 얕게 개념에 접근하고...
중간 이후부터는 각 부분에 맞게 깊게 들어가죠.
깊은 지식이 필요하지 않다면, 깊게 들어가는 부분 이후부터는 보지 않으면 되죠.

폭넓은 지식을 가진 사람들은
자신의 분야는 아주 깊게...
자신의 분야는 아니지만 관련이 있는 분야도 어느선 이상의 깊이를 가지고 있죠.
이러한 깊이는 어떻게 만들어 졌을지...

Quote:
그리고 개인적인 생각이지만 지식을 파는데있어서
어려운 책 특히나 영어책을 보는것에는 부정적입니다.

요즘에는 원서의 번역본들도 많이 나와 있습니다.
shineyhj의 이미지

영어책을 보는데에는 몇 가지 이유가 있습니다.
보통은... 번역이 되어있지 않다거나, 번역이 엉망이다거나, 아니면 영어에 익숙해지려고 한다거나... 하는 경우가 되겠습니다.

요즘은 좋은 책들이 번역이 많이 되어 있습니다.
당장 제 책장에 꽂혀있는 러닝 리눅스만 해도 번역이 상당히 잘 되어있기 때문에 굳이 원서를 살 필요를 느끼지 못한것이고요.

근데, 뭔가를 공부하다 보면... 처음에 언급한 세가지의 경우가 왕왕 생기기 마련입니다.
그런 경우에도 무조건적으로 번역서 없다고 배척하실건가요.

목마른 사람이 우물을 파는 법입니다.
근데, 더미님 글 보면 항상 다른사람들이 떠먹여주지 않아서 불만이라는 뉘앙스가 가득 풍깁니다.
하지만 그렇게 이야기를 하셔도 관심을 보이는 사람은 사실 얼마 되지 않을겁니다.

스스로 해결하려고 하면서 내공을 키우시길 바랍니다.
게시판에 묻기 전에 구글링도 해보시고, 주위의 서점이라든가 학교 도서관 같은데를 이용하는 방법도 있을겁니다.
광주에 계신다고 알고 있는데, 광주 같으면 전남대라든가 조선대라든가... 그런 큰 대학들도 있고,
기술서적이라면 GIST 같은 특성화된 좋은 학교에서 많이 구할 수 있으실겁니다.
그 학교 학생이 아니더라도 뜻이 있다면 열람할 수 있는 방법은 얼마든지 있습니다.

단언컨데, 지금과 같은 방식으로는 한계가 있고,
그리고 그런 방법으로는 지금까지 게시판에서 다른 분들이 보였던 부정적인 반응들 이외의 다른 반응들을 앞으로도 보기 쉽지 않을겁니다.

좀 더 내공을 쌓으시고, 다른 사람들과 토론을 하세요.
그동안 게시판에서 더미님 글 볼때마다 느끼는걸 보다보다 대놓고 말씀드리는겁니다.

- 야간비행.

The Feynman algorithm :

1. Write down the problem.
2. Think real hard.
3. Write down the solution.

-_-;;;

shjeun의 이미지

dummy999 wrote:
책을 보면 깊게 들어가야합니다. 책자체가 깊게 들어가는 책이 많죠.
저역시 그런점에서 보면 폭넓은 지식이 필요할뿐이지 폭깊은 지식은 필요하지않습니다.
물론 필요하다면 그렇게 파고들어야죠.
다만 제가 궁금한것은 깊게파고들면 기존에 존재하는 지식이 무의미한체 새로운용어가
등장한다는거죠.

쉽게 쉽게 생각하세요~ 너무 복잡하게 생각하면 머리아프잖아요 안그래도 머리아픈 세상

Database와 Database Management System을 햇갈려들 하는데.. Database 개론서 서점가서 1장만 보아도 나와요~!! 한글책도 많아요 깊게 들어갈 필요도 없는 내용입니다.

:-)

dgkim의 이미지

백엔드라는 용어는 전산에서 일반적으로 널리 사용되는 용어입니다.

데이터베이스는 위의 설명대로, 자료를 정리하는 방법입니다. 하지만 일상적인 대화에서는 프로그램자체를 지칭하기도 합니다.

백엔드 데이터베이스 프로그램이라 하면, 자료에 가까운 프로그램이라 볼 수 있고, 프론트 엔드 데이터베이스 프로그램이라면, 사용자에 가까운 프로그램이라 할 수 있습니다.

Access는 *.mdb라는 형태의 파일에 자료들을 저장하는 방법을 통해 효과적인 처리를 수행합니다.

그리고 Query, Form, Report에 해당하는 프론트 엔드 기능을 통해 사용자와 교류(?)합니다.

또한, 위의 각 기능이 간편한 확장성을 가지고 있기에, 일반 사용자가 마우스 클릭과 몇번의 타이핑 만으로 간단한 기능을 구현해서 사용할 수 있습니다.

반면, Oracle의 경우는 Frontend보다는 Backend에 치중을 하였고, 다중 접근과 같은 희얀한 접근 방법도 제공하며, 대량의 데이터 처리에 월등한 능력을 보여줍니다. 하지만, 사용자에게 친숙한(?) 인터페이스는 거의 제공하지 않으며, 접근을 위해서는 Todd같은 툴(?)을 사용해서 접근하고, 실제 업무에 적용될 시에는 Power Builder와 같은 것을 통해 세세한 프로그래밍 과정을 거쳐 사용합니다.

그밖에 미량의 데이터 처리는 일반 텍스트를 사용하거나, 임베디드 데이터베이스(?)를 사용합니다. 가깝게는 WMP(Windows Media Player)의 미디어라이브러리를 들 수 있습니다.

리눅스에서는 BDB와 같은 것이 사용될 수 있습니다.

dummy999의 이미지

인간의 뇌에있는 뉴런들은 어떤공식을 거쳐서 형성되는게 아닙니다.
단지 내가 필요하다고 자극을 주면 그쪽뉴런은 발전하고 그렇지않다라고하면 퇴화되죠.
결국 자신이 의도하지않지만 뇌라는 녀석은 정말 자기멋대로겠죠

뇌는 무작위로 받아들인다라는거죠..
그런다음 그것들이 뇌에서 화학반응을 일으켜 새롭고 더욱두꺼운 뉴런을 형성하는데
우리는 그것을 지식이라고 부르기도합니다.
뇌는 상당히 직관적이며, 충동적이고, 임의적(무작위적)이죠.

책이 필요한사람들에겐 필요하겠지만. 어디까지나 저도 필요에의해서 선택을 하는바입니다.

예전 공자전이란 애니가있었는데 거기서 이런말이 나옵니다.
사람들은 예절을 마음에서 나와 필요에의해 만들었는데 시간이 지나면 지날수록 그형식에만 연연해
지키느냐 지키지않느냐만 가지고 그것을 논한다라고요.

반드시 지식을 얻기위하여 어떤 공식을 밟는다는것은
예절을 지키느냐 지키지않느냐의 차이라고 생각되네요.
지식을 얻기위해 도서관을 찾거나 지식을 얻기위해서 책을 본다는것은
있을수도있는일이지만 없을수도있는일입니다.
다시말해 정형화된 공식이 아니라는겁니다.

그리고 DB와 DBMS를 몰라서 말하는게 아닙니다.
다만 그것을 어느시점에서 보느냐에따라 같은부류에 들어갈수도있고 다른 부류에 들어갈수있습니다.
반드시 물어본다하여 그부류에대한 원칙이 필요한건아니라고 생각합니다.

머리에서 지식을 받아들이고있는건 정말 직관적이라서
머릿속에서 필요한것만 받아들이고 그렇지않는것은 대부분 다 짤라버리는데
원칙을 고수해가면서 불필요한것까지 넣어서 손실을 남기는것보다는
훨씬 효율적이지않겠습니까?
저는 그렇게 생각하고있기때문에 필요한것들만 같이 공감하는 사람들에게 제의견을 말하는겁니다.

그리고 필요하다면 지식의 깊이도 파야겠죠.. 언제까지나 옆으로만 팔순없는격이죠.
그러나 그것도 어디까지나 제가 필요하다 느끼면 파야겠죠

필요하다면 이부분을 따로떼서 이야기하고싶습니다만..
원래 질문했던내용과 전혀 다른.. 내용으로 흘러가고있다는 판단이 되는듯..

제생각을 부가적으로 말씀드리자면
UI도 이런 직관적인점에서 설계되어야한다고 말씀드린적도있었던거같은..

정리하자면 지식에는 순서도 없고, 원칙도없으며, 생명력도 없다고 생각합니다.
뇌에서 받아들이는대로 순서가 정해지고, 원칙이 정해지며, 생명력이 정해지겠죠

그렇다보면 그런뇌를 잘이해한다면 그것이 필요로하는것들만 수집해주면 되는게
제가 할일이 아닐까요?

뇌를 너무 혹사시키고싶지않습니다.
인터넷으로 여기에 접근할수있는것만으로도 어떤책을 산것보다 큰 수확이라고 생각됩니다만.

---------------------------------------
dgkim님
프론트엔드와 백엔드의 설명은 와닫는듯싶습니다.
감사합니다.

------------------------------------
F/OSS bless you... ^^*

warpdory의 이미지

dummy999 wrote:
인간의 뇌에있는 뉴런들은 어떤공식을 거쳐서 형성되는게 아닙니다.
단지 내가 필요하다고 자극을 주면 그쪽뉴런은 발전하고 그렇지않다라고하면 퇴화되죠.
결국 자신이 의도하지않지만 뇌라는 녀석은 정말 자기멋대로겠죠

뇌는 무작위로 받아들인다라는거죠..
그런다음 그것들이 뇌에서 화학반응을 일으켜 새롭고 더욱두꺼운 뉴런을 형성하는데
우리는 그것을 지식이라고 부르기도합니다.
뇌는 상당히 직관적이며, 충동적이고, 임의적(무작위적)이죠.

책이 필요한사람들에겐 필요하겠지만. 어디까지나 저도 필요에의해서 선택을 하는바입니다.

예전 공자전이란 애니가있었는데 거기서 이런말이 나옵니다.
사람들은 예절을 마음에서 나와 필요에의해 만들었는데 시간이 지나면 지날수록 그형식에만 연연해
지키느냐 지키지않느냐만 가지고 그것을 논한다라고요.

반드시 지식을 얻기위하여 어떤 공식을 밟는다는것은
예절을 지키느냐 지키지않느냐의 차이라고 생각되네요.
지식을 얻기위해 도서관을 찾거나 지식을 얻기위해서 책을 본다는것은
있을수도있는일이지만 없을수도있는일입니다.
다시말해 정형화된 공식이 아니라는겁니다.

그리고 DB와 DBMS를 몰라서 말하는게 아닙니다.
다만 그것을 어느시점에서 보느냐에따라 같은부류에 들어갈수도있고 다른 부류에 들어갈수있습니다.
반드시 물어본다하여 그부류에대한 원칙이 필요한건아니라고 생각합니다.

머리에서 지식을 받아들이고있는건 정말 직관적이라서
머릿속에서 필요한것만 받아들이고 그렇지않는것은 대부분 다 짤라버리는데
원칙을 고수해가면서 불필요한것까지 넣어서 손실을 남기는것보다는
훨씬 효율적이지않겠습니까?
저는 그렇게 생각하고있기때문에 필요한것들만 같이 공감하는 사람들에게 제의견을 말하는겁니다.

그리고 필요하다면 지식의 깊이도 파야겠죠.. 언제까지나 옆으로만 팔순없는격이죠.
그러나 그것도 어디까지나 제가 필요하다 느끼면 파야겠죠

필요하다면 이부분을 따로떼서 이야기하고싶습니다만..
원래 질문했던내용과 전혀 다른.. 내용으로 흘러가고있다는 판단이 되는듯..

제생각을 부가적으로 말씀드리자면
UI도 이런 직관적인점에서 설계되어야한다고 말씀드린적도있었던거같은..

정리하자면 지식에는 순서도 없고, 원칙도없으며, 우선순위도 없다고 생각합니다.
뇌에서 받아들이는대로 순서가 정해지고, 원칙이 정해지며, 우선순위가 정해지겠죠

그렇다보면 그런뇌를 잘이해한다면 그것이 필요로하는것들만 수집해주면 되는게
제가 할일이 아닐까요?

뇌를 너무 혹사시키고싶지않습니다.
인터넷으로 여기에 접근할수있는것만으로도 어떤책을 산것보다 큰 수확이라고 생각됩니다만.

---------------------------------------
dgkim
프론트엔드와 백엔드의 설명은 와닫는듯싶습니다.
감사합니다.

별로 맞는 얘기는 아닌 듯 합니다.
몇가지 TRIZ 기법이라는 게 있습니다.
뭐냐 하면 러시아 과학자들이 인간의 사고하는 방법을 연구하여서 그것들을 정리한 겁니다.
정확히는 특허들을 수십만건 앞에 놓고 정리하여 그 속에 혼재된 법칙을 찾아낸 겁니다.

그것에 따르면 지식에는 순서도 있고, 원칙이 있으며 우선 순위도 있습니다. 어떤 걸 먼저 배우느냐, 어떤 방식으로 익히느냐, 그리고 어떻게 그것을 기억하느냐에 따라서 뇌에서 다르게 반응한다는 얘기고, 그것은 같은 시간에 같은 내용을 뇌에 입력시켰을 때 얼마나 효율적으로 뇌에서 정리되느냐.. 결국 얼마나 인간이 제대로 이해하느냐와도 연결됩니다.

마구잡이로 하고 싶은대로 한다고 그게 제대로 되는 게 아니라는 얘깁니다.


---------
귓가에 햇살을 받으며 석양까지 행복한 여행을...
웃으며 떠나갔던 것처럼 미소를 띠고 돌아와 마침내 평안하기를...
- 엘프의 인사, 드래곤 라자, 이영도

즐겁게 놀아보자.

notpig의 이미지

dummy999 wrote:
책을 보면 깊게 들어가야합니다. 책자체가 깊게 들어가는 책이 많죠.
저역시 그런점에서 보면 폭넓은 지식이 필요할뿐이지 폭깊은 지식은 필요하지않습니다.
물론 필요하다면 그렇게 파고들어야죠.
다만 제가 궁금한것은 깊게파고들면 기존에 존재하는 지식이 무의미한체 새로운용어가
등장한다는거죠.

궁금 한게 있는데요~
이 분야를 전공으로서 공부하시는건지
아니면 그냥 교양 으로서 공부하시는 건지 궁금합니다.
전공으로서 공부하시는 거라면 좀더 깊게 들어가야 하고
교양 수준으로 공부하시는 거라면 약간만 더 깊게 들어가면 됩니다.

개인적으론 대학교 혹은 다른 교육 기관에서 관련 강좌를 들어보길 추천 합니다~
책보단 쉽고 인터넷에서 접하는거보단 체계적으로 알려줍니다.

meteors의 이미지

dummy999 wrote:
다만 제가 궁금한것은 깊게파고들면 기존에 존재하는 지식이 무의미한체 새로운용어가
등장한다는거죠.

DB와 DBMS는 분명차이가 있습니다.
그러나 그것을 달리보겠다는것은 하나하나 집어보겠다는 말과같습니다.
transaction, job, task, process를 달리보겠다는 말과 비슷하다고 생각되네요
물론 약간의 어감은 틀립니다. 그러나 그것들이 근본적으로 지칭하는바는 같지않겠습니까?
마찬가지로 DB와 DBMS가 똑같을수도 틀릴수도있는건 시각차라고 생각됩니다만..
같다고 보는사람은 큰틀에서 DB라고 말하는 바이고
다르다고 보는 사람은 데이터베이스 개념적인면에서 봤을때의 차이를 말하는거겠죠.
위에서 말씀드렸듯이 깊은 지식은 필요할때가 있을때 접근하도록 하겠습니다.

사전이 있고 사전에서 단어를 정의하는 것은 정확한 의미를 알고 사용하도록 하기 위함입니다. 모든 사람들이 자신만의 해석으로 단어의 뜻을 이해한다면 의사소통이 불가능해집니다.

우리나라에서 특히 DBMS, database, database system의 의미가 모호한 것은 통칭해서 다 database로 말하기 때문입니다. 또 새로운 기능들이 나옴에 따라 기존의 개념들이 달라졌기 때문이기도 합니다. Excel file, XML file은 예전에 database라고 부르기 어려웠지만 지금은 불러줄 수 있습니다. DBMS에서 접근이 가능해 졌기 때문이죠.
(영어 사전도 마찬가지로 10년에 1번은 바꿔줘야 한다고 하죠)

DBMS, database, database system는 task, job 수준의 원초적인 모호성을 가진 것이 아니라 우리나라에서만의 모호성일 뿐입니다. 같은 것을 지칭하는게 아니라 포함관계가 명확한 것이기 때문이죠. 자동차와 바퀴의 관계를 보면 바퀴는 자동차의 부품입니다. 또 자동차와 엔진의 경우도 마찬가지입니다. 하지만 엔진이나 바퀴를 바꾸어서 사용할 수는 없습니다.
database system은 DBMS, database를 다 포함하지만 DBMS를 database라고 할 수 없고, database를 DBMS라고는 할 수 없습니다.

pynoos의 이미지

어떤것을 데이터베이스라고 하는지는 책을 읽어보면 쉽지만,
사실 혼자 공부하는 것은 바로 앞에 두고도 어려운경우가 많습니다.

아마 혼란스러운 것은
시장에서 흔히 사용되는 데이터베이스라는 용어가 가지는 위치때문이라 생각됩니다.

데이터 베이스는 전문적이지 않은 위치에서 의논할 때는 말그대로 데이터를 저장할 수 있는 모든 파일 혹은 서버라고 얘기할 수 있고,
전문적인 위치에서는 과연 이 프로그램이 데이터를 어떻게 저장/가공/선택할 수 있도록 지원해주느냐라고 생각할 수 있습니다.

세상에 수 많은 프로그램들이 데이터를 가공하는데 사용되므로 하나만 있으면 이런 질문도 나오지 않았겠지요.

mirr의 이미지

오로지 공감대(시각, 사상, 지식등)를 가지고 있는 사람들만의 답글을 원하셨던 것이라면
dummy999님의 사고가 약간 편협한 태도를 지니고 있다고 할 수 있을것 같습니다.

애초에 dummy999님의 접근 방법이 혹은 글이 약간 잘못짚었다는 것들을
사람들은 말씀해 주셨던것 같습니다.
Access도 디비에 들어가야 한다고 하셨던말이라든가, Access류와
Mssql류 Oracle류 이렇게
구분하셧던 점도 약간 논쟁의 소지가 있었습니다.
어차피 모두 Database의 효율적 관리와 작성을 위해 만들어진 도구입니다.

Msword가 워드프로세서이고, 한글, 훈민정음 등또한 모두 워드 프로세서이듯이 말입니다.

게다가 비베와 파워빌더 등까지 DB 관련 프로그램으로 구분해 버린다는것도
잘못된 듯 합니다.

C언어나 파이썬, VC++, VC.net 등 프로그래밍 관련 언어에 관한
통합개발툴을 사용하여 생성된 DB 프로그램, 혹은 그 DB 관련 프로그램
들을 지원하는 다른 플러그인 혹은 Addon 프로그램, 혹은 기타 매크로
등이 작성됐고, 그걸 사용하고 있다고 해서 VC, gcc, .net 등등을
DB관련 프로그램이라고 분류하는것은 엄연히 잘못인식 하고 있는 것입니다.

위에 여러 분들은 그런것들에 대해서 지적해 주신듯 하고,
dummy999님께서 이렇게 잘못 접근하게 된 원인은 기초적인 개념이
부족해서라고 생각하시고 도움이 되고자 답변해 드린듯 합니다.

뇌의 구조를 백프로 해독해낸 과학자들도 없고,
실제로 그 연구결과가 백프로 맞는지 틀린지는 장담하지 못하는 바 아닙니까? (사실 모르겠습니다 ㅡ,.ㅡ::)

다른 분들의 답글에 그렇게까지 과민반응 보이시는것은 좀 이해가 안가는 점이며,
너그럽게 받아들이시고, 자신의 생각이 잘못될 수도 있다는 것을
인식하셨으면 해서 글좀 올려봤습니다.

내 마음속의 악마가 자꾸만 나를 부추겨.
늘 해왔던 것에 만족하지 말고 뭔가 불가능해 보이는 것을 하라고 말야.

litdream의 이미지

데이터 베이스가 무엇인가 에서 출발해서, 뉴런이며, 지식접근방법까지
나오는군요. 저도 잠금에 한표!
( KLDP 들어와서 처음으로 잠금에 표던집니다. )

삽질의 대마왕...

정태영의 이미지

잠금에 한 표 추가... -_-;;

오랫동안 꿈을 그리는 사람은 그 꿈을 닮아간다...

http://mytears.org ~(~_~)~
나 한줄기 바람처럼..

ㅡ,.ㅡ;;의 이미지

깊게 알기는 싫고 얕게 알아서 어디에 써먹게요?

차라리 모르는게 낮습니다.

간혹 용어만 알아와서 떠드는사람이 개발자 잡는걸 보거든요..


----------------------------------------------------------------------------

mania12의 이미지

오라클이나 Sybase, MS-SQL, DB2 같은 DBMS 들은 현대 IT의 총아입니다. 어떻게보면 OS보다 더 복잡한 분야입니다.

예를 들어 우리가 SQL로 무엇을 원하는지 질의를 주면 옵티마이져가 최적의 경로를 찾아서 결과값을 돌려줍니다.
실재로 우리는 HOW에 대해서는 아무런 언급도 하지 않아도 말이죠. SQL에는 어떤 순서로 어떤 인덱스를 타서 어떻게 꺼내오라는 이야기가 없습니다. 어떻게 보면 옵티마이져가 인공지능에 근접한 가장 복잡한 두뇌에 해당하는 부분이라고 볼 수도 있습니다.

그리고... DBMS를 단순히 Data를 넣고 저장하고 필요하면 꺼내오는 운영시스템이라고 보는 것은 불합리 합니다.
DBMS에 관심이 있어서 건드려보신 분들은 아시겠지만... DBMS에서 Procedure언어나 Java, Pro*C 같은 전처리기까지 제공을 합니다. 단순히 Data뿐만 아니라 개발환경까지 제공해주므로 어떻게 보면 개발환경이라고 까지 볼 수도 있습니다.
오라클의 경우 아파치 웹서버를 아예 내장하고 있고 원한다면 PL/SQL로 웹스크립트까지 구사가 가능합니다. 별도로 WAS의 도움이 받지 않고서도 말이죠.

또한 네트워크 프로토콜도 TCP/IP만 지원하는게 아니라... 대단히 많은 프로토콜을 지원하기 위한 벤더 나름대로의 추상층을 가지고 있으며... 보안을 위한 DES, 3DES, AES, RSA RC4 같은 다양한 보안 Encryption도 제공하고 있습니다.
(DNS같은 자체적인 names server도 제공하고 있습니다.)
인증도 커버로스나 NIS, 노벨네트웨어, 엑티브디렉토리 같은 인증도 제공하고 있구요. 네트워크 부분만 하더라도 굉장히 복잡합니다.
요즘 나오는 DBMS들은 ID/PASS 가 아닌 지문인식장치를 통한 인증 기능까지 지원한다는거 아십니까?

거기다 가용성을 높이기 위해 클러스터 기술이나 DR(장애복구) 솔루션까지 갖추고 있으므로 더더욱 IT의 총아라고 부를 수 있습니다.
백업 및 복구는 아주 기본적인 기능이구요.

엑세스 같은 DB야 파일 기반이니 그냥 파일 복사하면 백업이라고 볼 수 있지만... 은행 같은데서 사용하는 대단위 동시접속 시스템에서는 초 단위의 트랜잭션 조차 보호되어야 하거든요.
1초, 1분 전에 거래 내역까지 장애나면 모조리 복구가 가능해야 합니다. 이걸 Point In Time Recovery 라고 합니다.

특히 E.F 코드 박사의 관계형 이론에 따라서 만든걸 RDBMS 즉, 관계형 DBMS라고 하는데... 최근에는 OO기능을 추가한 ORDBMS죠. 거기에 XML기능까지 흡수해서 이미 지원하고 있습니다.

거기다 각종 보안 기능이나 감사(Auditing)기능까지 갖추고 있답니다. 예를 들어 제가 인사 DB에 접근해서 임의로 옆에 동료 직원 철수의 연봉이 얼마인지 볼 수 없어야 합니다. 오직 제것만 조회가 가능해야죠. 이런걸 이미 DBMS차원에서 Row Level Security 기능으로 제공하고 있습니다.

최근 오라클 버젼 같은 경우 ... 아예 클러스터를 위한 자체 파일시스템을 제공하거나... LVM같은 기능까지 아예 흡수하고 있습니다. DBMS가 OS의 영역까지 넘보는 것이죠.

아주 방대한 분야고 평생 공부해도 안되는 분야입니다.

단순히 말 장난 몇마디로 간과하고 넘어갈 분야가 아닙니다. 전산학에서도 데이터베이스 쪽은 별도의 학문으로 치는 이유가 그것이죠.

물론 그 정도 수준까지 하라는 이야기는 아닙니다. :lol:
하지만 아주 기본적인 이해도 못한 상태에서 피상적으로 떠드는 것은 본인에게도 아무 도움이 되지 못합니다.

제트기도 사람이 타는 것이고 자전거도 사람이 타는 것이라고 해서 둘 다 똑 같은 운송수단 아니냐고 말하는 것과 비슷합니다.

dgkim의 이미지

글을 잠궈달라는 욕망이 좀 있는데..

뭐가 문제였나요?

dummy999의 이미지

오라클의 제품군들에대한 설명좀부탁드립니다.
구체적인 설명이있는 사이트들이 없네요
오라클 솔루션을 구입하면 아래와같은 프로그램이 딸려나온다는거겠죠?

레포츠 (레포트도구 = 크리스탈레포트와 비슷한걸로 판단)
디스커버러 (데이터 웨어하우징 도구) - 차트나 그래프를 그릴수있음, 쿼리, 리포팅, 분석 할수있다고함.
스프레드쉬트 에드인 - 기능인지 몰라도 스프레드쉬트로부터 오라클의 제품도 읽을수있게한것같음
웨어하우스 빌더 -?
BI 빈즈 - ?
기타 제가알기로는 디벨로퍼도있고 익스프레스도 있다고 하던데 써보지않는 저로서는
이것들이 뭐하는 프로그램인지 잘모르겠습니다.
구성이 어떤식으로 되어서 어떻게 판매하고있는지.. 그런 구조에대해서말입니다.
1. 오라클 제품에대한 설명좀부탁드립니다.

참고 ::
http://news.naver.com/news/read.php?mode=LSD&office_id=098&article_id=0000036180&section_id=001&menu_id=001

darkschutepen wrote:

혹시 토드나 그런데 스키마 브라우저나 그런데 안들어가 보신거는 아니시죠...?그리고 토드나 SQL게이트나 왠만한 간단한 쿼리는 자동으로 만들어 줄텐데요...쿼리 문법 기능이나 그런거는 확실히 엑세스의 그것보다 토드나 SQL게이트가 훨 낫습니다.

오래전일이라 기억이 안나지만 제가 기억하기로는 엑세스처럼 관계도를 그려주는 화면은 없던걸로 기억합니다.
물론 테이블설계같은것은 있었던거같았는데.. 그래서 그때 엑세스같은기능을 찾으려고
관련프로그램들을죄다 받아본적이있었는데 대부분 없었던거같습니다

2. 엑세스에는 VB를 프로시져작성도구로 사용하는데 다른 DB들은 어떤언어를 이용해서 프로시져를
작성하나요?

3. 아쿠아DB스튜디오라는 프로그램이나 토드같은거 상용인데 솔직히 FM대로하면 사야하고
그거 구하기도 힘들거같은데 비상용중에서 구하기쉽고 제가말하는 기능들(엑세스의 관계편집등이
GUI로 죄다 구현되는것)이 구현된 프로그램이 어떤게있을까요?
또 상용제품중에도 설치및 활용에있어서 복잡하지않는 인터페이스를 가지고있는 프로그램좀 알려주세요.

4. 스키마브라우져에대한 화면을좀봤음합니다.
따로 캡쳐해놓은 사진을 찾기힘들더라구요.

------------------------------------
F/OSS bless you... ^^*

다크슈테펜의 이미지

dummy999 wrote:

(적어도 제경험상 sql게이트나 토드같은것도 GUI라면
엑세스와비슷한 인터페이스의 관계편집, 쿼리편집 기능정도는 구현되어야한다고생각됨.)

혹시 토드나 그런데 스키마 브라우저나 그런데 안들어가 보신거는 아니시죠...?그리고 토드나 SQL게이트나 왠만한 간단한 쿼리는 자동으로 만들어 줄텐데요...쿼리 문법 기능이나 그런거는 확실히 엑세스의 그것보다 토드나 SQL게이트가 훨 낫습니다.
Quote:

오래전일이라 기억이 안나지만 제가 기억하기로는 엑세스처럼 관계도를 그려주는 화면은 없던걸로 기억합니다.
물론 테이블설계같은것은 있었던거같았는데.. 그래서 그때 엑세스같은기능을 찾으려고
관련프로그램들을죄다 받아본적이있었는데 대부분 없었던거같습니다

그냥 비지오나 그런데서 디비 설계해가지고 리버스 앤지니어링을 이용해서 집어 넣으면 되던데요...그리고 래셔널 로즈 같은 경우에도 UML로 클래스 다이어그램 그려서 디비에 집어 넣는 게 가능한 걸로 알고 있습니다.
그리고 전에도 이문제 가지고 한번 쓰레드 여신적이 있지 않았나 합니다.자신에게 필요한툴은 찾아 보시면 있을겁니다.더미님께서 말씀하신 기능 같은 경우에는 이클립스 플러그인으로도 몇개 본것 같습니다.한번 그쪽으로 찾아 보셔도 좋을 듯합니다.
스키마 브라우저 같은 경우에는 토드를 실행하시고 디비 접속하신다음에 상단 메뉴바를 훝어 보시면 있을겁니다.그리고 액세스에서는 쿼리 인텔리 센스기능같은 거 없지 않나요...?

인생이란게 다 그런게 아니겠어요....? 뭘(?)
http://schutepen.egloos.com

codebank의 이미지

음...

제가 볼 때에 dummy999님의 질문은
'DB라는 것이 있는데 MySQL도 DB라고 불리우고 Access도 DB라고 불리는데 차이점이 무엇이냐?'
이것 아닌가요?(결국 존재의 의미니까...)

만일 위의 질문이라면 여러명이 사용할 것인지 한명이 사용할 것인지의 차이라고
말하고 싶습니다. 내부적으로 들어가면 복잡하고 알지 못하는 용어를이 마구마구
뒤섞여서 많이 헷갈려서 저도 머리가 혼돈되는데...
일단 제가 이해하고 있는 수준은 단지 저 수준입니다.

결론적으로

다수의 사람이 이용하는 DB : SQL 서버
PC급에서 단 한명만이 사용 : Access나 DB3 같은 DB

라고 생각합니다.

------------------------------
좋은 하루 되세요.

지리즈의 이미지

사실, SAM파일나 ISAM이나
혹은 구조체를 순차적으로 파일로 저장해서,
seek로 잃어 들이는, 로우레벨적인 접근이나,
혹은 CSV파일이나,...
다 db의 범주에 속하겠죠.

그런데... Excel은 어떻게 보십니까?

묘한 놈이라는 생각이 드네요.

There is no spoon. Neo from the Matrix 1999.

다크슈테펜의 이미지

지리즈 wrote:
사실, SAM파일나 ISAM이나
혹은 구조체를 순차적으로 파일로 저장해서,
seek로 잃어 들이는, 로우레벨적인 접근이나,
혹은 CSV파일이나,...
다 db의 범주에 속하겠죠.

그런데... Excel은 어떻게 보십니까?

묘한 놈이라는 생각이 드네요.


지금 코딩상에서 엑셀 문서 다루는 일을 조금 하고 있는데
처음에는 그냥 컴포넌트 없이 할려고 하다 보니 나중에는
엑셀 문서에 쿼리를 때려서 데이터 집어 넣고 불러오는 게 가능하다고 하더군요 약간 경악을 했지요...@0@ 모든 오피슨 문서는 아마 쿼리 때려서 데이터 집어넣고 그런게 가능하지 않을 까 생각도 해봅니다(안돼면 말고...)

인생이란게 다 그런게 아니겠어요....? 뭘(?)
http://schutepen.egloos.com

codebank의 이미지

Excel파일자체는 DB라기보다는 TABLE이라고 보는게 나을것 같습니다.
데이터의 구분도 ','나 탭으로 변환이 가능하고 내보내기나 들여오기등을 볼 때는
일정한 규칙만 있으면 나름대로 Excel 포맷에 맞도록 수정을 봐주니까요.

다만 Excel이라는 프로그램은 데이터관리를 내장한 응용 프로그램이라고 생각합니다.

darkschutepen님이 말씀하신 부분은 COM인가로 빼놓고 규칙에 맞게
호출을 하면 가능한것로 알고 있습니다.

------------------------------
좋은 하루 되세요.

jongwooh의 이미지

지리즈 wrote:

그런데... Excel은 어떻게 보십니까?

묘한 놈이라는 생각이 드네요.

스프레드쉬트종류는 데이터베이스라기보다는 lazy evaluation 다중 그래프 알고리즘에 2차원 어레이형 UI를 매핑시킨 고급형 계산기입니다.

스프레드 쉬트도 소트,서치가 가능하긴 합니다만 데이터베이스와는 다른 기법입니다.

예를들어 RDBMS는 레코드 순서는 따지지 않지만 컬럼 순서는 따지며, 소트/서치는 버티컬(즉 레코드 셋)에 대해서만 가능합니다. 그에 비해 스프레드쉬트는 로우나 커럼 어느쪽으로도 연산이 가능합니다. (자료구조가 R*트리가 아니라 내부적으로 어레이/그래프이므로)

그대신 RDBMS는 구현따라 레코드 숫자가 거의 무한으로 가능하지만, 스프레드쉬트는 개념 구현의 제약상 정해진 크기에서만 연산이 가능합니다.

아뭏든 내부 구조를 생각해보면 그다지 스프레드쉬트 프로그램들이 묘한것은 아닙니다. 다만 RDBMS의 2차원 테이블 표기와 스프레드쉬트의 UI가 같아서 서로 비슷한게 아닌가 하고 착각들을 하시는데... 구현 원리,한계와 성능에서는 확실하게 서로 차이가 나는 소프트웨어들이죠. :wink:

you must know the power of dark side.

alwaysN00b의 이미지

잠금 +1

언제나 시작

Prentice의 이미지

검은해
litdream
정태영
alwaysN00b
잠금에 네 표 나왔습니다.

다크슈테펜의 이미지

while(1)
{
잠금++;
}

인생이란게 다 그런게 아니겠어요....? 뭘(?)
http://schutepen.egloos.com

dummy999의 이미지

codebank님
그게 궁극적으로 맞는데요. 님의 답변을 보니까 갑자기 생각나는게 잇습니다.
엑세스에서도 mdb파일을 쓰는데 그걸 MSSQL도 쓰더라구요/

그렇다면 이런경우엔 데이터파일만 공유하는 구조라고 할수있을까요?
뭐 MYSQL의 데이터파일을 다른데서 공유하는데가 없으니..
저로서는 잘모르겠군요..

엑셀은 참 오해의 소지가많습니다. DB는 아닌데 dB같은 기능은 다합니다.
적어도 엑세스에서 하는건 대부분 따라하죠. 뭐 관계같은거빼고말이죠.

그런데 엑셀과 SPSS,sas 이런 통계계산한다는..뭐 그런프로그램류와 형태는 비슷하게 생겼드라구요
그렇다면 이건 같은 스프레드쉬트로 분류되어야 당연할까요?
그런데 spss같은걸 스프레드쉬트라고 부르진않았던거같은데..

스프레드쉬트(엑셀경우)
쉬트하나가 테이블 하나가 될수있습니다.
적어도 테이블겸 폼이되겠지만.. (테이블에서 컨트롤러를 붙여넣을수있음)

--------
제가 이걸연것은 모호하게 알고있는것을 정확하게 알고자하는겁니다.
이게 정확하게 어떤구분에 속하는지말이죠.
그렇게하기엔 상당히 모호한면이 많습니다.
추세가 그럴수밖에 없게 흘러갑니다.

누군가 Winamp보고 mp3플레이어라고 한다면 예전엔 맞을지몰라도 지금은 틀립니다.
그렇다면 이런유형은 더이상 음악플레이어로 구분되어선안될꺼같습니다.

그래서 매체재생기나 미디어플레이어 같은 통합된단어를 쓰면좋겠군요.

DB도 마찬가집니다.
DB니 DBMS니 하는건 관점에따라 달라지게 분류되지만 이젠 그의미가 거의 모호해지지않을까싶습니다.
요즘나오는 모든 DB들은 DBMS를 기본적으로 지원해야하죠. 아니면 안쓰니까요.
그렇게하면 DB의 표준사양도 DBMS라고 봐야할수있지않을가요?
물론 그렇게하기엔 dB자체가 추상명사라서.. 어디다 한정시키기엔 너무 큰개념이지만..

그런개념은 복잡하지도않지만 어떤책에도 나와있지않습니다.
설령나와있더라도 상당히 주관적이겠져
왜냐면 지금 우리도 이렇게 이런내용으로 말이 많은데 누구개인의 생각으로 이건뭐다라고하기엔
지금 씨츄레이션에서는 어패가 많습니다.

자바를 배울때였을땐가?
거기에 추상클래스라는 개념을 첨봤습니다.
저는 첨에 이게 왜필요했는가라는게 상당히 궁금했습니다.
그다지 알고보면 기능도없는 클래스인데 이걸 왜만들었는가 생각해보니까.
어렴푸레 그개념을 알겠더라구요.

무엇이되었던지간에 구체적인 물체가 있으면 추상적인 물체로 그것을 그룹짓는것.
아마도 그런 의미로 사용되지않았나 생각되었습니다.
사람한명만있으면 그사람이름 = 사람의 전체명사가 되겠지만 두사람이상이면 적어도 사람의이름이
둘을 지칭하는 용어는 될수없듯말입니다.

큰개념일수록 정말 추상적인부분이 많다는걸 느낍니다.
그럴수록 깊게가는것보다는 넓게가서 그것이 어디까지 영향을 미치는지를
알아야할필요가있다고 생각됩니다.

자기가 플그램을 만드는데
1. 어떤부류에 속하며 그부류에는 어떤기능들이 필요하다라는게
사전에 지식으로 남아있고
2. 그걸 구현하기위해서는 어떤식으로 해야한다라는것..

적어도 스킬이라는것은 2번의 경우가 아닐까생각됩니다.
그리고 1번은 기본지식이고요.
2번안에서 설계와 코딩이 있을것이고 이모든것은 경험속에서 나오는 스킬이필요하겠죠.

제가 그간 플그램을 멀리해왔는데 이런 개념때문이었습니다.
한프로그램의 기능을 파악하기위해서 몇번이나 깔고 지우고를 반복했죠.
그렇게하면서 컴터 수십번 밀어봤고. 그래도 지금도 다모르겠더라구요.

IT를 잘하기위해서 책을 많이 읽어야한다면 책만봣을껍니다.
IT를 잘하기위해서 코딩이나 설계같은것이 필요하다면 아마 진작 거기에 파묻혔을껍니다.

아직은 잘모르겠지만 제생각에는 그것만으로는 부족할꺼같습니다.
적어도 그런 마인드에서 자기가 개념정도는 확신할수있다는 그런게 있어야한다는것도
IT를 잘하기위한 방법중에 하나가아닐까 생각합니다.

이게 제 공부방향이고, 제생활이되버렸네요.
제생각에는 이런게 처음시도되는것이라고 생각됩니다. (물론어디까지나 제생각임)
왜냐면 사람들의 의견이 무수히 많기기때문입니다.
그만큼 이부분이 취약하다는 생각이듭니다.

언제까지나 안개속을 걸어다닐수없습니다.
정확하지않는걸로 대충때려맞추고 클론 소스를 사용하고
하는것은 정말위험하다생각합니다.

적어도 뭔가 명확한 개념(표준)이 있어야 그것의 흐름도 정확한 IT로서 활용가치가있다고 생각됩니다

------------------------------------
F/OSS bless you... ^^*

pool007의 이미지

jwhan wrote:
예를들어 RDBMS는 레코드 순서는 따지지 않지만 컬럼 순서는 따지며, 소트/서치는 버티컬(즉 레코드 셋)에 대해서만 가능합니다.

RDB에서는 레코드 순서 뿐만 아니라, 컬럼 순서도 따지지 않습니다.

우리가 흔히 구현 레벨에서 테이블이라고 말하는 것은, 사실 RDB 이론에서는 relation 이라고 부르죠. 그리고 relation 은 set of k-tuples 입니다. k-tuples 는 (속성명, 속성값)의 pair가 k 개 있는 set 을 말합니다. 그래서 개별 행에서 각각의 속성의 순서라는건 존재하지 않습니다..

사실은 이건 정의하기 나름입니다만, (예를들어 Navathe 가 쓴 데이터베이스 책에서는 컬럼 순서가 중요하다고 정의했다가 다시 컬럼 순서가 중요하지 않은 정의, 이렇게 2개를 제시하죠) 흔히 이야기하기로는 컬럼에는 순서같은건 없습니다.

--
Passion is like genius; a miracle.