응용 프로그램 코드를 작성하기 전에 데이터베이스를 설계해야합니까?

데이터베이스를 설계하는 가장 쉽고 효율적인 방법은 무엇입니까? 필자의 관점에서 볼 때 응용 프로그램의 데이터 저장소 디자인을위한 몇 가지 옵션이 있습니다.

1. 응용 프로그램 코드를 작성하기 전에 처음에 최대한 데이터베이스를 설계하십시오 . 이를 통해 기본 데이터 구조를 활용할 수 있다는 이점이 있습니다. 내 의견으로는 이것의 단점은 응용 프로그램 개발주기 내내 데이터 변경의 위치 / 방법 / 방법에 영향을주는 응용 프로그램 특정 항목으로 인해 많은 변경 이있을 것이라는 점입니다.
2. 응용 프로그램이 완성되면 데이터베이스를 디자인하십시오 . 응용 프로그램을 작성할 때 일부 데이터베이스 오브젝트가 필요할 때, 응용 프로그램과 병렬로 (시간순으로) 데이터베이스를 개발합니다. 내가 볼 때 데이터베이스 구조에 대한 변경이 적다는 이점이 있습니다. 단점은 응용 프로그램 코드와 데이터베이스 개발간에 시간과 개발 노력이 나누어 져 있다는 것입니다.

경험상 가장 생산적이고 효율적인 방법은 무엇입니까?

다른 답변 외에도 ...

개념적 모델을 캡처하려면 먼저 범위와 요구 사항을 정의해야합니다. 이를 통해 논리적 및 물리적 데이터 모델을 도출 할 수 있습니다.

이것이 정적 일 때, 당신은 당신의 어플리케이션을 빌드 할 안정적인 데이터베이스를 갖게됩니다. 이것은 첫 번째 옵션과 반대입니다.

두 번째 요점은 지저분한, 유지 불가능한 진흙 공으로 끝납니다 . 데이터 모델은 고정되지 않습니다. 사전에 설계하지 않은 경우 배송 전에 수정해야 할 시간이 없습니다. 함께 해킹하는 데 너무 바쁠 것입니다.

스키마에 대한 사소한 변경, 테이블 결합 또는 분할, 관계 변경 등이 발생하지만 현지화 된 "섬"에서는 모델 + 기본 디자인이 변경되지 않습니다.

Agile의 일부 변형을 운영하지 않는 최신 소프트웨어 부서를 찾기가 어려울 것입니다. DBA는 @RobPaller의 대답에 여전히 일반적인 장소가 포함되어 있다는 생각과 함께 암흑 시대에 갇혀 있습니다.

데이터베이스 스키마를 수정하는 것이 코드를 수정하는 것만 큼 쉬울 수 없었으므로 데이터베이스 개발 및 유지 관리에 대한 민첩한 접근 방식을 채택하기를 꺼려했습니다. 이제 개발자와 비슷한 방식으로 작동 할 수있는 도구와 기술을 갖추 었으므로 가장 확실하게해야합니다. 스키마를 변경하기가 쉽지 않다고해서 할 수없고해서는 안된다는 의미는 아닙니다.

저는 데이터베이스 디자인에 대한 우연한 접근 방식 (주석 참조)을 옹호하는 것이 아니라 민첩한 개발 팀의 접근 방식과 더 유사하게 접근하는 것입니다. 민첩한 프로젝트에 참여 하는 경우 미래에 발생할 수도 있고 그렇지 않을 수도있는 작업에 대한 요구 사항 이 없으므로 필요한 것보다는 필요한 것을 디자인해야합니다.

나는 그것이 당신의 옵션 2로 내 투표를했다고 생각합니다. 그리고 나는 이것에 추위에 서있을 것으로 생각합니다!

논리적 데이터 모델은 애플리케이션의 비즈니스 요구 사항을 효과적으로 캡처해야합니다. 실제 데이터베이스 설계는 RDBMS의 효율성을 최대화하기 위해 DBA가 느끼는 필수 변경 사항과 결합 된 논리 데이터 모델을 기반으로해야합니다.

