코드 우선과 데이터베이스 우선

내가 작업하는 소프트웨어를 디자인하고 만들 때 일반적으로 백엔드 SQL 테이블을 먼저 디자인하고 만든 다음 실제 프로그래밍으로 넘어갑니다. 현재 작업중 인 프로젝트는 당황 스럽습니다. 이것은 아마도 견실하고 견고한 요구 사항이 부족하기 때문일 수 있지만 불행히도 이번에는 할 수있는 일이 거의 없습니다. 상황이 "그냥 일어 나라"고 ..하지만 난 틀렸다.

워크 플로를 뒤집어 UI와 데이터 모델 클래스를 먼저 만들려고 생각하고 있습니다.이 작업을 수행하면 데이터베이스 스키마가 어떻게 보일지 분명히 알 수 있기를 바랍니다. 이것이 좋은 생각입니까? UI로 끝나고 db를 구성하는 방법에 대해 전혀 모릅니다.

궁금한 사람이 있다면 SQL Server를 백엔드로 사용하고 MS Access를 프런트 엔드 응용 프로그램으로 사용하고 있습니다. (액세스도 내 선택이 아니므로 너무 나쁘게 싫어하지 마십시오.)

프로세스 또는 프로세스에서 사용 된 데이터는 무엇입니까? 나는 이것이 일종의 "닭고기 또는 계란"질문이라는 것을 알고 있지만 소프트웨어의 경우에는 그것이 과정이라고 믿는다.

예를 들어, 메모리 내 지속성 (또는 구현하기 쉬운 것)만으로 한 번에 하나의 사용 사례를 구현하여 데이터 모델을 점진적으로 구축 할 수 있습니다. 기본 엔터티를 간략히 설명하기에 충분한 사용 사례를 구현했다고 생각되면 메모리 내 지속성을 실제 데이터베이스로 교체 한 다음 한 번에 하나씩 사용 사례로 스키마를 계속 구체화 할 수 있습니다.

이것은 데이터베이스에서 초점을 잡고 문제의 핵심 인 비즈니스 규칙으로 이동시킵니다. 비즈니스 규칙을 구현하여 시작하면 결국 비즈니스에서 실제로 필요한 데이터를 찾을 수 있습니다 (자연 선택과 매우 유사한 프로세스). 데이터 모델링이 실제로 필요한지 여부 (또는 해당 형식 또는 정규화 수준 등)에 대한 피드백없이 데이터베이스를 모델링하는 것부터 시작하면 많은 늦게 조정을 수행하게됩니다. 스키마 (비즈니스가 이미 실행중인 경우 많은 마이그레이션 프로 시저가 필요할 수 있음) 또는 조정되지 않은 데이터 모델을 보충하기 위해 비즈니스 규칙에 "해결 방법"을 구현해야합니다.

TL; DR : 데이터베이스는 비즈니스에 따라 다르며 데이터베이스에 의해 정의됩니다. 데이터와 함께 작동하는 프로세스가 없으면 데이터가 필요하지 않습니다 (보고서도 프로세스 임). 먼저 프로세스를 구현하면 필요한 데이터를 찾을 수 있습니다. 데이터를 먼저 모델링하면 처음 모델링 할 때 얼마나 많은 가정이 잘못되었는지 계산할 수 있습니다.

주제에서 조금 벗어 났지만 매우 중요합니다. 제가 설명하는 워크 플로우는 종종 "가장 간단한 일", 테스트 중심 개발, 세부 사항에서 아키텍처를 분리하는 데 초점을 맞추는 것과 같은 매우 중요한 관행과 함께 자주 사용됩니다. 방해받지 마십시오 (힌트 : 데이터베이스). 마지막 이야기에 대해 , 이 대화 는 아이디어를 아주 잘 요약합니다.

근본 원인 분석에 따르면이 문제는 방법 중 하나가 아니라 사양이 부족합니다. 하나가 없으면 실제로 무엇을 먼저 작성하든 상관 없습니다. 어쨌든 버릴 것입니다.

자신에게 유리한 태도를 취하고 기본적인 시스템 분석을 수행하십시오-다양한 레벨의 일부 사용자를 식별하고, 빠르고 더러운 설문지를 작성한 다음 기계를 끄고 커피와 쿠키 / 도넛 (또는 바퀴에 기름이 묻은 곳)을 챙긴 다음 그들의 책상, 그들이 무엇을하고 있는지, 분명한 것처럼 보이더라도 그들의 일을하기 위해 알아야 할 / 기록해야 할 것들을 물어보십시오. 그들이 얼마나 중요한지 걱정하지 마십시오. 너무 바쁘면 다른 시간에 다시 돌아 오거나 그 자리를 떠나도록 준비하십시오.

일단 당신이 당신에게 최고의 결과를 제공하고 나머지 사양이 올 때까지 기다릴 것이라고 생각하는 것을 구축 할 수 있어야합니다.

내 경험은 다음과 같습니다.

