내 대상 DB는 MySQL이지만이 문제를보다 "일반적인"방식으로 볼 수 있습니다. 필요한 테이블 구조를 수정할 프레임 워크를 만들려고합니다. 테이블에는 언젠가 수천 개의 레코드가 포함될 수 있습니다. 열을 추가하거나 열의 이름을 바꾸거나 열의 유형을 변경할 수도 있습니다 (불가능한 것은 아닙니다. 예를 들어 숫자 열을 varchar 열로 만 변경할 수도 있음). 또는 전체 열을 삭제할 수도 있습니다. 하지만 대부분의 경우 열을 추가합니다.큰 테이블의 구조를 변경하는 것이 얼마나 좋지 않습니까?
누군가가 매우 나쁜 아이디어라고 말해 줬어. 그는 매우 시끄럽고 명료하지만 더 이상의 논쟁은하지 않았습니다. 그래서 당신은 어떻게 생각하십니까? 나쁜 생각? 왜?
대부분의 데이터베이스에서 열을 추가하거나 이름을 바꾸는 것은 테이블 메타 데이터를 변경하는 간단한 작업입니다. 실제로 사용중인 MySQL 스토리지 엔진의 경우인지 확인해야합니다. 컬럼을 삭제하는 것은 너무 가볍습니다.
대조적으로 열의 유형을 변경하는 것은 실제로 테이블의 각 행에 대한 데이터를 생성하기 때문에 집중적 인 작업입니다. 마찬가지로, 열을 추가하고 채 웁니다 (새 열의 값을 null로 두지 않고).
데이터베이스는 데이터 무결성, 참조 무결성 및 트랜잭션 무결성을 처리하기 위해 몇 가지 사항을 잘 수행하도록 설계되었습니다. 테이블 구조를 망칠 때 (기존 데이터와 관계가있을 때)이 세 가지를 모두 동시에 위반하고있을 것입니다.
데이터 표시 방법 (표시 여부, 열 이름 변경 등)을 조정하려면 많이으로보기를 통해 데이터를 노출하고 필요합니다. 그러나 테이블을 혼자 두십시오!
나쁜 생각입니다.
이 열을 사용하는 클라이언트 응용 프로그램이 있으므로 열 이름을 바꾸거나 제거 할 때마다 코드가 중단됩니다.
때때로 열의 유형을 변경하는 것이 필요할 수도 있지만, 그렇게해야하는 것은 아닙니다. 열이 숫자이고 계산을 수행하면 varchar 유형으로 변경할 수 없습니다. 그리고 계산에 필요하지 않고 나중에 숫자가 아닌 문자가 필요할 경우 varchar로 정의하지 않으시겠습니까?
데이터의 무결성이 손상되고 쿼리가 하드 코딩되거나 부적절한 ORM이 발생해도 쿼리가 실패하므로 매우 위험하므로 피해야합니다. 신중해야하고 라이브로 DB를 먼저 백업해야합니다.
이유에 대한 자세한 정보를 제공해 주시겠습니까? –
글쎄, 비즈니스 로직이 수정되지 않고 변경 될 수 있습니다. 그래서 내 프레임 워크에서 테이블 구조를 변경해야 할 수도 있습니다. 즉, User 객체는 데이터베이스에 2 백만 명의 사용자가있는 5 년 후에 age 속성을 가져옵니다. 다른 솔루션은 메타 데이터베이스가 될 것이지만 성능이 가장 낮은 수준으로 내려갈 것입니다. – openfrog