이와 같은 경우라면 대략 둘째안에 찬성합니다.

비트로 표시할 경우도 물론 크게 문제가되지는 않겠지만, 그래도 bitwise operator 를 이용해야 하고, 그리고 사이트가 많아질경우 변동사항도 문제가되겠지요. 그리고 어느 비트가 어느 사이트인지는 반드시 기억해야 하는 문제도 생기고...

여하튼 다른 문제 고려 않는다면 2안이 옳을것으로 판단됩니다.

모델하실 때는 기술적인 면보다는 업무가 우선이어야 한다고 생각합니다.

이런 경우에는  각 사이트라고 그 사이트가 자주 변하느냐 아니면 고정이 되어 있느냐, 또 각 사이트별로 테이블이 항상 있느냐 없느냐,

그리고 이 정보를 어떤 식으로 활용할 것인가 등등에 대한 정의가 우선 이루어 져야 합니다.

제 추측으로, 만약 사이트가 변동이 자주 생기고 각 사이트 별로 테이블이 항상 생긴다면 세번째 안이 좋을 듯합니다.

그렇지 않고 사이트가 거의 고정되어 있거나, 사이트에 따라서 별도 테이블이 생기지 않을 가능성이 있으면 첫번째나 두번째...

사이트가 오늘은 A, B, C, 내일은 A, B, C, D 이런 식이라면 두번째 안은 쪼금 곤란하지 않을까 합니다만.. 이렇게 될 경우 두번째 안이라면, 테이블의 구조 자체가 변동이 되어야 하기 때문에 .

다른 안도 있을거 같네요.

사이트별 테이블 생성이 아니라...

id,  사이트id, 수신여부, 수신일자,....

이런식으로 테이블 생성도 가능할 듯 한데..

그리고, 각각의 안에 대해서 필요한 정보를 추출해 내기위한 SQL문들을 한 번 만들어보세요. 사용자 interface 를 고려한 insert 문, update 문, select 문 등등을 만들어 보면 어느 정도 윤곽이 잡힐지도 모르겠습니다. 그리고 확장성도 생각을 해 보시고.

결론적으로 말씀 드리면 업무가 최우선입니다. 업무를 모르고 DB 모델을 한다면 나중에 꼭 문제가 생기더라구요.

그럼 수고하세요.

글을 수정을 하셨나.

지금 세번째 안이 두번째 안으로 되어 있었던것 같은데 말이죠.

당연히 세번째안이 선택되어져야 할것 같습니다.