응용 프로그램의 소프트웨어 개발 수명주기를 통해 기본 데이터베이스 디자인을 많이 변경해야하는 경우 다음 두 가지를 나타냅니다.

1. 스코프 크리프 – 부적절한 시간에 새로운 요구 사항을 도입 할 수 있습니다.
2. 불충분 한 비즈니스 요구 사항 -데이터 모델러 (또는 시스템 분석가)가 비즈니스 분석가의 요구 사항을 충분히 번역하지 못했습니다. 결과적으로 응용 프로그램의 요구 사항을 지원하기 위해 불완전하거나 잘못된 데이터 모델이 생성되었습니다.

일단 애플리케이션이 프로덕션으로 전환되면 다시 돌아가서 애플리케이션 또는 기본 비즈니스 프로세스의 자연스러운 진화를 지원하기 위해 데이터 모델을 반복적으로 변경해야하는 경우가 드물지 않습니다.

도움이 되었기를 바랍니다.

웹, 액세스 및 C #을 포함한 다양한 프런트 엔드를 사용하여 비즈니스에 사용되는 여러 가지 복잡한 데이터베이스를 설계하는 데 고급 스러웠습니다.

일반적으로 나는 앉아서 데이터베이스 스키마를 미리 연구했습니다. 이것은 항상 나에게 가장 의미가 있었다. 그러나, 내가 테이블을 변경하거나, 새로운 테이블을 추가하거나, 나를 귀찮게하고 근본적으로 고치기에 너무 늦었 던 측면으로 살지 않은 경우는 없었습니다.

치료법이 먼저 코드를 작성하는 것이라고 생각하지 않습니다. 그리고 나는 그 문제가 "비즈니스 요구 사항이 충분하지 않다"거나 최소한 완전히 해결되지 않은 것이 아니라고 생각합니다. 사용자는 자신이 필요한 것을 알지 못하며 더 열심히 생각하거나 똑똑하게 생각하거나 더 잘 알고 내 질문에 더 잘 대답 할 수있는 힘이 없습니다. 아니면 그들은 주장하고 나는 특정한 방법으로 무언가를하라는 명령을 받는다.

내가 구축 한 시스템은 일반적으로 아무도 들어 가지 않은 새로운 영역에 있습니다. 조직, 자원 또는 툴을 개발하기 위해 내가 만든 것보다 열 배나 많은 팀을 이룬 최고의 비행 설계 전문가 개발 팀이 할 수있는 종류의 작업을 수행 할 수있는 조직, 자원 또는 도구로부터의 매입이 없습니다. 두 번 시간.

나는 내가하는 일에 좋다. 그러나 "개발을하지 않는"환경에서는 저 뿐인 사람이 있습니다.

나는 비즈니스 규칙을 발견하는 데 점점 나아지고 있습니다. 그리고 세 번째 옵션이 있습니다.

데이터베이스를 디자인하기 전에 코드를 작성하기 전에 응용 프로그램의 작동 방식을 보여주는 조잡한 화면을 그립니다. 글꼴이나 크기 또는 크기에 대해 주석을 달지 않도록 손으로 그려야합니다. 기능 만 원합니다.

투명 용지와 종이 조각을 사용하면 교환 및 교환이 가능하고 한 사람은 컴퓨터가되고 두 ​​사람은 기술적으로 문제가없는 전문 지식을 가진 사용자 (큰 소리로 말을하는 사람)가되고 메모를 한 사람은 촉진자가됩니다. 사용자의 사고 과정과 혼란에 대해 사용자는 "클릭"하고 상자에 끌어서 쓰고 "컴퓨터"는 화면을 업데이트하며 모든 사람이 디자인을 경험하게됩니다. 개발 프로세스에 이르기까지는 배울 수 없었던 것들을 배우게됩니다.