• 내가 작업 한 대부분의 프로젝트에서 데이터베이스를 먼저 디자인했습니다.
• 종종 데이터가 스프레드 시트, 레거시 데이터베이스, 종이 등에 이미 존재합니다.이 데이터는 보유해야하는 테이블에 대한 힌트를 제공합니다.
• 프로세스가 이미 수동으로 사용되거나 자동화되지 않았거나 상호 운용되지 않거나 표준을 준수하지 않는 여러 개별 도구를 사용하는 경우가 종종 있습니다.
• semi-mature 데이터베이스 모델이 있으면 해당 데이터베이스에 읽고 쓰는 프로토 타입 양식, 창 등을 디자인 할 수 있습니다.
• 계속 진행하면서 처음에는 고려하지 않은 사항을 수용하기 위해 일부 변경이 필요합니다.

또한 기억하십시오 :

• 더 이상 하나의 앱이 아닌 하나의 데이터베이스 세계가 아닙니다. 앱이 둘 이상의 데이터베이스에서 데이터를 읽거나 써야하거나 솔루션이 동일한 데이터베이스를 사용하는 둘 이상의 앱을 구성 할 수 있습니다.

결론 : 데이터베이스를 먼저 디자인하는 것이 좋습니다.

대규모 프로젝트에 대한 많은 경험이 있고 많은 개발자가 병렬로 작업하는 경우 견고한 데이터 모델이 필요하기 때문에 Database First를 말하려고했습니다.

그러나 나는 조금 더 그것에 대해 조금 더 큰 프로젝트에서 우리가 실제로하고있는 것은 "먼저 요구 사항"이라는 것을 깨달았습니다.

잘 정의 된 비즈니스 요구 사항 세트는 기능 요구 사항 세트로 이어집니다. 좋은 기능 요구 사항이 있다면 데이터 모델과 모듈 사양이 별다른 노력없이 제자리에 들어갑니다.

이것이 유동적이고 불특정 한 것처럼 보이므로 프론트 엔드 GUI를 먼저 수행합니다. 이해 관계자로부터 응답, 지원, 시간 및 피드백을 얻는 데 필요한 것 같습니다. 화려한 정규화 된 테이블과 외래 키 제약 조건 및 계단식 삭제는 신경 쓰지 않습니다. 그러나 반짝이는 색상이 많은 멋진 GUI-최고입니다!

초기 백엔드 "데이터베이스"의 경우 파일에 저장된 키 / 값과 같이 매우 간단한 것을 사용하십시오. MS Access에 익숙하지 않으므로 "가벼운"백엔드가 무엇인지 모릅니다. (더 넓어진 테이블?) 빠르거나 더러운 것은 무엇이든 버릴 계획을 세우십시오.

가능하면 GUI에서 재미있는 모양과 느낌 을 사용하여 프로토 타입임을 분명히하십시오. 다른 모든 방법이 실패하면 색인 카드를 사용하십시오.

이제 이해 관계자가 DB 전문가 일 수 있습니다. 때때로 저와 같은 경우였습니다! -이 경우 일부 DB 디자인을 수행하십시오.

요구 사항이 명확하지 않기 때문에 필요한 기본 요소, 즉 기본 테이블과 PK만으로 매우 기본적인 데이터 모델로 시작할 수 있습니다. 나머지 데이터는 이진 또는 XML로 직렬화하고 BLOB를 데이터베이스에 저장하여 시작합니다. 이를 통해 완전한 관계형 모델없이 UI 및 비즈니스 계층 (중간 계층)을 개발할 수 있지만 필요에 따라 키 검색을 저장하고 검색하고 간단하게 유지할 수 있습니다.

예를 들어, Person이있을 수 있으므로 PK가 Person Id입니다. 나머지 속성은 알려져 있지 않으므로 PK Person Id가있는 Person 테이블과 Blob, 모든 개인 데이터를 저장할 다른 열로 시작하십시오.

요구 사항이 확정되면 Blob을 가져와 필요한 모든 테이블과 열을 추출하고 모델을 관계형으로 만듭니다. 그런 다음 데이터 액세스 계층에서 지속성을 BLOB에서 관계형으로 변경하면됩니다. 그러나 비즈니스 규칙 UI 등의 다른 모든 기능은 계속 작동합니다. 이로 인해 프로젝트에 약간의 시간이 걸리지 만 관계형 모델을 변경하지 않고도 필요에 따라 항목을 추가하고 삭제할 수 있습니다.

모델이 안정화 될 때 BLOB를 쿼리 할 수 ​​없어 검색이 지연 될 수 있습니다. 관계형 열에서 검색해야하는 데이터 저장을 시작하십시오.

기본적으로 테이블 형식 모델로 시작하여 프로젝트가 진행됨에 따라 관계형 모델로 이동합니다.

또는 관계형 모델을 처음 개발할 수 있도록 작업을 시작하기 전에 요구 사항을 강화하십시오.

일반적으로 코드가 데이터를 조작하기 때문에 코드가 데이터 뒤에 오는 것으로 생각합니다.

요구 사항이 명확하지 않은 경우 요구 사항 해석에 대한 데이터 모델을 작성할 수 있습니다. 가장 좋은 것은 아마도 몇 가지 요구 사항을 적어 고용주에게 보내면 촬영할 것이 있습니다. 또는 먼저 GUI를 만들면 고용주 유형에 따라 가장 잘 작동합니다. :)