프로그램 자체가 Combination unit(조합단위) 로 데이터를 읽어들여서 처리를 하는 동작의 System 인데, 


이런 측면에서 보면 데이터를 설계를 하는 것이 CRUD 를 할 것을 생각을 해보면 When? & What? 을 Reference 기준으로 설계를 하는 것이 되기는 함.. 


개인적으로 데이터베이스 분석해놓은 게시글도 있는데 디테일 빼고 원론적으로는 맞음.. ㅇㅅㅇ.


그렇지만 Algorithm(알고리즘) 에 대해서 모든 CRUD 의 System 에서 설계된 데이터의 처리에 관해 Reference 가 이미 설계되어 있기 때문에, 


들어갈 자리가 없는 것같지만 생각 외로 성능에 대해서 중요하다고 볼 수 있음.. ㅇㅅㅇ. 




Algorithm(알고리즘) 에 대해서는 기본적으로 Yes or No 의 판단이 성립이 가능해야함.. 


왜냐하면 프로그램으로 알고리즘이 나타나는데 이것에 대해서는 Reference 가 데이터적으로 설계되어 있는 환경에서의 알고리즘이 되어야 하고, 


여기에서 Reference 에 대해서 동작(Operation) 이 Problem 에 대해서 있기 위해서는 Yes or No 의 Base unit 이 필요로 하기 때문임.. 


그렇지만 컴퓨터(Computer) 에 대해서는 Memory 를 기준으로 Base unit 이 CRUD 이기 때문에, 


When? & What? 의 Reference 로 데이터가 설계가 되기 때문에 시스템적으로 소프트웨어의 기본기능 등에 대해서는 알고리즘은 필요없음.. ㅇㅅㅇ.. 




그렇지만 소프트웨어의 성능에 대해서는 알고리즘이 들어갈만함.. 왜나하면 데이터 설계에 대해서는 항상 Domain 이 있기 때문임.. 


Domain 에 대해서 Yes or No 가 가능할 바에 대해서는 알고리즘이 가능할 것이고 어느정도의 Real world 에 대한, 


Analogy(분석) 이 Really Yes or No 에 대해서 있기 때문임.. 


그렇다면 Reference 에 대해서 When? & What? 이 Real world 에 대해서, 


어떤 모델 X 에 대해서 어느정도의 Real world 에 대한 지식으로 Yes or No 가 되는 것이 있을 것임.


ㅇㅅㅇ..




그러니까 동작(Operation) 을 기준으로 Reference 가 기계적이든 행동적이든 Reference 의 When? & What? 에 대해서,


Yes or No 의 Base unit 이 있게되고, 


여기에 대한 Base unit 의 Cache table 이 가능해지는 것에 의해서 시스템의 성능을 향상시킬 수 있는 것임.. 


ㅇㅅㅇ.. 


여기에서 Server-Client 구조에서 데이터 통신에 대해서 Yes or No 의 Tagging List 를 Server 에서 Cache table 로 Send 하면, 


Client 에서 List 의 목록을 공유해서 거기서 부터 When? & What? 을 Deciper(해독) 할 수가 있는 것으로 보임.. 




결과적으로 데이터 통신에 대해서 대규모 트래픽 관리에 대해서는, 


Server-Client 에서 하드웨어를 증설하거나 Event pipeline 을 만드는 것 외에, 


이러한 전략도 있고 프로그래밍의 관점에서의 성능절약의 형태로 대규모 트래픽 관리가 가능하기도 함. ㅇㅅㅇ.


그리고 dcinside 끊기는데다가 너무 느린데 내 의견이 반영됬으면 좋겠다 싶음.. 


ㅇㅅㅇ..