아마도 내가 모순되는 것일 수도있다. 아마도 더 나은 요구 사항 발견 일 것이다. 그러나 아이디어는 코드를 작성하지 않고 응용 프로그램을 먼저 디자인하는 것입니다. 나는 이것을 소규모로 시작했고 작동하고 있습니다! 내 환경의 문제에도 불구하고 처음부터 데이터베이스를 더 잘 설계하도록 도와줍니다. 여러 유형이 있기 때문에 열이 새 부모 테이블로 이동해야한다는 것을 알게되었습니다. 작업 목록에 통합 주문 시스템에서 제공되지 않은 정식 주문이 있어야한다는 것을 알고 있습니다. 나는 모든 종류의 것들을 배웁니다!

제 생각에는 이것은 큰 승리입니다.

대부분의 경우 옵션 2 : 다른 구성 요소와 병렬로 데이터베이스 구축을 선택합니다. 가능할 때마다 반복적 인 접근 방식을 취하고 각 부분을 작성할 때 엔드 투 엔드 기능을 제공하십시오.

이것은 일정량의 프로젝트 훈련이 필요합니다. 데이터베이스를 변경할 때마다 엄격하게 정규화 (Boyce-Codd / Fifth Normal Form)를 적용하여 품질을 유지하고 임시적이고 일관성이없는 모델을 만들지 않도록하십시오. 비즈니스 규칙 및 수행자 데이터베이스 제약 조건으로 최대한 민첩하게 행동하십시오. 확실하지 않은 경우 제약 조건을 조기에 적용하는 것이 좋습니다. 나중에 언제든지 제거 할 수 있습니다. 기술 부채를 최소화하기 위해 건축 구성 요소를 구현하는 순서에 대해 지능적입니다. 모든 개발자 팀이 구매할 수있는 데이터베이스 설계 지침을 마련하십시오.

이 모든 과정은 지속적인 통합, 테스트 자동화 및 데이터베이스 관점에서 결정적으로 중요한 테스트 개발과 같은 다른 우수한 개발 엔지니어링 사례와 함께 진행되어야합니다. 현실적인 크기의 데이터에 대한 테스트 데이터 생성은 각 반복마다 반드시 수행되어야합니다.

건축의 세계에서 "Form Follows Function" 이라는 문구 가 만들어졌고 나중에 고층 빌딩을 건설 할 때 고수되었습니다. DB 인프라 및 애플리케이션 개발에도 동일하게 적용되어야합니다.

여기에 테이블과 거기에 테이블이 필요하다고 즉시 결정하는 앱을 작성한다고 상상해보십시오. 앱이 완료되면 수많은 테이블이 배열로 취급됩니다. 모든 테이블을 나란히 살펴보면 테이블에 운율이나 이유가없는 것 같습니다.

불행히도 일부 개발자 상점은 memcached와 같은 것을 선택하여 RAM에 데이터를로드하여 (데이터 도관처럼 취급) MySQL 또는 PostgreSQL과 같은 데이터베이스를 단순히 데이터 저장 장치로 사용합니다.

데이터베이스 사용에 대한 인센티브는 데이터베이스를 RDBMS로 올바르게 보는 것입니다. 그렇습니다. 관계형 데이터베이스 관리 시스템. RDBMS를 사용할 때 목표는 스토리지 테이블뿐만 아니라 검색 테이블을 설정하는 것입니다. 표 사이의 관계는보고자하는 데이터와 표시 방법을 모델링해야합니다. 이는 알려진 비즈니스 규칙과 함께 데이터의 응집성과 무결성을 기반으로해야합니다. 이러한 비즈니스 규칙은 앱 (Perl, Python, Ruby, Java 등) 또는 데이터베이스에서 코딩 할 수 있습니다 .

결론

옵션 1을 사용하는 것이 가장 확실합니다. 적절한 계획, 데이터 모델링 및 지속적인 데이터 분석이 필요합니다. 그러나 이것은 장기적으로 데이터베이스 변경을 최소화해야합니다.

응용 프로그램의 실제 코드 가 있기 전에 수행해야 하지만 응용 프로그램을 설계하기 전에 수행해야한다고 생각합니다 .

