एक टेबल के साथ कई में से एक

Question

मैं एक टेबल का उपयोग करके कई संबंधों में से एक बनाने की कोशिश कर रहा हूं। क्या यह संभव है?

create table user(id int primary key auto_increment not null,                              
created_by int default null                                       
)ENGINE=INNODB;                                          

alter table user add foreign key (created_by) references user(id) ON DELETE SET NULL ON UPDATE CASCADE;                    

insert into user (id) VALUES(1);                                     
insert into user (id, created_by) VALUES (2,1); 

अब जब मैं आईडी = 1 created_by के मूल्य के साथ उपयोगकर्ता को हटा automaticaly शून्य करने के लिए बदल के रूप में मैं उम्मीद थी।

लेकिन जब मैं आईडी = 1 के साथ उपयोगकर्ता की आईडी को बदलने मैं यह त्रुटि

mysql> update user set id=2 where id=1; 
ERROR 1451 (23000): Cannot delete or update a parent row: a foreign key constraint fails (`jrt`.`user`, CONSTRAINT `user_ibfk_1` FOREIGN KEY (`created_by`) REFERENCES `user` (`id`) ON DELETE SET NULL ON UPDATE CASCADE) 

मैं इसे कैसे ठीक कर सकते हैं? इस अद्यतन को ठीक करें मैं चाहता हूं कि स्तंभ बनाया गया हो जिसे कैस्केड बदला जा सके।

Answer 1

कुंजी बदलने के लिए नहीं हैं, वे 'पहचान' होने के लिए हैं। तो आईडी 2 वाला उपयोगकर्ता तार्किक रूप से आईडी के साथ उपयोगकर्ता के साथ एक अलग उपयोगकर्ता है। जिस पल में आप एक अद्वितीय उपयोगकर्ता बनाते हैं, वह प्राथमिक कुंजी उस उपयोगकर्ता के जीवनकाल के लिए समान होनी चाहिए।

तो यह वास्तव में एक डिजाइन मुद्दा है। आपको सवाल करना होगा कि आप किसी विशेष उपयोगकर्ता के लिए आईडी क्यों बदलना चाहते हैं। हो सकता है कि आप जो चाहते हैं वह एक निश्चित पहचान कुंजी और दूसरा पहचानकर्ता (जो कुंजी नहीं है और पूरी तरह से उपयोगकर्ता तालिका पर मौजूद है) जिसे आप बदल सकते हैं।

[अधिक जानकारी के साथ अपडेट किया गया] संबंधपरक डेटाबेस डिज़ाइन के मूलभूत सिद्धांतों पर यहां संसाधन (कई ऑनलाइन उपलब्ध हैं) हैं। http://www.deeptraining.com/litwin/dbdesign/FundamentalsOfRelationalDatabaseDesign.aspx

प्रासंगिक अनुभाग "टेबल्स, विशिष्टता और कुंजी" है।

फैबियन पास्कल, अपनी पुस्तक एसक्यूएल और संबंधपरक मूल बातें में, लिखते हैं कि निर्णय ( सबसे कम कॉलम आवश्यक चुनें) minimality के सिद्धांतों पर आधारित होना चाहिए, स्थिरता (एक महत्वपूर्ण यह है कि शायद ही कभी परिवर्तन चुनें), और सादगी/परिचितता (एक कुंजी चुनें जो सरल दोनों और उपयोगकर्ताओं से परिचित है)।

व्यक्तिगत रूप से, मैं स्थिरता पर आगे जाऊंगा; एक कुंजी चुनने का प्रयास करें जो कभी नहीं बदलेगा। उदाहरण के लिए, उपयोगकर्ता के लिए "ईमेल" कुंजी की खराब पसंद होगी क्योंकि उपयोगकर्ता अपना ईमेल बदल सकता है। यदि आप एक कुंजी चुनते हैं, जैसे आंतरिक रूप से जेनरेट किया गया नंबर या शायद कर्मियों की प्रणाली से एक अद्वितीय पहचानकर्ता, तो आपको इस बदलाव को अन्य तालिकाओं में बदलने और माइग्रेट करने की चिंता करने की आवश्यकता नहीं है।

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

भी देखें:When to use "ON UPDATE CASCADE"

भी ध्यान रखें:http://forums.mysql.com/read.php?136,391782,391782