우리가 만든 자료와 고객이 올린 자료가 한 테이블에 있었고 이름 앞에 붙인 접두어로 구분하고 있었다. 고객이 이름을 바꿀 수 있다는 것이 이 구분의 전제를 무너뜨렸다.
Table of contents
Open Table of contents
이름 규칙이 가르던 소유
우리가 만든 것에는 정해진 접두어를 붙이고 조회할 때 그 패턴으로 갈랐다. 접두어가 있으면 시스템 자료이고 없으면 고객 자료라는 규칙이었다.
이 규칙은 이름이 안 바뀐다는 전제 위에 서 있었다. 그런데 이름은 고객이 언제든 바꿀 수 있는 값이었다.
이름을 바꾸면 구분이 깨진다
고객이 그 접두어로 시작하는 이름을 지으면 그 자료가 시스템 것으로 잡힌다. 반대로 우리 자료의 이름이 바뀌면 고객 것으로 잡힌다.
두 방향 모두 조용히 어긋나고 어디서도 오류가 나지 않는다. 구분의 근거가 사용자가 바꿀 수 있는 값이면 그 구분은 언젠가 깨진다.
값으로 옮긴 뒤의 조건
소유 유형 컬럼을 두고 기존 이름 규칙으로 한 번 채운 뒤부터는 그 값으로 갈랐다. 이름을 바꿔도 구분이 유지되므로 이름 규칙 자체를 없앨 수 있었다.
소유에 따라 수정 권한과 삭제 가능 여부와 갱신 시 덮기와 백업 대상과 과금이 갈렸다. 전에는 이름 비교가 코드 여기저기에 흩어져 있었는데 값 하나로 판단하니 조건이 한 자리에 모였다.
덮는 범위와 이름 삭제의 위험
시스템 자료는 판을 올릴 때 지우고 다시 넣는데 전에는 그 삭제를 이름으로 했다. 고객이 그 접두어로 시작하는 이름을 지었으면 갱신 때 같이 지워진다.
실제로 고객 자료 몇 개가 그렇게 사라진 적이 있었다. 소유 값으로 지우게 바꾸니 남의 것이 딸려 갈 자리가 없어졌다.
둘로 안 나뉘는 중간 성격
우리가 준 기본 서식을 고객이 고쳐 쓰는 것이 있었는데 덮으면 고친 내용이 사라진다. 그래서 시스템과 고객 사이에 고객이 수정한 시스템 자료라는 유형을 하나 더 뒀다.
고객이 고치는 순간 유형이 바뀌고 그 뒤로는 덮지 않는다. 갱신할 때 건너뛴 것을 목록으로 알려서 새 판을 원하면 개별로 처리하게 했고 같은 문제가 있던 설정과 알림 규칙과 계정에도 같은 값을 넣었다.
정리
- 이름 규칙으로 소유를 가르면 이름을 바꿀 때 깨진다
- 사용자가 바꿀 수 있는 값을 구분 근거로 삼지 않는다
- 두 방향 모두 오류 없이 조용히 어긋난다
- 값으로 가르면 이름을 자유롭게 쓸 수 있다
- 소유에 따라 무엇이 다른지 표로 적으면 조건이 한 자리에 모인다
- 이름으로 지우면 같은 이름의 남의 것이 지워진다
- 둘로 안 나뉘는 중간 성격은 고친 순간 유형이 바뀌게 한다
- 덮기 전에 건너뛴 것을 알린다