크고 작은 많은 프로젝트가 있습니다. 대부분은 (전부는 아닐지라도) 적어도 하나의 SQL Server DB를 사용합니다. 그들 모두는 서로 다른 환경을 갖추고 있습니다. 일반적으로 dev (1+), QA, UAT, Live. 서로 다른 환경에 다양한 코드 업데이트를 개별적으로 릴리스하는 것이 일반적입니다. 물론 이러한 업데이트 중 일부는 레드 게이트 SQL/데이터 비교하여 스키마 업데이트 때로는 손으로 만든 같은테이블의 열 순서가 중요합니까?
alter table foo add column bar
go
update foo set bar=... where ...
로 스크립트, 다른 시간이 제공됩니다.
어쨌든 여기서는 동일한 프로젝트의 여러 환경이 서로 다른 열 순서로 끝나는 경우가 많습니다. 이게 문제 야? 나는 정말로 모른다 ... 칼럼 순서는 성능에 영향을 미칩니 까? 내가 누락 될 수있는 건 없니?
아니요, 열 순서는 중요하지 않습니다. 실제로 열 데이터가 디스크에 저장되는 순서는 엔진이 데이터를 재 배열하여 저장 공간과 읽기/쓰기 성능을 최적화하기 때문에 클라이언트 도구에서 보는 순서와 다를 수 있습니다 (여러 비트 필드를 단일 메모리 위치에 배치). , 메모리 경계에 열 정렬).
사실 - 95 %의 경우에는 열 순서에 차이가 없습니다. 그리고 관계형 이론적 관점에서 볼 때 테이블의 열 순서는 관계가 없습니다.
VARCHAR와 같이 가변 크기 필드가 많은 경우 열 순서가 테이블에 약간의 영향을 미칠 수있는 몇 가지 단점이 있습니다. 하지만 그 수는 실제로 커야하며 필드 (크기)는 정말 거대해야합니다. 이러한 경우 가변 길이 필드를 열의 순서와 관련하여 테이블 끝에 배치하는 것이 좋습니다.
그러나 다시 말하자면, 이것은 표준이 아닌 매우 드문 경우입니다.
SQL Server에는 열을 재정렬하는 수단이 없습니다. 시각적 테이블 디자이너에서이 작업을 수행 할 수 있지만 SQL Server는 원하는 열 순서가있는 새 테이블을 만든 다음 이전 테이블의 모든 데이터를 복사합니다. 이것이 대형 테이블의 작업이 매우 지루하고 시간이 오래 걸리는 이유입니다.
예, 열을 재정렬하기 위해 테이블을 다시 만들어야한다는 사실을 알고 있습니다. 그러나 Charles Bretana는 SQL Studio의 열 순서가 DB에 실제로 저장된 것과 같지 않다고 말하는 것 같습니다. –
@ liho1eye : 그렇습니다. 나는 그 사실을 읽는 데 너무 놀랐습니다. 사실인지, 그 사실에 대한 어떤 언급도 찾을 수 없습니까. –
@ liho1eye, @marc_s : 디스크상의 스토리지를 살펴보면, 고정 길이 컬럼이 먼저 가변 길이가됩니다. "string last"에 대한 오래된 격언은 IMHO 쓰레기입니다. http://www.sqlskills.com/BLOGS/PAUL/post/Inside-the-Storage-Engine-Anatomy-of-a-record.aspx 또는 MSDN/BOL too – gbn
@marc_s : 물론 참고 자료가 있습니다 ... http://www.sqlskills.com/BLOGS/PAUL/post/Inside-the-Storage-Engine-Anatomy-of-recrec.aspx 또는 MSDN/BOL too – gbn