나는 언덕으로 달려 가야 할까?

Question

기본적으로 웹 프로젝트에 동의했습니다. 기본적으로 처음부터 다시 디자인합니다. Ui와 탐색 문제가 많았으므로이 재 설계가 필요했습니다. 프로젝트를 평가할 때 기존 사이트 코드를 통해 터벅 터벅 걷는 것이 허용되었습니다. 이 커브 된 내 발가락은 getSubSubSubSubSubSubProductCategory 및 getSubCategorySubCategory와 같은 이름의 많은 함수를 보았습니다. 나는 그저 나쁜 이름 짓기/코딩에 이르기까지 막혔다. 기본 db가 f'd와 같다고 생각하지 않았습니다. 내가 틀렸어. 같은 무서운 엉덩이 테이블 이름과 그 위에 97 개의 friggin 테이블이 있습니다! 이 사이트가 97 개의 제품을 판매하는지조차 확신하지 못합니다.

이와 같은 DB 작업을 고려해 본 적이 있습니까? 아니면 솔직하게 말해서 그가 진짜 혼란 스럽다는 것을 클라이언트에게 알리시겠습니까?

Answer 1

UPDATE :

항상 당신의 본능을 신뢰합니다.

분명히 언덕을 향해 달렸어야합니다.

Answer 2

재미있는 사운드! 반드시 나쁜 디자인을 의미하지 않는다)

Answer 3

97 표를,

는 작업을 포용에서 많은 것을 배울 수 있습니다. 정규화는 비정규 화 된 디자인보다 테이블 수가 많기 때문에 반드시 나쁜 것은 아닙니다.

이렇게 말하면 게시 한 내용을 토대로 디자인을 판단 할 수 없습니다.

웹 및 중간 계층에서 잘못된 이름을 지정한 사람들이 데이터베이스를 만들었는지 모르겠습니다. 누군가 스마트하게 데이터베이스를 만들었는지 알아내는 유일한 방법은 그것을 보는 것입니다. 물론 네이밍을 확인하고 정규화 정도, 적절한 키, 좋은 인덱스 등을 확인하십시오.

공연을할지 여부는 공연을 얼마나 필요로하는지 여부와 도전 여부를 결정합니다. 큰 혼란을 해결하는 것은 만족 스러울 것입니다. 당신은 늪지대를 흘린 사람이 될 것입니다.

Answer 4

아니요. 솔직히 말해서, 합당한시기에 괜찮은 해결책을 결코 얻지 못할 것이므로 나중에 그렇지 않으면 심하게 후회할 것입니다.

또한 클라이언트는 자신의 시스템이 끔찍하다는 것을 알고 있고 솔직한 전문적 의견을 제공하는 것을 존중합니다.

마지막으로 그가 듣고 분석을 수락한다고 가정하면 다시 협상 할 좋은 위치에 있습니다.

Answer 5

이것은 고객의 기대치에 달려 있습니다. 나에게

, 당신이 얼마나 배고픈 중요하지 않습니다 - 클라이언트가 얼마나 많은 시간/.. 멀리 걸어보다 걸릴 거예요 작동

는 그런 말로 미루어의 합리적인 기대를 가지고 있지 않은 경우 , 자신의 엉망을 알리는 것이 당신 직업입니다. 하루를 알아보고 간단한 분석을하고 고객에게 걱정거리를 보여줍니다. 그런 다음 시간이 걸릴 것으로 생각하고 두 배로 만듭니다 (아마도 트리플). 고객에게 그 번호를 알려서 그들이 어떻게 반응하는지보십시오.

는