Postgre SQL의 성능을 알어보니 상용DB와 별차이가 없네요
넘 좋은것 같아요 그래서 사용해볼까합니다
궁금한것은 생산관리에서 필요한 BOM정보를 오라클에서 connect by를 써서 불러오는것처럼
하는 방법은 없나요
없다면 프로그램으로 구현을 해야겠네요
답좀 주세요
BOM 이놈이 뭔지요?
BOM : 빌드 오브 메트리얼 ( 영어가 짧아서리 -_-;)
질문의 요지는 모자 관계에 있습니다.
예를 들어
모코드 코드 모델명
0001 0002 엔진
0002 0019 피스톤
0002 0030 배관
0019 0040 고무파킹
이렇게 된것을
엔진(0레벨)
- 피스톤(1레벨)
- 고무파킹(2레벨)
- ....
- 배관(1레벨)
이렇게 표현이 가능한가에 대한 질문 입니다.
답변부탁드려요... ^-^
윗 문제는 Table return function 이라는 개념으로 풀 수 있습니다.
참 대단하네요
여하튼 postgreSQL로 정해도 되겠네요
넘 좋다...ㅋㅋㅋ
실업무가 C/S 환경으로 움직이고, Client 쪽이 M$ 동네쪽에서 ODBC로 움직일 요량이라면, PostgreSQL ODBC 사용에 대한 테스팅을 충분히 하시길 바랍니다. PostgreSQL ODBC가 PostgreSQL 서버 기능을 완벽하게 충족시켜주지 못하기 때문입니다.
원인은 M$ 동네쪽 ODBC 규약자체가 PostgreSQL의 확장된 기능을 모두 흡수하지 못하는 것이 가장 큰 원인이기도 하고, 게다다 PostgreSQL 응용프로그램 개발자들도 일치감치 ODBC 쪽에 기대를 걸지 않고, libpq 인터페이스 API로 direct connection 을 사용해서 개발하기 때문에 ODBC쪽 개발이 서버 개발속도를 못 따라가고 있는 것이 현실입니다.
중요한 것은
그냥 단순한 자료구조 - 일반적인, 범용적인, 전통적인 자료구조와 프로그램 설계라면, 현재 제공되고 있는 ODBC로 충분하겠지만, PostgreSQL 고유의 꽤 괜찮은 기능들을 ODBC를 사용해서 뭔가 해보겠다면, 꽤 꼼꼼하게 테스트를 해보시고 실무에 사용하실 바랍니다.
개인적으로 PostgreSQL 사용자층이 얇은 이유가 바로 평범한 것이 머물지 않는 PostgreSQL의 도전정신(?) 때문이 아닐까싶습니다. :)
그냥 일반 사용자를 생각해서 무난하고 튼튼하고 빠르게 만들면 될 것을 괜히 일반사람들은 관심도 안가지는 온갖 기능들을 제공하면서 오히려 일반사용자에게 혼돈만 부과시키는 것이 아닐까? 하는 생각도 가끔은 해봅니다.
