게임 DBA 를 하다보면 이벤트 관련한 쿼리 제작을 많이 하게 됩니다. 

보통의  [이벤트 대상자 추출] -> [대상자 들에게 상품 지급]  구조로 쿼리를 작성 하시게 되는데요 

이벤트 대상자를 산정하는 로직이 복잡 하거나 상품 지급 로직이 복잡 해지게 되면 쿼리가 길어지게 되고 그로인해 버그가 발생할 확률이 올라 갑니다.

그걸 방지하기 위해서 쿼리도 모듈화를 많이 하게 됩니다.

위 경우는 크게 [이벤트 대상자 추출] , [아이템 지급] 두개의 sp로 나눌 수 있습니다. 그때 sp간 자료 공유를 위해  쿼리에서 select into로 물리 테이블을 만들어 사용하시는데 그럴 필요 없이 지역 임시 테이블을 사용 해도 동일하게 구성할 수 있습니다.


대상자 추출 sp 입니다.


  CREATE proc [dbo].[sp_temptable_send] (  

@command Varchar(5)

  , @o_ret int out

  )

  as

set @o_ret = -1;

--다른 sp와 공유할 임시 테이블 생성 

create table #tmp_user( name varchar(30));

insert into #tmp_user(name) values (CONVERT(varchar(30),GETDATE(),21));

exec dbo.sp_temptable_receive 'test', @o_ret output; --호출 당한 sp에서 임시테이블의 정보를 select 

--지역 임시 테이블은 Procedure가 종료되면 자동으로 삭제됨 

--drop table #tmp_user;

return; 



상품 지급 sp


  CREATE proc [dbo].[sp_temptable_receive] (

  @command Varchar(5)

  , @o_ret int out

  )

  as

  set @o_ret = -1;

  --호출측 과 약속한 임시테이블에서 데이터를 꺼냄

  insert into [dbo].[tbl_test](cname) select name from #tmp_user;

  set @o_ret = @@ROWCOUNT;

  return;

 


대상자 추출 sp에서 대상자와 상품을 매칭 시켜 임시테이블에 담아 놓으면

상품 지급 sp에서는 해당 명칭의 임시테이블에서 정보를 가져와 실제로 상품을 지급하는 동작을 수행 합니다.

상품지급 sp를 생성할 때 임시테이블의 유무는 검사하지 않기 때문에 

상품지급 sp를 미리 만들어 놓고 약속된 임시테이블을 대상자 추출 sp에서 생성한 후 상품 지급 sp를 호출하여

정상적으로 상품을 지급할 수 있습니다.


위와 같이 하면 변하지 않는 상품 지급 sp는 한번만 만들어 놓고 검증까지 완료해 놓으면 매번 이벤트 때마다 상품 지급이 정상적으로 되었는지 

검증할 필요가 없어 집니다.

읽어 주셔서 감사합니다.



위 주제 관련 혹은 DB에 관련하여 토의하고 싶으신 내용이 있으시면 댓글 남겨 주세요.^^

요즘 Dremel 8220 을 눈여겨 보고 있습니다. 그러면서 자연스레 많은 액세서리를 보게 되네요.

보면서 정리해 봅니다.


드레멜 액세서리는 종류에 따라 생각으로 구분되는데, 절단 액세서리는 붉은색 으로 표시 됩니다.

절단 비트별 사용처는 아래와 같습니다. 

최저가 금액은 

560 : 4,000 원     /     561 : 6,000 원     /     562 : 15,200 원     /     569: 17,300 원     /     570: 17,300 원  

정도 입니다



'기타 > 공구' 카테고리의 다른 글

[DeWalt] 퀵 체인지 드릴 드라이버  (0) 2023.03.12
Dewalt (디월트) 클램프 규격표  (0) 2020.07.18

DMV(동적관리뷰) 중 dm_exec_query_stats 에 대해서 알아 보겠습니다.


MSDN의 설명을 빌리자면   https://msdn.microsoft.com/ko-kr/library/ms189741.aspx


SQL Server에서 캐시된 쿼리 계획에 대한 집계 성능 통계를 반환합니다. 이 뷰에는 캐시된 계획 내의 쿼리 문당 하나의 행이 포함되어 있습니다. 


라고 설명 되어 있습니다. 


이 중 '캐시된 계획 내의 쿼리 문당 하나의 행' 에 대하여 테스트를 진행하였습니다.



테스트에 쓰인 SP 입니다. 

입력 변수의 값에 따라 총 3가지의 실행 계획이 생성 됩니다.

1번 IF 문만 실행,  2번 IF 문만 실행,   3번 IF 문만 실행



실행 계획이 3개가 생기니

뷰의 ROW로 실행에 맞춰 3개의 ROW가 생성 되었습니다.




자세한 내용은 아래 동영상을 참고해 주시길 바랍니다. 




오늘은 우연히 알게된  DB#5의 리버스 가능을 사용하여

MSSQL DB 스키마를  ORACLE 스키마로 변경해 보겠습니다.


변경하고자 하는 DB의 물리 모델을 생성 합니다.



리버스를 통하여 대상 MSSQL DB를 리버스 합니다.




VARCHAR 는 VARCHAR2로 변경된것을 확인할 수 있습니다.


아래는 시연 동영상 입니다.



베타 테스트 중인 DA#5 를 이용하여 MSSQL 을 리버스 하고 변경된 내용을 스크립트를 생성하여 DB에 적용해 보았습니다.



DA#5는 많은 종류의 DB에 대하여 리버스를 실행할 수 있습니다.

ORACLE, SQLSERVER, MYSQL, SYBASEASE, SYBASEIQ, INFORMIX, DB2, CUBRID 등등 - 만물상이 따로 없네요 .


리버스 옵션에서 인상적인건 '코멘트로 엔터티명 지정', '코멘트로 속성명 지정' 기능을 사용하면  논리 물리 모델을 충실하게 관리할 수 있겠습니다.


          아래는 리버스 및 스크립트 생성을 동영상으로 제작해 보았습니다.




      

       DA#5 인상적이고 편리한 기능들 도 많이 있는데, 


       버전 5까지 온 지금에 와서도 아직 사용에 거칠거칠 함이 있는 이유가 


       사용을 망설여지게 합니다. - 저만 그렇게 느끼는걸 까요 ?

       

       좋은 기능이 참 많은데, 쓰는건 좀 불변하고...

MSSQL에서 mdf 파일만 가지고 DB을 생성할 수 있습니다.


하지만 이상하게 운영체제 오류, 오류:5120 오류가 발생 하는데, 설명은 부실하고, 몇번을 해봐도 똑같습니다.


해결 방법은 아주 간단 합니다. Ssms.exe Management Studio 응용프로그램을 관리자 권한으로 실행 시켜 주고


연결을 수행하면, 아~무~런 오류 없이 DB가 연결 됩니다.




+ Recent posts