2009-11-26 3 views
0

데이터베이스 디자인에 대한 의견이나 토론을 듣고 싶습니다. 저와 제 동료들은 여러 국가에 설치된 금융 산업에서 복잡한 응용 프로그램을 개발하고 있습니다.T-SQL 데이터베이스 디자인 및 테이블

우리 계약자는 우리가 모든 국가에 대해 단일 응용 프로그램을 유지하기를 원했기 때문에 우리는 자연스럽게 각기 다른 워크 플로의 어려움에 직면하고 다양한 요구를 충족시키기 위해 응용 프로그램을 조정할 수 있도록 노력했습니다.

오늘 내가 직면 한 문제는 계약자 측의 IT 부서장이 요청한 테이블과 열의 관점에서 데이터베이스 모델을 유지하는 것입니다.

예를 들어, 위험이 다른 표를 얻었으므로 플래그 열 IsSomething (BIT NOT NULL ...)을 추가해야했습니다. 그것은 완전히 세 번째 정규화 된 형식에 따라 위험 표 내에 존재할 수 있으며, 키에 대한 전이 의존성, 비 핵심 가치 ...

하지만 그 사람은 그가 그대로 테이블을 유지하기를 원한다고했습니다. 새로운 테이블 "riskinfo"를 만들고 데이터 1 : 1을 새 열에 연결해야했습니다.

귀하의 의견은 무엇입니까?

+1

귀하의 질문에 대한 답변을 드리겠습니다. 당신은 "주관적이고 논쟁의 여지가있다"는 결론을 내릴 위험이 있습니다. 나는 이것을 "받아 들일 수있는 아이디어인가?"라고 직설적으로 요구하고 토론의 욕구를 제거합니다. –

+0

주관적이며 논쟁 적이라면 정말 미안합니다. 그런 의도는 없습니다. 내 입장에서는 당신이 그것에 대해 다르게 느낄 수도 suprprised 프로그래머로 그것을 읽어보십시오. 나는 숯을 바꾸지 않을 것이다. –

+0

바이너리, 응용 프로그램을 개발하는 배경을 게시 한 다음 상황을 설명했습니다 (절대적으로 명백하게). 그런 다음 예제가 주어 지므로 아무도 문제의 세부 사항을 혼동하지 않습니다. 그리고 나서 마지막 질문 .. 나는 동의한다, 그것은 많은 관점에서 다르게 들릴지도 모른다. 다음에, 대문자 잠금은 없다. .. 그러나 나를 용서해라, 나는 어떤 출생지의 영어 연설자도 아니다. 질문은 나를 위해 nonsided하게 들린다. –

답변

2

우리는 항상 다양한 앱에 의해 참조되는 테이블에 테이블을 추가합니다.

응용 프로그램에서 사용하려는 열을 구체적으로 참조하고 새로운 필드가 nullable이거나 적절한 기본값이 정의되어있어 삽입을 방해하지 않는지 확인하면 실제 문제는 발생하지 않습니다.

그런데 앱이 select *를 수행하면 이름 대신 색인으로 열을 참조하여 기존 코드에서 문제가 발생할 수 있습니다. 개인적으로 저는 데이터베이스를 참조하는 것이 코드 작성 규칙 때문에 (코드 검토 프로세스가 그것을 시도한 사람과 연관이 있다고 생각합니다 : P),이 작업을 수행하지 않는다는 확신을 가지고 있습니다. 그러나 확신하지 못하면 최소한의 작은 위험이 있습니다 그러한 변화에.

실제 시나리오에서는 계약 업체로 돌아가서 변경 사항이 문제를 일으키지 않을 것이라고 생각하는 이유를 제시하고 선택의 여지가있는 근거를 묻습니다. 어쩌면 그들에게는 제안에 대한 몇 가지 애플리케이션 별 지혜가 있을지도 모르며, 하위 호환되지 않는 방식으로 데이터베이스 구조를 변경하는 다른 회사를 다루는 편집증에 불과할 수도 있고, 아니면 고무 스탬프가 찍힌 회사의 정책 일 수도 있습니다. 전에는 아무도 도전을받지 못했습니다. 당신이 결코 알지 못할 때까지.

+0

제안 해 주셔서 감사합니다. 제 생각에 편집증은 뒤에 있습니다.하지만 그것은 불평의 대상이 될 것이므로 문제를 쉽게 해결할 수 있기를 바랍니다. 계약자가 코어 테이블을 설정하려고 시도했는데 결코 변하지 않을 것이라고 생각합니다.우리는 항상 새로운 기능을 추가하고 "국가 별"이므로 모든 국가에서 쉽게 이해할 수있는 기본 테이블을 원합니다. 나는 간단히 말해서 그들의 솔루션이 속기 쉽고 실제로 체계적이지 못하다고 느낍니다. 그러나 ... 그들은 작은 요청으로 더 깊은 문제에 대한 토론을 시작했습니다. 이것은 유용 할 수도 있습니다. –

