2008-12-12 8 views
1

나는 응용 프로그램을 재 설계/재실행하기위한 프로젝트를 진행 중이다. 문제는 이전 응용 프로그램이 ASP.net 1.0으로 작성되었으며 데이터베이스가 100 개의 테이블과 300 개의 홀수 뷰에 비해 상당히 큽니다. 데이터베이스가 역할과 멤버쉽을 매우 외설적 인 방식으로 처리합니다. 그것은 또한 간단한 워크 플로우를 포함합니다. 이 애플 리케이션은 유지 보수에 관해서는 고통이다. 소프트웨어를 다시 실행하려면 약 3-4 개월이 걸립니다.응용 프로그램 재 설계 다루기

DB 디자인은 내가 좋아하는 것이 아니지만 데이터 마이 그 레이션 및 DB 재 설계를 고려하면 프로젝트가 중단 될 수 있습니다.

누구나 전에이 상황에 부딪 혔습니까 ?? 어느 누구든지이 프로젝트에 대해 어떻게 가야할지에 관해서 나에게 어떤 조언이 있습니까 ??

.NET 3.5를 사용하여 소프트웨어 속도를 높이고 싶습니다. DB를 고려하지 않고 앱 재 설계가 의미가 있는지 확실하지 않습니다.

문제점 : 1. 유지 관리 및 확장 성 문제. 2. 사용자 관리의 경우 특히 DB 디자인이 좋지 않아 앱이 사용자와 역할 등에 크게 의존합니다.

+0

도메인 전문가가 아닙니다. – Perpetualcoder

+0

DB를 리팩터링 할 수 있습니까? 어쩌면 모든 것을 재 설계하지 않으면 DB의 최악의 영역을 처리 할 수 ​​있습니다. DB 구조가 관리하기 어려워 졌던 프로젝트에 참여하여 각 릴리스의 DB 섹션을 다시 구체화하기로 결정했습니다. –

답변

2

데이터베이스 재 설계는 많은 노력을 필요로합니다. 귀하 또는 귀하의 팀원 중 누군가가 데이터베이스 설계 및 ETL 전문가가 아닌 경우, 현재보다 더 심각한 혼란을 겪을 수 있습니다.

그러나 데이터베이스의 최악의 부분을 수정하여 전체적으로 개선 할 수 있습니까? 최악의 실행 쿼리를보고 무엇이 정말로 옳지 않은지 확인하십시오 (싫어하는 점에 대한 개인적 관점뿐만 아니라 현재 실제로 잘 작동하지 않는 점). 어쩌면 총 재 설계보다 적은 것이 성능을 크게 향상시킬 수 있습니다.

데이터베이스를 싫어하는 이유는 그것이 관계형이 아니라는 것입니다. 관계형 테이블에 새로운 이름을 넣고, 데이터를 이동하고 이전 테이블을 삭제하고, 이전 테이블로 뷰를 생성함으로써 절충 할 수 있습니다 현재 디자인과 같은 구조의 이름. (현재 데이터베이스베이스 백업 없이는하지 마십시오 !!!!) 그런 식으로 코드를 새로운보다 효과적인 디자인으로 변경할 수는 있지만 변경하지 않은 내용은 사용자가 얻을 때까지 여전히 작동합니다.

+0

회원/역할 및 사용자와 관련된 db 부분이 좋지 않습니다. 왜 원래 dev에 isActive 등 부울 alements 저장 char/varchar 사용 이해할 수 없습니다. – Perpetualcoder

0

데이터베이스 재 설계를 원하지 않는다면 언제든지 사용자 경험 (UI)을 재구성 할 수 있습니다. 좋은 패턴을 사용하면 웹 양식을 사용하도록 선택하면 모델 뷰 발표자 패턴을 사용하거나 자바 스크립트 및 HTML이 많이 있고 웹 폼 모델에서 새 ASP.NET MVC를 사용하는 것을 좋아하는 경우 조언을 사용하십시오.

하지만 애플리케이션을 재구성하기 전에 선택한 디자인 패턴을 이해해야합니다.

이 정보로 무엇인가 할 수 있기를 바랍니다.

+0

webform과 함께 MVP를 사용하기위한 모든 참조 자료 ?? – Perpetualcoder

1

데이터베이스 또는 전체 응용 프로그램을 다시 디자인해야합니까? 솔로 미션에 참여하고 있습니까? 아니면 도움이 필요합니까? 귀하의 회사는 어떤 방법론 표준 (SDLC 프로세스)을 사용합니까, 아니면 당신이 독창적 인 IT 부서입니까?

4 개월은 매우 공격적입니다. 요구 사항을 문서화하고, 모든 기능 구성 요소를 계획, 설계, 구축 및 테스트하고, 이전 시스템의 데이터를 새로운 시스템으로 변환하고, 이러한 모든 시나리오가 수행 될 수있는 새로운 환경을 설정해야합니다.

결론은 전체 프로세스를 진행하는 데 소요되는 작업을 예측하는 데 상당한 시간을 투자하는 것입니다. 4 개월이면 멋지네. 나는 그것이 될 것이라고는 생각하지 않는다. 관련된 노력을 문서화하고 상세한 추정치를 얻은 다음이를 상사에게 가져 가서 4 개월 기간의 극단적 인 정도를 설명하십시오.

데이터베이스를 다시 할 것인지 아닌지를 가장 많이 염두에 둔다면 체인이 가장 약한 링크만큼 강한 기존 관용구를 고려해보십시오. 새로운 응용 프로그램은 .NET으로 작성되지만 불쌍한 디자인의 샷 데이터베이스에 앉아있는 것이 합리적일까요?

계획을 프로젝트에 보내면 실제로 발생할 수있는 실제 개발, 테스트 및 다시 작업하는 데 훨씬 적은 시간을 할애 할 수 있습니다.

희망이 도움이됩니다.

+0

경제는 내가 솔로와 그 응용 프로그램을 재 설계한다고 말합니다. 나는 개인적으로 생각하기에는 거의 불가능하다고 생각한다. – Perpetualcoder

1

언제나 스마트 데이터 구조와 멍청한 논리가 역순으로 뒤틀린다고 일종의입니다. unix philosophy article의 규칙 5를 참조하십시오. 문제가 생길 때, 깨진 데이터 구조를 수정하기 위해 코드로 원숭이에게해야만했던 곳의 모든 프로젝트는 고통 스러웠습니다.

짧은 답변 : 가능한 경우 데이터를 다시 작성하십시오.

답변 : 실용적입니다. 데이터베이스의 일부만 다시 작업하여 두통을 해결할 수 있다면 그렇게하십시오. 응용 프로그램 논리에서 데이터베이스 수준보다 처리하는 것이 더 어려워집니다.

희망 하시겠습니까?

0

정말 프로젝트의 범위를 알지 못합니다. 그러나 100 개의 테이블이 비현실적인 것처럼 보이는 시스템을 재 설계하는 데는 4 개월이 걸립니다. 도메인을 잘 아는 경우는 제외하고

내 0.02는 성능, 유지 보수의 확장 더 나은 기지, 현재 소프트웨어의 문제 것입니다 내가 $ 0.02, 당신이 먼저 재 설계를하고있는 이유에 대해 명확해야 추가하려면 $

0

새로운 제품에 대한 목표 (예 : UX, 성능 목표, 프레임 워크 개선 등)를 명확하게 기술하면 어떨지 재 디자인해야 할 것이 무엇이고 어떤 것이 작동하는지 더 잘 볼 수있을 것입니다.