동료가 96 열의 SQL 테이블을 만들었습니다.

우리는 2010 년에 4 년 또는 5 년의 경력을 가진 소프트웨어 엔지니어이며 여전히 96 개의 프랙 킹 컬럼이있는 테이블을 설계하고 있습니다.

악몽이 될 것이라고 말했습니다.
MySQL을 C #과 인터페이스하기 위해 서수를 사용해야한다는 것을 보여주었습니다.
행보다 열이 많은 테이블은 큰 냄새가 난다고 설명했습니다.

아직도, 나는 "이 방법은 더 간단해질 것입니다."

어떻게해야합니까?

편집하다 *

이 테이블에는 센서의 데이터가 포함되어 있습니다.
우리는
Dynamic_D1X 와 센서 1을 가지고
Dynamic_D1Y
[...]

Dynamic_D6X
Dynamic_D6Y
[...]

EDIT2 *

글쎄, 나는 마침내 그 일을 떠났다. 다른 프로그래머가 몇 달 동안 어두워지면 징조이며, 경영진이 이것이 문제임을 깨닫지 못하면 또 다른 징조입니다.

어쩌면 그는 공연이나 ROI와 같은 좋은 이유로 그렇게 했습니까? .

가장 좋은 방법은 그에게 질문을하는 것입니다. 일정량의 "왜"를 사용하면 자신이 실제로 잘못했을 가능성이 있음을 확실히 알 수 있습니다.

성과와 관련이 없지만 투자 수익 (ROI)과 관련된 사례가 하나 있습니다. 나는 매주 특정 시간 (주당 168h)의 값을 가진 객체를 포함하는 테이블을 가지고있었습니다. 우리는 값을 포함하는 ObjectHour 테이블을 만들 수 있었지만 Object의 키와 시간 숫자를 만들었습니다. 그러나 우리는 또한 168 개의 값을 줄에 넣을 수있는 기회를 가졌습니다. 아마도 당신의 동료가 한 일을 좋아할 것입니다.

개발자는 두 솔루션을 모두 추정했습니다. 간단한 솔루션 (168 열)은 잘 설계된 솔루션보다 훨씬 저렴했습니다. 고객에게 동일한 결과를 제공합니다.

우리는 보안과 같은 더 중요한 것들에 우리의 노력을 집중시키기 위해 가장 단순하고 저렴한 솔루션을 선택하기로 결정했습니다.

우리는 앞으로 그것을 개선 할 많은 기회를 가질 것입니다. 시장 출시 시간은 당시 우리에게 우선 순위였습니다.

불행히도 평범한 개발자는 여전히 관계형 데이터베이스를 큰 플랫 파일로 생각합니다. 그들이 더 나아질 수있는 유일한 방법은 누군가가 책임을 맡고 모범으로 인도하는 것입니다. 최근에 나는 데이터베이스에서 중요한 스키마를 대대적으로 재 설계하고 일반적인 관계 관행을 따랐다. 갑자기 우리의 저장 프로 시저가 더욱 우아 해졌고 모든 적절한 인덱스가 원래의 것처럼 만들어졌습니다. 자아 주도 개발자는 증거 없이는 결코 당신을 믿지 않을 것입니다.

StackOverflow 에서 비슷한 내용이 이미 논의되었습니다 .

일반적으로 테이블에 많은 열 이 있다고해서 반드시 무언가 잘못하고 있다는 의미는 아니지만 디자인을 면밀히 살펴볼 수 있도록 반드시 붉은 깃발을 올려야합니다. 때로는 거대한 테이블이 올바른 선택이지만 많은 경우 다른 대안이 더 합리적입니다. 예를 들어, 하나의 옵션은 스토리지를 두 개의 테이블로 분할하는 것입니다. 하나는 엔티티를 식별하는 테이블과 해당 엔티티를 설명하는 속성의 키 / 값 저장소 인 효과적인 테이블입니다 (최대 96 개의 행으로 끝날 수 있음)각 엔티티에 대해). 다른 디자인도 가능하다. 팀원들과 이야기하고 데이터 정규화, 코드 가독성 및 유지 관리 성 (속성에 96 개의 속성을 가진 명령문 삽입?), 성능 영향, 새로운 속성 (컬럼)의 추가 또는 변경 빈도, 스파 스 방법에 따라 어떤 솔루션이 더 나은지 파악하십시오. 데이터는 (96 개의 열 중 몇 개가 채워지고 NULL로 남아 있습니까?)보고에 영향을 미칩니다. 모든 개발자는 설계 결정을 합리적으로 정당화 할 수 있어야하며 비용 / 혜택 트레이드 오프 (그리고 모든 설계 결정은 트레이드 오프 임)가 유리하다는 것을 보여줄 수 있어야합니다. 귀하의 책임은 불평하거나 비난하는 것이 아니라 대안을 제안하고 이들이 이러한 문제를 통해 생각하도록하는 것입니다.

96 열로 정규화 되었습니까? 1, 2, 3 등 NF를 만족합니까?

엔티티에 대해 96 개의 개별 속성이있을 수 있습니다.

그렇지 않으면 Simple Talk에서 Joe Celko를 읽습니다.

그것은 완전히 다릅니다.

