आपकी त्रुटियां गलत विदेशी कुंजी सिंटैक्स के कारण होती हैं।
हालांकि, मुझे लगता है कि आपको स्ट्रिंग समग्र प्राथमिक कुंजी करने के बजाय आईडी फ़ील्ड का उपयोग करना चाहिए . आपके तरीके में कुछ समस्याएं हैं...
-
इसमें शामिल होने के लिए एक पूर्णांक (आईडी) फ़ील्ड का उपयोग करने की तुलना में डीबी के लिए तालिकाओं में शामिल होना कठिन हो जाएगा (कठिन ==अधिक प्रसंस्करण समय)।
-
एक ही नाम के कई लोगों का होना मान्य है, यहाँ तक कि मध्य नाम के अक्षर का भी उपयोग करना।
-
यदि आपको किसी का नाम बदलना पड़े तो क्या होगा? या तो क्योंकि इसे गलत रखा गया था या उन्होंने शादी कर ली थी या कुछ भी... इसका मतलब है कि आपको न केवल अपने
employee
को अपडेट करना होगा तालिका, लेकिनworks
तालिका और कोई अन्य तालिका जिसे आपने विदेशी कुंजी के रूप में नाम का उपयोग किया है।
इसे देखें:http://sqlfiddle.com/#! 2/2dc8c/3/0
मैंने प्रत्येक तालिका में एक तालिका आईडी जोड़ी है . यह एक unsigned int
है , जिसका अर्थ है कि यह ऋणात्मक नहीं हो सकता (क्योंकि इसका अधिक अर्थ नहीं होगा)। यह auto_increment
भी है , जिसका अर्थ है कि हर बार जब आप तालिका में एक पंक्ति जोड़ते हैं, तो यह आईडी स्वतः उत्पन्न हो जाएगी और 1 बढ़ जाएगी।
create table Employee (
Employee_ID int unsigned auto_increment primary key,
Lastname varchar(10),
FirstName varchar(10),
MidInitial char(1),
gender char(1),
street varchar(10),
city varchar(10),
unique (Lastname, FirstName, MidInitial)
);
आप इस तालिका में चीजों को इस तरह जोड़ेंगे:
insert into Employee (Employee_ID, LastName, FirstName, MidInitial)
values (null, 'Smith', 'John', 'K');
null
स्वचालित रूप से जेनरेट की गई आईडी बन जाएगी। यह प्रत्येक पंक्ति के लिए अद्वितीय होगा।
साथ ही, एक अद्वितीय बाधा इसका मतलब है कि इन क्षेत्रों का संयोजन तालिका में अद्वितीय होना चाहिए। हालांकि, एक बड़ी पर्याप्त कंपनी के साथ, मैं शर्त लगाता हूं कि दो लोगों का एक ही नाम होगा। वास्तविक जीवन में, मैं इस अनूठी बाधा को दूर करने का सुझाव दूंगा।
मैंने कंपनी तालिका में समान परिवर्तन किए हैं...
create table company(
company_ID int unsigned auto_increment primary key,
company_name varchar(20),
city varchar(10),
unique (company_name)
);
चीजें जोड़ी जा सकती हैं जैसे:
insert into company values (null, 'Taco Bell', 'Paris');
तो... works
. के लिए .... इस तालिका में प्रत्येक व्यक्ति का पूरा नाम और कंपनी का पूरा नाम बार-बार संग्रहीत करने के बजाय, अब हमें केवल आईडी को स्टोर करना होगा।
create table Works (
works_id int unsigned auto_increment primary key,
employee_id int unsigned,
compay_id int unsigned,
salary numeric(8,2),
foreign key (employee_id) references Employee (employee_id),
foreign key (compay_id) references company (company_id)
);
आप चीजों को works
में जोड़ सकते हैं इस तरह:
insert into Works values (null, 1, 1, '10.00');
चूंकि जॉन स्मिथ हमारा पहला कर्मचारी था, उसका कर्मचारी_आईडी 1 होगा। इसे सत्यापित करने के लिए, बस select * from Employee where FirstName='John' and LastName='Smith'
. टैको बेल को company_id =1 भी मिलेगा। उन मानों को works
. में डालने से , इसका मतलब है कि जॉन अब टैको बेल में काम करता है।
मैं यह भी सुझाव दूंगा कि आप start_date
. जैसे फ़ील्ड जोड़ें और end_date
और job_title
अपने काम की मेज पर। और आप इस तालिका के लिए किन्हीं विशिष्ट बाधाओं पर भी विशेष ध्यान देना चाहेंगे। लोग एक ही कंपनी के लिए एक से अधिक बार काम कर सकते हैं। उनके पास अलग-अलग काम भी हो सकते हैं।
जब आप अपना डेटा वापस पाना चाहते हैं, तो आप इस तरह की क्वेरी का उपयोग करेंगे:
select FirstName, MidInitial, LastName,
Company_Name,
Salary
from employee
join works
on works.employee_id = employee.employee_id
join company
on works.company_id = company.company_id
जो यह कहने का एक शानदार तरीका है:
select FirstName, MidInitial, LastName,
Company_Name,
Salary
from employee, works, company
where employee.employee_id = works.employee_id and
company.company_id = works.company_id
डेटाबेस चीजों पर कुछ नोट्स...
-
एक नामकरण परंपरा चुनें और उस पर टिके रहें! यदि आप
CamelCase
. का उपयोग करना चाहते हैं , इसे हर जगह इस्तेमाल करें। अगरyou_want_to_use
आपके नाम में अंडरस्कोर, हर जगह उनका इस्तेमाल करें। इसमें से चुनने के लिए कई नामकरण परंपराएं हैं:तालिका नाम के साथ उपसर्ग विशेषताएँ (कॉलम/फ़ील्ड), सामान्य संक्षिप्ताक्षरों (या नहीं) का उपयोग करते हुए, जहां पूंजीकरण का उपयोग किया जाता है (या नहीं) ... यह ज्यादातर व्यक्तिगत पसंद के लिए आता है लेकिन वहाँ कुछ लोगों के उपयोग के बारे में पेशेवरों और विपक्षों के बारे में लेख हैं। अंतिम नोट, _just क्योंकि आप किसी नाम में रिक्त स्थान का उपयोग कर सकते हैं,__ इसका मतलब यह नहीं है कि आपको चाहिए।`Almost all`
डेटाबेस[you use spaces]
. करते हैं यदि आप चाहें तो नामों में लेकिन यह बाद में बहुत सारी समस्याएँ पैदा कर सकता है। -
तालिका नाम बहुवचन नहीं होने चाहिए। यह मेरा एक पेट-पीव है और यहां क्यों है:हम जानते हैं कि एक टेबल कई रिकॉर्ड रखेगी ... कई लोग/व्यक्ति, कई कर्मचारी, कई कंपनियां, किसी भी प्रकार या प्रकार की कई प्रविष्टियां। प्रत्येक पंक्ति केवल एक . का वर्णन करती है इन चीजों का। कभी-कभी यह भी समझ में नहीं आता कि नाम बहुवचन है। दूसरी बार, यह संदिग्ध है - जैसे
works
मेज़। यदि आप इसे कभी बहुवचन बनाते हैं, और कभी इसे एकवचन बनाते हैं, तो यह बाद में भ्रमित हो सकता है। इसे केवल एकवचन बनाकर, यह अभी भी सही समझ में आता है, और आप आगे और पीछे स्विच नहीं कर रहे हैं या प्रश्न लिखते समय सटीक नाम नहीं देख रहे हैं। -
डेटाटाइप महत्वपूर्ण हैं और समान फ़ील्ड के लिए सभी तालिकाओं में सुसंगत रहने का प्रयास करें (जैसे सभी
id
एस एक ही प्रकार; सभी बूलियन फ़ील्ड को सभी बिट्स या पूर्णांक या जो कुछ भी बनाएं, बस उन्हें वही बनाएं)। आपके द्वारा चुने जा सकने वाले पूर्णांक प्रकारों के विभिन्न आकार हैं। आकार, प्रदर्शन और आपकी आवश्यकताओं के लिए क्या उपयुक्त है, इसके बारे में सोचें। तय करें कि क्या आपको वास्तव में एक nvarchar की आवश्यकता है या यदि कोई varchar ठीक है।- तारीखें कभी नहीं होनी चाहिए एक स्ट्रिंग के रूप में संग्रहीत किया जाना चाहिए। उपयुक्त दिनांक, दिनांक समय, समय या टाइमस्टैम्प डेटाटाइप का उपयोग करें . यह आपको बाद में बहुत मदद करेगा जब आपको इसे पुनः प्राप्त करने, इसकी तुलना करने या गणना में इसका उपयोग करने की आवश्यकता होगी। एक अन्य महत्वपूर्ण निर्णय यह है कि आपने समयक्षेत्र . को कैसे संभालना चुना है . जब उपयोगकर्ता को जानकारी प्रस्तुत की जाती है, तो मैं यूटीसी में सबकुछ स्टोर करना चाहता हूं और किसी भी टाइमज़ोन ऑफ़सेट चीजों को फ्रंट एंड पर संभालना चाहता हूं। यह सब कुछ सुसंगत रखता है और मुझे इस बारे में चिंता करने की ज़रूरत नहीं है कि क्या पंक्ति मेरे उपयोगकर्ता के कंप्यूटर समय, उपयोगकर्ता के ब्राउज़र समय, मेरे डेटाबेस के समय या सर्वर के समय के आधार पर शाम 6 बजे डाली गई थी।
ली>
- तारीखें कभी नहीं होनी चाहिए एक स्ट्रिंग के रूप में संग्रहीत किया जाना चाहिए। उपयुक्त दिनांक, दिनांक समय, समय या टाइमस्टैम्प डेटाटाइप का उपयोग करें . यह आपको बाद में बहुत मदद करेगा जब आपको इसे पुनः प्राप्त करने, इसकी तुलना करने या गणना में इसका उपयोग करने की आवश्यकता होगी। एक अन्य महत्वपूर्ण निर्णय यह है कि आपने समयक्षेत्र . को कैसे संभालना चुना है . जब उपयोगकर्ता को जानकारी प्रस्तुत की जाती है, तो मैं यूटीसी में सबकुछ स्टोर करना चाहता हूं और किसी भी टाइमज़ोन ऑफ़सेट चीजों को फ्रंट एंड पर संभालना चाहता हूं। यह सब कुछ सुसंगत रखता है और मुझे इस बारे में चिंता करने की ज़रूरत नहीं है कि क्या पंक्ति मेरे उपयोगकर्ता के कंप्यूटर समय, उपयोगकर्ता के ब्राउज़र समय, मेरे डेटाबेस के समय या सर्वर के समय के आधार पर शाम 6 बजे डाली गई थी।
-
एक
ID
शामिल करें फ़ील्ड यह प्रत्येक तालिका में पंक्ति के लिए अद्वितीय है। ऐसा करने का सबसे आसान तरीकाauto_increment
. का उपयोग करना है (mysql) याidentity(1,1)
(एसक्यूएल सर्वर) फ़ील्ड ताकि डेटाबेस आपके लिए इसका ट्रैक रखे। जरूरत पड़ने पर इन मूल्यों को रीसेट या फिर से शुरू किया जा सकता है। -
जानें कि लेन-देन करते हैं और वे क्यों महत्वपूर्ण हैं... भले ही आप उनका उपयोग न करें।
-
विभिन्न प्रकार के जुड़ावों के बारे में जानें . यह सबसे अच्छी व्याख्याओं में से एक है मैंने कभी देखा है। ध्यान देने वाली मुख्य बात यह है कि क्या जुड़ाव बाहरी या आंतरिक जुड़ाव होना चाहिए।
-
एसक्यूएल इंजेक्शन के बारे में जानें और अधिक महत्वपूर्ण बात, कैसे इसे रोकने के लिए (वह लिंक PHP के लिए है)।
-
यदि आप PHP का उपयोग कर रहे हैं, तो पुराने
mysql_
का उपयोग न करें कक्षा। इसके बजाय,PDO
. का उपयोग करें याMySQLi_
. जानकारी... -
डेटाबेस के बारे में सबसे बड़ी बात है डेटा अखंडता, सत्यापन और स्वच्छता . उपयोगकर्ता सभी प्रकार के मैला, गंदे डेटा को आपकी टेबल में रखना चाहेंगे। क्या यह एमओ या मिसौरी है? महिला, एफ, महिला, लड़की, या हाँ? क्या वेतन 15.00 प्रति घंटा, 50k सालाना या 3,000 तनख्वाह है? क्या यह 12/31/2013, 31/12/2013, 12-31-13, 31 दिसंबर, 2013 या दिसंबर बत्तीस दो हजार तेरह है?
-
निर्णय लें कि क्या आप
NULL
को अनुमति देना चाहते हैं या नहीं। यह ट्रिपल स्टेट लॉजिक के कारण चीजों को और अधिक जटिल बना देता है और आपको बाद में इसकी जांच करनी होगी। कुछ लोग इसके बजाय केवल एक खाली स्ट्रिंग का उपयोग करने का निर्णय लेते हैं। शून्य एक वास्तविक मूल्य से अधिक एक राज्य है और इसका अर्थ है अपरिभाषित या अज्ञात - मूल्य कुछ भी हो सकता है। मैं शून्य का उपयोग करता हूं क्योंकि एक खाली स्ट्रिंग कभी-कभी किसी फ़ील्ड के लिए मान्य मान होती है। उदाहरण के लिए,Middle_Initial
सेट करना एक खाली स्ट्रिंग के बराबर होने का मतलब यह हो सकता है कि व्यक्ति के पास मध्य अक्षर नहीं है या इसका मतलब यह हो सकता है कि आप नहीं जानते कि यह क्या है। मेरे लिए ये चीजें अलग हैं। अन्य लोगों के लिए, अंतर कोई मायने नहीं रखता। केवल संख्याओं पर विचार करें... क्या 0 अज्ञात के समान है? -
यदि और कुछ नहीं, तो बस सुसंगत रहें।