1

eqtype_jobs이라는 세 번째 테이블을 만들었으므로 Many to Many 관계가 jobseqtypes 사이에 있습니다. 그러나,이 관계에서 정규화, 테이블 내가 예를 들어, 독립적 인 기본 키 id을 만들지 않았어, 난 그냥 job_ideqtype_id 기본 키로 설정합니다.Many to Many conjugation 테이블에 파티션이 정의되어 있지 않습니다.

CREATE TABLE `eqtype_jobs` (
    `job_id` int(10) UNSIGNED NOT NULL, 
    `eqtype_id` int(4) UNSIGNED NOT NULL 
) ENGINE=InnoDB DEFAULT CHARSET=utf8; 

-- 
-- Indexes for dumped tables 
-- 

-- 
-- Indexes for table `eqtype_jobs` 
-- 
ALTER TABLE `eqtype_jobs` 
    ADD PRIMARY KEY (`eqtype_id`,`job_id`), 
    ADD KEY `job_id` (`job_id`); 

-- 
-- Constraints for dumped tables 
-- 

-- 
-- Constraints for table `eqtype_jobs` 
-- 
ALTER TABLE `eqtype_jobs` 
    ADD CONSTRAINT `eqtype_jobs_ibfk_1` FOREIGN KEY (`job_id`) REFERENCES `jobs` (`id`) ON DELETE CASCADE ON UPDATE CASCADE, 
    ADD CONSTRAINT `eqtype_jobs_ibfk_2` FOREIGN KEY (`eqtype_id`) REFERENCES `eqtypes` (`id`) ON DELETE CASCADE ON UPDATE CASCADE; 

이 I 독립 기본 키를 이용 id 생략 첫 번째 테이블이 다음은 테이블 구조이다. 나는 다른 많은 many to 관계를 사용하고 id 전에.

가 없음 파티션을 정의하지 : eqtype_jobs 테이블 구조를 표시 할 때 그러나, phpMyAdmin에는 다음과 같은 통지를 보여줍니다!

인해 독립적 인 기본 키, I, E id의 부재로 분할에 대한이 메시지의 원인을합니까? 또는 테이블의 복합 기본 키가 잘 정의되어 있지 않습니다. 이 부분에 대한 통지는 향후 실적에 부정적인 영향을 미칩니 까?

답변

3

아니요, 메시지가 테이블 구조에 아무런 문제가 없다고 말하지 않습니다. 문법 및 UI 측면에서 보면 느낌표를 사용하는 것이 다소 이상하지만 여기에는 문제가 없습니다.

Partitioning은 데이터가 디스크에 저장되는 방식을 나누는 방법입니다. 표시되는 구조 페이지의 영역은 파티션 작업 (사진 참조)을 다루며, 파티션이 구성되지 않은 경우 경고 한 알림을 볼 수 있습니다. 파티션이 구성되어있는 경우

No partitions

, 당신은 매개 변수가 표시됩니다

Partition display

그래서 안전하게 해당 페이지의 파티션 부분을 무시할 수 있습니다.