2012-11-22 10 views
16

है मैं निम्नलिखित संरचना के साथ एक मेज को अपडेट करना होगा:MySQL 5.5.24 - अद्यतन पर डुप्लिकेट प्रविष्टि, जब वहाँ कोई वास्तविक डुप्लिकेट

INSERT INTO `eav_entity_attribute` 
(`entity_attribute_id`, `entity_type_id`, `attribute_set_id`, `attribute_group_id`, `attribute_id`, `sort_order`) 
VALUES 
(32758, 4, 224, 3423, 5171, 12) 

:

CREATE TABLE `eav_entity_attribute` (
    `entity_attribute_id` int(10) unsigned NOT NULL AUTO_INCREMENT COMMENT 'Entity Attribute Id', 
    `entity_type_id` smallint(5) unsigned NOT NULL DEFAULT '0' COMMENT 'Entity Type Id', 
    `attribute_set_id` smallint(5) unsigned NOT NULL DEFAULT '0' COMMENT 'Attribute Set Id', 
    `attribute_group_id` smallint(5) unsigned NOT NULL DEFAULT '0' COMMENT 'Attribute Group Id', 
    `attribute_id` smallint(5) unsigned NOT NULL DEFAULT '0' COMMENT 'Attribute Id', 
    `sort_order` smallint(6) NOT NULL DEFAULT '0' COMMENT 'Sort Order', 
    PRIMARY KEY (`entity_attribute_id`), 
    UNIQUE KEY `UNQ_EAV_ENTITY_ATTRIBUTE_ATTRIBUTE_SET_ID_ATTRIBUTE_ID` (`attribute_set_id`,`attribute_id`), 
    UNIQUE KEY `UNQ_EAV_ENTITY_ATTRIBUTE_ATTRIBUTE_GROUP_ID_ATTRIBUTE_ID` (`attribute_group_id`,`attribute_id`), 
    KEY `IDX_EAV_ENTITY_ATTRIBUTE_ATTRIBUTE_SET_ID_SORT_ORDER` (`attribute_set_id`,`sort_order`), 
    KEY `IDX_EAV_ENTITY_ATTRIBUTE_ATTRIBUTE_ID` (`attribute_id`) 
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='Eav Entity Attributes' 

तालिका के ऊपर एक ही पंक्ति में शामिल है मैं एक स्वचालित आयात प्रक्रिया चला रहा हूं, जो डेटा के बाहरी स्रोत को पढ़ेगा और इस तालिका में लिख देगा।

यह आयात कई बार चलता है और इसलिए, कभी-कभी एक ही डेटा कई बार आयात किया जाता है। ऐसे मामले में, प्रक्रिया पुराने डेटा को केवल नए के साथ ओवरराइट करती है, भले ही नया व्यक्ति पुराने जैसा हो। वह स्थिति जहां एक ही डेटा मौजूद है, एक ऑन डिप्लिकेट कुंजी अद्यतन खंड के साथ संभाला जाता है। यह इस विशिष्ट तालिका को छोड़कर लगभग पूरी तरह से काम करता है।

इस तालिका पर, जब प्रक्रिया अद्यतन की कोशिश करती है, तो मुझे एक "डुप्लिकेट कुंजी" संदेश मिलता है, जिसे मैं समझा नहीं सकता। मैं कोड डिबग, और इस क्वेरी कि विफल रहता है (INSERT..ON नकली चाबी से निकाले) है:

UPDATE eav_entity_attribute 
SET 
    `attribute_group_id` = 3423 
    ,`attribute_id` = 5171 
    ,`attribute_set_id` = 223 
    ,`entity_type_id` = 4 
    ,`sort_order` = 320 
WHERE 
    (`attribute_group_id` = 3423) AND 
    (`attribute_id` = 5171) 

त्रुटि निम्नलिखित है:

Error Code: 1062. Duplicate entry '3423-5171' for key 'UNQ_EAV_ENTITY_ATTRIBUTE_ATTRIBUTE_GROUP_ID_ATTRIBUTE_ID' 

मुझे पता है कि इस जोड़ी को 3423 -5171 पहले से मौजूद है, लेकिन अद्यतन इन मानों को अपने साथ बदल देगा, न कि नई प्रविष्टि बनाएगा। मैं इस मुद्दे के कारण के बारे में काफी उलझन में हूं, किसी भी सुझाव का बहुत स्वागत है। धन्यवाद।

अद्यतन - नई खोजने

मैं "प्रेरणा" किसी प्रकार का हो गया और मैं एक प्रयोग किया जाता। मैंने (attribute_set_id, attribute_id) (नोट, यह त्रुटि में से एक नहीं है) में शामिल अनन्य बाधा को हटा दिया और मैंने INSERT..ON डिप्लिकेट क्वेरी चलायी। यह पूरी तरह से काम किया।

मेरा एक अनुमान है, लेकिन इस मैं क्या सोचता है: डेटा मैं दो बाधाओं के साथ तालिका संघर्ष करने के लिए लिखने के लिए कोशिश कर रहा हूँ:

  • अद्वितीय (attribute_set_id, attribute_id)
  • अद्वितीय (attribute_group_id , attribute_id)

सम्मिलित करें शायद पहले बाधा द्वारा उठाए गए दोहराव त्रुटि के कारण विफल रहता है,। यह UPDATE को ट्रिगर करता है, जो पहली बाधा का उपयोग निहित WHERE खंड के रूप में करता है। मेरी अटकलें यह है कि, इस तरह के मामले में, पहली बाधा किसी भी तरह से अनदेखा की जाती है, लेकिन दूसरी बार अद्यतन यात्राएं, जो पहले शामिल नहीं थीं।

यह अभी भी मेरे लिए एक अद्यतन कारण नहीं है, जो एक डुप्लिकेट एंट्री त्रुटि बढ़ाने के लिए अपने साथ कुछ बदल देता है, लेकिन यह इसके पीछे तर्क पर कुछ प्रकाश डाल सकता है।

दूसरा अद्यतन

मुझे पता चला कि मैं वास्तव में मेज के खिलाफ परीक्षण किया गया था पंक्तियों की एक बहुत कुछ शामिल अन्य डेटा के सफल आयात से उत्पन्न (मैं फ़िल्टर किए गए दृश्य को निष्क्रिय करना भूल गया)।हालांकि, सेट में "डुप्लिकेट उम्मीदवार" अभी भी अद्वितीय है।

मैं पुष्टि करता हूं कि टिप्पणियों में क्या पोस्ट किया गया था, जब तालिका में केवल पंक्तियां होती हैं, INSERT..ON डिप्लिकेट काम करता है, साथ ही साथ अद्यतन भी। अब मैं सोच रहा हूं कि इसमें अधिक डेटा होने पर तालिका को गड़बड़ क्यों किया जाता है, क्योंकि हम अभी भी एक ही डेटा के साथ अपडेट की जाने वाली एक अनूठी पंक्ति के बारे में बात कर रहे हैं।

तीसरा अपडेट - मिले मूल कारण

मैं अंत में कारण पता चला क्यों अद्यतन विफल रहता है, अब मैं पता लगाने के लिए मैं ऐसे हालत में मिलता है की है।

सुराग पहले अद्यतन में मेरी अनुमान था। बस, मेरे पास दो बहुत ही समान पंक्तियां हैं (कृपया ध्यान दें कि मैं अलग-अलग मानों का उपयोग कर रहा हूं जैसा कि मैंने एक स्वच्छ डेटाबेस से शुरू किया था)।

row,entity_attribute_id,entity_type_id,attribute_set_id,attribute_group_id,attribute_id,sort_order 
1,16919, 4, 120, 1746, 80, 1 
2,16649, 4, 119, 1744, 80, 210 

यहाँ क्या होता है:

  • सम्मिलित करें निम्न मान के साथ एक पंक्ति सम्मिलित करने का प्रयास: 120, 4, 1744, 80, 54
  • यह "डुप्लिकेट कुंजी" ट्रिगर करता है, क्योंकि 120, 80 फ़ील्ड attribute_set_id, attribute_id (पंक्ति 1) के लिए डुप्लिकेट हैं।
  • MySQL तो अद्यतन, जो इस प्रकार हो जाता है की कोशिश करता है:

    अद्यतन तालिका entity_type_id = 4 , attribute_group_id = 1744 , sort_order = 54 कहां (attribute_set_id = 120) और (attribute_id = 80)

  • इस बार, अद्यतन विफल रहता है क्योंकि 1744,80 मूल्य attribute_group_id, attribute_id पर पंक्ति 2 में पाया गया है,

सारांश

  • सम्मिलित में विफल रहता है क्योंकि पंक्ति 1 कुंजी attribute_set_id, attribute_id के लिए एक ही मान होते हैं।
  • अद्यतन विफल रहता है क्योंकि पंक्ति 2 कुंजी attribute_group_id, attribute_id के लिए एक ही मान होते हैं।

समाधान

मैं पूरी आयात प्रक्रिया की समीक्षा करने के, के रूप में, सिद्धांत रूप में, इस तरह के डुप्लिकेट में से कोई भी उत्पन्न होता है तो करना होगा। MySQL अपना काम ठीक कर रहा है, यह डेटाबेस है जो जटिल है।

सभी सुझावों के लिए धन्यवाद।

+0

MySQL 5.5.24। मैंने इसे शीर्षक में जोड़ा। – Diego

+3

अजीब, 5.5.28 में काम करता है। http://sqlfiddle.com/#!2/81569 –

+1

यह 5.5 में काम करता है।प्रश्न से पूछताछ के साथ 20; यह तालिका के आकार का आकार है, मुझे लगता है। – raina77ow

उत्तर

2

के UPDATE खंड के भीतर प्रमुख मानों को अपडेट न करने का प्रयास करें। MySQL से महत्वपूर्ण मूल्यों को बदलने के लिए यह अजीब बात है कि इन महत्वपूर्ण मानों के साथ एक रिकॉर्ड पहले से मौजूद है, इसलिए, MySQL का अप्रत्याशित व्यवहार आश्चर्यजनक नहीं है।

+0

का उपयोग करते हुए 'पर नकली चाबी UPDATE' किसी भी अजीब व्यवहार में परिणाम नहीं करता है, इस मुद्दे के कारण परिस्थितियों की एक श्रृंखला के लिए गया था और यह अब हल है। मैं इसे पूरा करने का एक पूरा उत्तर तैयार कर रहा हूं। – Diego

+0

इस उत्तर की तरह लगता है बहुत करीब था! डुप्लिकेट कुंजी अपडेट के अंदर एक महत्वपूर्ण मूल्य के लिए एक अद्यतन निश्चित रूप से अपराधी था। (केवल मुझे लगता है कि चेतावनी यह है कि MySQL इन परिस्थितियों में भी एक अपेक्षित तरीके से व्यवहार किया) –

संबंधित मुद्दे