1

이 질문은 Binary Worrier가 논평 한 것처럼 주관적입니다. 나는 대답이나 제안이 없다. 내 2 센트 만 공유하면 돼.

이러한 결정의 근거가 무엇인지 알고 계십니까? 때로는 좋은 디자인은 현재 작동중인 응용 프로그램을 깨지 않기 위해서 또는 단순히 이전 응용 프로그램을 기반으로 너무 많이 수행되었다는 사실 때문에 손상되었습니다. 그것은 또한 다른 많은 기술적이지 않은 이유 일 수 있습니다.

+0

나는 때때로 .. 타협 한 .. 기술적이지 않은 이유에 동의한다. 나는 그것의 필요성을 어떤 경우에는 이해한다. 간단한 테이블에 다른 플래그 열이 필요한 경우 기분이 들지 않습니다. DB 모델에 대한 기술적이지 않은 위반 문제를 다루는 문서 나 웹 페이지가있는 사람이 있습니까? –

+0

"주관적인"단어가 여기에 있습니다. 미안하지만, 나는 참으로 초보자입니다. 그러나 내 견지에서 볼 때 인간이 주관적인 어떤 것도 될 수는 없습니다. 객관성이 단어로서 fullfiles 결코 .. 그리고 자신의 견해가되기 전에 다른 의견에 대한 존중을 선언하는 것은 객관성이 존재한다는 자기기만의 좋은 예라고 말합니다. 그러나 .. '당신은 다른 의견을 갖고 있겠습니까. 나는 너와 동의한다. ' 내가 바라는 불평은 다른 문제에 관한 것이지만 나는 주관성의 문제가 상대적으로 매력적이라는 것을 안다. –

+0

@ 대니얼, "주관적인"은 당신이 정말로 옳고 그른 대답을 가질 수 없다는 것을 의미합니다. 답변을 수락하지 않기로 선택할 수는 있지만 일반적으로 대답을 수락하거나 위키로 태그를 지정하는 것이 좋습니다. –

0

종종 프로그래밍 커뮤니티는 테이블을 재정의하여 발생하는 파급 효과에 대해 부당하게 우려하고 있습니다. 일반적으로 이는 데이터 독립성을 이해하지 못하고 데이터에 대한 작업의 데이터 독립성을 지키지 않아 발생한 결과입니다. 때로는 원래 데이터베이스 설계자의 잘못입니다.

대부분의 객체 지향 프로그래머는 내가하는 것보다 캡슐화가 더 잘 이해하고 있습니다. 그러나이 같은 전문가들은 일반적으로 데이터 독립성에 대한 웅크리는 것을 이해하지 못합니다.그리고 SQL 데이터베이스에서 작동하는 방법을 배웠지 만 데이터 독립성의 개념을 결코 알지 못하는 사람은 위험 할 정도로 무지합니다. 데이터 독립성의 표면적 측면은 약 5 분 만에 배울 수 있습니다. 그러나 실제로 배우려면 시간과 노력이 필요합니다.

다른 응답자는 "select *"를 사용하는 쿼리에 대해 언급했습니다. 와일드 카드를 사용한 선택은 테이블의 모든 열의 이름을 나열하는 동일한 선택보다 데이터 의존적입니다. 이것은 수십 개 중 하나 일뿐입니다.

데이터 독립성과 캡슐화는 모두 동일한 목표를 추구합니다. 즉, 모델의 의도하지 않은 결과가 포함됩니다.

다음은 IT 담당자를 만족시키는 방법입니다. 이전 테이블의 모든 열과 현재 필요한 모든 추가 열을 포함하는 새 이름으로 새 테이블을 정의하십시오. 이전 테이블과 동일한 이름의 뷰를 생성합니다. 뷰에는 이전 테이블과 동일한 열과 순서가 동일한 뷰가 생성됩니다. 일반적으로이 뷰는 이전 테이블의 모든 행을 표시하며 이전 PK는 여전히 고유성을 보장합니다.

가끔씩은 IT 총책임자의 모든 요구를 충족하지 못합니다. IT 담당자가 "데이터베이스를 이해하지 못해 아무 것도 변경하지 마십시오."라고 말하면 IT 담당자가 변경되거나 변경 될 때까지 크릭을 올라갑니다.

+0

귀중한 답변, 감사합니다. 필자는 프로그래머가 논리적으로 찾는 방식으로 데이터베이스를 구성하는 것에 대해 생각할 것입니다. 동시에 IT 수석은보기를 사용하여 "핵심"테이블을 변경하지 않고 자신의 눈에서 변하지 않게 할 수 있습니다. –