해보진 않았는데요.. 
그냥 순환문을 돌려서 CREATE DATABASE해보세요. 
그렇게 DATABASE를 구성했을 때의 효율이 먼지 모르겠네요. 

보안이라면 어떤걸 이야기 하시는 건지... 
어짜피 디비로 접근을 했다고 하면 db에 접근이 된상태이거늘 
어찌 그게 디비로 나뉘어져 있다 하여 보안이 높아진거라 할 수 있을까요?

아;; 만약 한 데이터베이스에

만약 테이블이 [USERID_주문서] 테이블일 경우 디비 권한이나. 프로시저에 오류가 있을 경우

다른사용자의 데이터가 나올까봐요..  글케대믄 대략 난감 ㅡㅡ;;

테이블로 만들면 디비 권한으로 다른 테이블도 접근이 가능하니까요.

시스템 권한이 아니라 다른 디비를 컨넥션 하지 못하니 그게 더 안정적인가 해서 여쭤보는것 입니다 ^^;;

[홈쇼핑_주문서], [디비사랑_주문서]

[홈쇼핑].[주문서], [디비사랑].[주문서] 요 차인데요..

우선 권한을 나눌수 있으면 상관 없기는 하지만 문제가 될 소지를 미연에 방지하는 의미에서는 DB를 나누는 것이 좋습니다. 

하지만 그렇게 할 경우에 DB 관리가 힘들어 지는 경우가 있죠...

제 생각에는 하나의 DB에서 table만 나눠서 쓰신다면 별 무리가 없어 보입니다. 

단 중간에 프로시져 하나 두셔서 그 프로시져에서 사용자 ID 별 검색 table을 틀리게 하는 것이 더 효과적이겠죠^^

그냥 제 생각 입니다. ~~~

그럼 수고하세요 ~~

제가 이해를 정확히 한 건지는 모르지만 아마도 업체마다 따로 따로 주문서를 관리하려고 하시나 보네요. 만약 공통적인 부분(상품과 주문 모두)이라면 제가 보기엔 주문은 하나의 테이블로 통합하고 업체구분 필드를 주어서 업체를 구분하면 될 것 같구요. 각 업체는 주문테이블로 바로 접근할 수 없고 각 업체에 맞는 주문테이블 뷰를 생성하신 다음에 해당 뷰만 접근할 수 있는 사용자를 추가하는게 나을 것 같습니다. 그래야 전체 주문을 볼 수 있고 관리하는 것도 쉬울 듯 한데요. INSERT나 UPDATE는 프로시저를 이용하면 될 듯 합니다. 어떤 특정 고유값을 둬서 매개변수로 받아 처리하시면... 수고하세요~

네!! 답변 주신분들 모두 너무 감사합니다. ^0^