2024 Spring Database System Assignment Repository

-part1 설계 변경사항

• 생성할 테이블의 외래키는 고려하지 않는다.
• 테스트 시나리오에서 primary key constraint를 확인한다.
• 레코드 삽입할 때, 반복문을 이용해 블록을 탐색하는 것이 아니라, 삽입할 위치가 링크로 바로 나오고 그래서 삽입할 블록 위치가 바로 나오기 때문에 반복문을 쓰지 않는다
• char배열과, int link를 byte 배열로 변환하여 한 번에 블록단위로 .txt파일이 아니라 .tbl 바이너리 파일에 출력한다.
• 테스트 시나리오에서 primary key 오름차순으로 정렬하는데, 숫자 크기 오름차순이 아니라 문자열 사전순 오름차순이므로 id10이 id9 다음이 아니라 id1 다음에 오게된다.

-고민한점

• 최대한 byte에 직접 접근하지 않고 Block이나 Record 클래스로 변경하도록 노력했다. 즉 읽은 byteBlock -> Block -> Record -> byte 이런 식의 변환이 가능하도록 하여 byte에 직접 접근하지 않고 객체의 값을 수정하도록 하였다. QueryEvaluationEngine 부분에서 직접 접근하는 부분이 있긴한데 나중에 이런 식으로 다듬으면 좋을것 같다
• 리팩토링에 신경썼다. 코드의 의미 단위로 하나의 메소드로 묶었고, 한 클래스에 모든 메소드를 때려박지 않고 설계한대로 메소드들을 나누어 담았다. 그리고 출력부분이랑 Processing 부분이랑 나누도록 노력했다.
• 결과셋을 성의없이 출력하지 않고 테이블 형태로 출력하도록 특수문자 찍는데 시간이 많이 들었다.
• 삭제할 때 Select One 함수 그대로 가져다 쓸까 고민했는데, 그러면 파일을 두번 연결해야할 것 같아서 로직 코드만 갖다쓰고 함수를 그대로 쓰지는 않았다.

-시간되면 개선해볼점

• Record에 블록의 몇번째 인덱스인지 저장해서, 따로 반복문 돌때 몇번째 레코드를 보고 있는지에 대한 변수를 밖으로 안빼도 되도록 하기
• byte에 직접 접근하는 코드가 있다면 Record, Block 클래스로 변경해서 접근하기(Done)
• 삭제로직에서 headerBlock과 readBlock 같을때 headerBlock이 바로 readBlock을 가리키도록 변경하기

-part2 고민한 점 *Buffer를 기존에 구현했던 Block 자료형으로 사용해야 하나 고민하였는데 기존의 Block은 free list 파일 구조에 맞추어 작성되기도 하였고, Block은 파일을 읽는 단위 개념이고 Buffer는 데이터를 저장하는 개념이기 때문에 BufferPage라는 새로운 클래스를 만들었다.

*조인을 수행한 후에 결과 정보를 어떻게 가지고 있어야 할지 고민하였다. 분명히 양쪽 레코드의 테이블에 대한 정보가 필요하기는 하지만 출력을 위해서는 항상 그 정보를 가지고 있을 필요는 없었다. 그래서 JoinedRecords 자료형을 만들어 결과 칼럼 리스트와 레코드 쌍은 가지고 있되, 생성자에서 각 테이블에 대한 정보를 입력받아 객체를 생성할 때만 필요하도록 구현하였다.