file_table { id, name, status}과 extra_data table { id, fileId FK(file.id), otherData}을 사용하는 것은 나쁜 습관인지 궁금합니다. 지금까지 모든 테이블이 앞으로 나아 갔고 ID를 사용하여 더 많은 데이터를 얻기 위해 쿼리를 수행 할 필요가 없었습니다.외래 키로 '뒤로 이동'하는 것은 나쁜 습관입니까?
이 나쁜 습관입니까? 그렇다면 이유는 무엇입니까?
이것은 나쁜 습관이 아닙니다. 실제로 견고한 디자인이 어떻게 보일 것입니다. 지금 당신은 테이블 파일과 extra_data와 '관계'를 수립했습니다. 그러나 DB가 정규화되기 위해서는 테이블 간의 관계의 카디널리티를 고려해야합니다. 그 카디널리티에 따라 FK를 배치하는 방법을 알게되거나 새로운 관계 테이블을 생성하게됩니다. 카디널리티에 대한 자세한 내용을 찾을 수 있습니다. here
동의 함, 세부 정보가 너무 많아서 필수 카디널리티를 지정할 수 없습니다. 모든 컬럼이 NULL 가능하다면 키가 없다. – onedaywhen
아무 문제가 없습니다.
매우 이상적입니다. 레이아웃으로 설계된 테이블은 하나의 file_table 레코드가 0 개 이상의 extra_data 레코드와 연관 될 수 있음을 확립합니다. 그러나 하나의 extra_data 레코드는 하나의 file_table 레코드에만 연결할 수 있습니다.
거꾸로 돌아가서 무엇을 의미합니까?
그는 외래 키 방법은 "나는 'Foo'라는 책이다. 나는 오크 책장에있다."객체 지향적 방법은 "나는 오크 책장이다. 나는 다음과 같은 책을 포함하고있다."라고 말하면서, 'Foo', 'Bar', 'Baz ''. 링크가 반대 방향입니다. – Timmmm
다른 항목과 연관된 항목 모음을 구현하는 다른 방법을 생각할 수 없습니다. 내가 여기서 무엇을 놓치고 있니?
담당자를 볼 때 왜 내가 Arby를 생각합니까? –
@mmyers는 나를 TV 전화 번호 (555-555-5555)로 생각 나게합니다. –
누군가가 그것을 마쳤습니다! –