혼자 일하는 경우의 일반적인 워크 플로는 다음과 같습니다.

1. 응용 프로그램이 수행해야 할 작업 결정
2. 재사용 가능한 구성 요소에 대한 작업을 분류 할 수 있는지 확인
3. 각 작업이 데이터 스토리지와 상호 작용하는 방법, 데이터에 대해 어떤 종류의 질문을 할 것인지, 얼마나 자주 쓸 것인지 등을 결정하십시오.
4. 데이터베이스는 우리가 요구하는 모든 질문에 대답 할 수 있고 가장 빈번한 작업을 수행 할 수 있도록 설계하십시오.
5. 신청서를 작성하십시오.

팀의 일원으로 자주 일하고 지리적으로 분산되어 있고 (시간대에 걸쳐) 우리는 초기 시작 회의를하는 경향이 있습니다.

1. 응용 프로그램이 무엇을해야하는지 결정하십시오.
2. 응용 프로그램을 독립적 인 구성 요소로 나눌 수있는 좋은 점을 결정하십시오.
3. 각 구성 요소가 다른 구성 요소와 상호 작용하는 방법을 결정하십시오.
4. 각 상호 작용에 대한 API에 동의하십시오.

그런 다음 집으로 돌아가서 파트를 작성하고 해당 파트의 관리자가 API의 모듈 일관성을 유지하는 한 컴포넌트에 자체 로컬 스토리지가 필요한 경우. 주 데이터 스토리지는 자체 API가있는 모듈로 처리되며 사람들은이 데이터를 쓸 것으로 예상됩니다. (DB 속도가 중요한 경우 API는 테이블 정의이며, 변경이 이루어지면 뷰 또는 다른 메커니즘을 사용하여 모든 모듈을 업데이트 할 수있을 때까지 이전 버전을 표시합니다.)

나는 다음과 같은 규칙을 염두에 두었다. "데이터베이스에서 생성 할 데이터가있는 정보 만 얻을 수있다". 그래서 코드를 먼저 데이터베이스에 디자인합니다.

왜? 내가 사용하는 방법론 / 언어 / 도구 세트에 관계없이 모든 관련 데이터가 DB에 잘 설계되고 저장되어 있으면이를 검색 할 수 있습니다. C # / Delphi / FORTRAN / COBOL / Assembly / VBA 또는 Crystal Reports에 있더라도 상관 없습니다. OO 설계 또는 이벤트 / 데이터 / 무엇이든; 민첩 또는 폭포. 데이터가 있으면 사용하는 도구가 데이터베이스에 연결할 수 있으면 검색 할 수 있습니다. 어셈블리에서 바이트 단위로 작성해야하더라도 분기의 수익에 대한 주문을 선택할 수있는 경우 판매 보고서를 작성할 수 있습니다.

관련 데이터가 없거나 데이터가 있지만 구조화되지 않은 경우 필요한 정보를 검색 할 수없는 방식으로 코딩하는 방법은 무엇입니까?

일반적으로, 그것은 의존한다;)

예를 들어, Python으로 개발되고 플랫 파일을 사용하는 소규모 작업 프로토 타입이 있고 사용자가 프로토 타입의 기능에 만족한다고 가정하면 RDBMS를 백엔드로 사용하여 프로토 타입을 생산하기 만하면됩니다. . 이 경우에는 처음부터 올바르게 수행하는 것이 합리적입니다. 문제는 작고 명확합니다. 이러한 경우 선결제 설계가 가능합니다.

반면에 애자일 환경에서 요구 사항을 발견 할 때는 요구 사항을 더 잘 이해하기 위해 몇 가지 반복 작업이 필요합니다. 이러한 상황에서 데이터베이스는 나머지 응용 프로그램과 함께 진화합니다. 이것이 우리가 일반적으로하는 일입니다. 가동 중단없이 위험이 적은 라이브 OLTP 테이블을 리팩토링 할 수 있으므로 데이터베이스 리팩토링 가능성에 익숙합니다.