정규화 / 비정규 화 DB 설계에는 각각 장단점이 있습니다.

내 첫 DB 디자인은 표준화 된 아름다움이었습니다. 유연하고 확장 가능했습니다. 나 자신을 제외하고 코드 수준을 다루는 사람에게는 놀라운 PITA였습니다. 그리고 그것은 온화한 PITA였습니다.

다음 시도는 평평한 구조였으며 (a) 훨씬 더 빠르고 (b) 코딩하기가 훨씬 쉬웠습니다. 그리고 나중에 더 정상화하는 것은 큰 일이 아닙니다.

따라서 냄새 일 수 있지만 다른 DB 디자인에는 유쾌한 냄새 배열이 있습니다.

기술 부채 에 대한이 기사를 읽게하십시오 . 그가 여전히 이런 식으로 유지하기로 결정했다면 적어도 당신은 건설적인 의견을 제시했습니다.

(편집 된) 게시물을 보면, 이것은 비정규 화 된 테이블이라는 것이 분명합니다. 어떻게해야합니까? 내가 알다시피 몇 가지 옵션이 있습니다.

1. 동료에게 비명을 지르면 업무 수행 방법을 배울 수 있습니다. 생산적이지는 않지만 다른 동료들이 당신을 엉망으로 만들지 않도록 설득 할 것입니다. 소리를 지르는 미치광이로서의 명성은 유용 할 수 있습니다 (내가 어떻게 아는지 묻지 마십시오).
2. 동료가 바보라고 보스에게 비명을 지르십시오. 재난을 예측 한 다음 적극적으로 프로젝트를 방해합니다. 무능한 동료가 제작 한 데이터베이스 디자인의 모든 것을 비난하십시오. 직접 이어질 수 있습니다 ...
3. 떠나다. 그것이 당신의 생각이라면 가장 좋지만 # 2는 비자발적 사직으로 이어질 수 있습니다. 분노한 보스 및 / 또는 동료가 창에서 던질 경우 아스팔트 / 콘크리트 / 자갈에 무릎을 긁지 마십시오. (이전 연구는 중요합니다. 보스 사무실이 1 층 이상이고 창문 밖으로 몸을 내밀고있을 경우 생존 가능성이 현저히 줄어 듭니다. 미리 계획하십시오 !! )
4. 음료를 많이 마시거나 캘리포니아로 이사하여 불이 붙습니다 (발의안 제 19 호 (또는 그 외)). 동료에 대한 전망을 향상시키기위한 몇 번의 촬영과 두비 같은 것은 없습니다. (공공 서비스 발표 : KIDS!이 사람들은 전문가입니다! 집에서 시도하지 마십시오!)

공유하고 즐기십시오.

여기에서 사지로 나가서이 "새"테이블을 사용하기 위해 많은 코드를 잘라 붙여 넣을 것이라고 가정합니다.

그렇다면 추가 기술 부채가 발생하지 않을 것입니다. 그는 단지 기술 부채에 대한 자신의 몫을 쪼개고 있으며, 일종의 거대한 통일로가는 길에있을 수 있습니다.

만약 그가 96 개의 컬럼을 필요로하는 시도되고 진실 된 방법론을 가지고 있다면,이 특정한 경우에 다른 방식으로 수행하는 것의 실제 이점을 고려하십시오. 아무것도 없다면, 그에게 의심의 혜택을 주되, 다음에 계획 단계에 참여하고 싶을 때 다음 번에 우리 모두가 멍청한 행동이라고 생각하는 것을 상기 시키십시오.

스키마에 액세스 할 애플리케이션의 사용 사례, 한 번에 필요한 데이터 청크에 전적으로 의존합니다. 어떤 식 으로든 테이블 디자인을 정당화 할 수 있습니다.

나는 그를 석기 시대로 보내고 파일을 사용하도록 강요하거나 적어도 블랍을 사용하는 방법을 가르쳐주었습니다.

정말로, 96 열 ... 그것은 옳지 않습니다. 아마도 ORM이 도움이 될 것입니다. (성능이 필요하지 않으면 DB를 더 잘 이해하는 사람이 처리 할 수 ​​있습니다)

나는 이것을 위해 모두 지옥으로 내려갈 것이지만 이것이 바로 상점에서 데이터 모델링과 소프트웨어 엔지니어링의 책임을 분리 한 이유입니다. 프로그래머는 세트 형태로 생각하는 경우가 거의 없으며 대신 세 번째 일반 형태, 인덱싱 또는 기타 DB 성능 문제를 유지하기보다는 데이터 사용에 중점을 둡니다. 우리는 프로그래머로서 순수한 데이터 모델링 / 건축 문제에 대한 경험이 없기 때문에 아마도 DB 아키텍처 결정에 대해 생각보다 동의하지 않는 경향이 있습니다. IMHO, 나는 요구 사항을 취하고 테이블 / 프로 시저 등을 구축하고 결과물을 나에게 맡기는 데이터 아키텍트와 모델러를 좋아한다.

그래도이 디자인의 실제 이유를 알지 못하면 (96 가지 이상의 숫자 출력 = 많은 테이블 열이있는 날씨 센서에서 작업했습니다) ...