1. Learning Outcomes#

2. एका row ला स्वतःची ओळख का हवी?#

समजा आपल्या database मध्ये students नावाचा table आहे.

त्यात असा data आहे:

इथे दोन students चे नाव Amit Patil आहे.

आता application ला सांगितले:

"Amit Patil चा city update करा."

Database चा पहिला प्रश्न असू शकतो:

"कोणता Amit Patil?"

हीच खरी problem आहे.

name हा column उपयोगी आहे, पण तो प्रत्येक row ची खात्रीशीर ओळख देत नाही.

दोन लोकांची नावे सारखी असू शकतात.

पण student_id पाहा:

• 101
• 102
• 103

प्रत्येक student साठी वेगळी value आहे.

म्हणून application सहज सांगू शकते:

UPDATE students
SET city = 'Nagpur'
WHERE student_id = 103;

आता confusion नाही.

आपल्याला नेमका कोणता row बदलायचा आहे हे स्पष्ट आहे.

थोडक्यात, database ला "हा कोण?" या प्रश्नाचे एकदम स्पष्ट उत्तर हवे असते.

गावात दोन माणसांचे नाव सारखे असले तरी घर क्रमांक वेगळा असतो. Database मध्येही अशीच काहीतरी पक्की ओळख आवश्यक असते.

3. Primary Key म्हणजे काय?#

आधी simple meaning समजून घेऊ.

Primary Key म्हणजे table मधील प्रत्येक row uniquely identify करण्यासाठी वापरला जाणारा key.

उदाहरण:

student_id = 101

हा value त्या specific student ची ओळख बनू शकतो.

जर student_id Primary Key असेल, तर database दोन महत्त्वाच्या गोष्टी enforce करते:

1. Primary Key value duplicate असू शकत नाही.
2. Primary Key value NULL असू शकत नाही.

म्हणजे database म्हणते:

"ओळख द्यायची असेल तर ती unique आणि available असली पाहिजे. 'मला माहिती नाही' असा ID चालणार नाही."

4. Definition#

इथे constraint म्हणजे database वर लावलेला rule.

म्हणजे आपण फक्त developer ला "duplicate ID टाकू नको" असे सांगत नाही.

Database स्वतः तो rule enforce करते.

5. Primary Key कसा काम करतो?#

समजा आपण नवीन student insert करत आहोत.

Database Primary Key संदर्भात साधारण असा विचार करते:

Flow सुरुवातीला नवीन row पासून सुरू होतो.

Database प्रथम पाहते की Primary Key value उपलब्ध आहे का.

Value NULL असेल तर row accept होत नाही.

Value उपलब्ध असेल तर पुढचा प्रश्न:

"ही value आधीच दुसऱ्या row कडे आहे का?"

जर हो, तर duplicate identity तयार होईल.

म्हणून row reject केला जातो.

Value unique असेल तर row accept होतो.

6. SQL मध्ये Primary Key तयार करणे#

आपल्याला students table तयार करायचा आहे.

प्रत्येक student साठी student_id ही unique identity असेल.

CREATE TABLE students (
    student_id INT PRIMARY KEY,
    name VARCHAR(100) NOT NULL,
    city VARCHAR(100)
);

इथे:

student_id INT PRIMARY KEY

याचा अर्थ:

• student_id हा integer column आहे
• हा column Primary Key म्हणून वापरला जाईल
• त्यातील values unique असल्या पाहिजेत
• त्यातील value NULL असू शकत नाही

आता काही data insert करूया.

INSERT INTO students (student_id, name, city)
VALUES (101, 'Amit Patil', 'Pune');

INSERT INTO students (student_id, name, city)
VALUES (102, 'Sneha Jadhav', 'Mumbai');

दोन्ही rows valid आहेत.

कारण:

101 != 102

दोन्ही students ची identity वेगळी आहे.

7. Duplicate Primary Key टाकल्यास काय होते?#

आता पुन्हा student_id = 101 insert करण्याचा प्रयत्न करू.

INSERT INTO students (student_id, name, city)
VALUES (101, 'Rahul Shinde', 'Nagpur');

पण 101 आधीच Amit Patil च्या row कडे आहे.

म्हणून database हा insert reject करेल.

Expected Result#

Primary Key violation किंवा duplicate key संबंधित error मिळेल.

Exact error message कोणता database वापरत आहोत त्यावर अवलंबून बदलू शकतो.

पण कारण तेच आहे:

student_id 101 already exists

Database च्या दृष्टीने situation अशी झाली:

"एका ID वर दोन students? मग 101 कोण? Amit की Rahul?"

Database अशा गोंधळाला परवानगी देत नाही.

8. Primary Key मध्ये NULL का चालत नाही?#

NULL म्हणजे साधारणपणे value unknown किंवा absent आहे.

समजा आपण हे करण्याचा प्रयत्न केला:

INSERT INTO students (student_id, name, city)
VALUES (NULL, 'Neha More', 'Pune');

Primary Key student_id आहे.

पण Neha ची identity काय?

तीच नाही.

जर database अशा rows allow करत राहिला तर:

आता प्रत्येक row uniquely identify करण्याचा Primary Key चा उद्देशच संपला.

म्हणून Primary Key NULL accept करत नाही.

पण Primary Key फक्त दोन rules ची बेरीज नाही.

तो table मधील row ची मुख्य identity म्हणून वापरला जातो.

9. Primary Key चे महत्त्वाचे Rules#

Rule 1: Primary Key values unique असल्या पाहिजेत#

हे:

101
102
103

valid असू शकते.

हे:

101
102
101

valid नाही.

कारण 101 repeat झाला आहे.

Rule 2: Primary Key NULL असू शकत नाही#

हे valid:

student_id = 101

हे Primary Key साठी valid नाही:

student_id = NULL

Row ची ओळखच नसणे Primary Key च्या उद्देशाच्या विरुद्ध आहे.

Rule 3: एका table ला एक Primary Key constraint असतो#

समजा table मध्ये columns आहेत:

student_id
email
phone

आपण दोन वेगवेगळ्या independent Primary Keys तयार करत नाही.

Table ला एक PRIMARY KEY constraint असतो.

आपल्या current examples मध्ये आपण simple single-column Primary Keys वापरत आहोत.

Rule 4: Primary Key शक्यतो stable असावा#

stable म्हणजे value वारंवार बदलणारी नसावी.

उदाहरणार्थ:

customer_id = 5001

हा ID customer चे नाव, phone किंवा email बदलले तरी तसाच राहू शकतो.

हे database design साठी सोपे असते.

समजा आपण email ला Primary Key केले:

rahul@gmail.com

आणि customer ने नंतर email बदलला:

rahul@company.com

आता आपण row ची मुख्य identity बदलत आहोत.

Technically काही systems मध्ये हे manage करता येते.

पण unnecessary complexity वाढू शकते.

म्हणून frequently changing values Primary Key म्हणून निवडताना काळजी घ्यावी.

"घाईचे काम शैतानाचे" म्हणतात. Database design मध्ये चुकीचा key पटकन निवडला तर नंतर त्याची किंमत migrations आणि updates मध्ये भरावी लागू शकते.

Rule 5: Primary Key practical आणि manageable असावा#

Primary Key theoretically unique असला तरी तो खूप मोठा, बदलणारा किंवा complex असेल तर काम अवघड होऊ शकते.

उदाहरणार्थ customer identify करण्यासाठी संपूर्ण अशी माहिती key म्हणून वापरणे:

name + city + phone + date_of_birth

हे unnecessarily complicated आहे.

Simple stable identifier अनेकदा सोपा ठरतो:

customer_id = 10025

10. Primary Key define करण्याची दुसरी syntax#

आपण आधी अशी syntax पाहिली:

CREATE TABLE students (
    student_id INT PRIMARY KEY,
    name VARCHAR(100) NOT NULL
);

Primary Key वेगळ्या table constraint स्वरूपातही लिहू शकतो:

CREATE TABLE students (
    student_id INT,
    name VARCHAR(100) NOT NULL,
    PRIMARY KEY (student_id)
);

दोन्ही examples मध्ये student_id Primary Key आहे.

Beginner म्हणून आत्ता एवढे लक्षात ठेवा:

student_id INT PRIMARY KEY

ही syntax single-column Primary Key साठी खूप सहज वाचता येते.

11. पण Primary Key साठी value कुठून आणायची?#

इथे दोन common approaches समजून घेणे महत्त्वाचे आहे:

• Natural Key
• Surrogate Key

दोन्हीचा उद्देश row identify करणे असू शकतो.

पण key कुठून येतो आणि त्याला business meaning आहे का यात फरक आहे.

12. Natural Key#

Natural Key म्हणजे business किंवा real-world data मध्ये आधीपासूनच अस्तित्वात असलेली unique value जी row identify करण्यासाठी वापरता येते.

उदाहरणार्थ countries table विचार करा:

इथे country_code ला स्वतःचा business meaning आहे.

IN म्हणजे India.

तो फक्त database ने random तयार केलेला number नाही.

अशी meaningful value Primary Key म्हणून वापरली तर तिला Natural Key म्हणता येते.

उदाहरण:

CREATE TABLE countries (
    country_code VARCHAR(2) PRIMARY KEY,
    country_name VARCHAR(100) NOT NULL
);

इथे:

IN
US
JP

या values unique identity देतात आणि domain मध्ये त्यांना अर्थही आहे.

Natural Key ची मुख्य कल्पना#

Natural Key:

• real-world किंवा business data मधून येतो
• स्वतःचा अर्थ असतो
• naturally unique असणे अपेक्षित असते
• sufficiently stable असेल तर Primary Key म्हणून चांगला candidate असू शकतो

पण प्रत्येक naturally unique दिसणारी value चांगली Primary Key असेलच असे नाही.

13. Email नेहमी चांगला Natural Primary Key आहे का?#

समजा:

email = rohan@gmail.com

Email unique असू शकतो.

म्हणून पहिल्या नजरेत वाटेल:

"मग हाच Primary Key करू."

पण विचार करा.

User email बदलू शकतो का?

हो.

Company email बंद होऊ शकतो का?

हो.

Business rules बदलू शकतात का?

हो.

म्हणून email natural business value असला तरी तो प्रत्येक system मध्ये ideal Primary Key असेलच असे नाही.

Database design मध्ये फक्त:

"ही value आज unique आहे का?"

इतकाच प्रश्न पुरेसा नाही.

आपण हेही विचारले पाहिजे:

"ही value उद्याही stable राहील का?"

हा छोटासा प्रश्न पुढचे मोठे headaches वाचवू शकतो.

14. Surrogate Key#

आता दुसरा प्रकार पाहू.

Surrogate Key म्हणजे row ला identity देण्यासाठी system/database साठी तयार केलेला artificial identifier.

त्याला सामान्यतः business meaning नसतो.

उदाहरण:

इथे:

customer_id = 1001

याचा business world मध्ये काही खास अर्थ नाही.

1001 पाहून आपल्याला customer Pune चा आहे, premium आहे किंवा male/female आहे असे काही समजत नाही.

तो फक्त identity आहे.

आणि अनेकदा तेच चांगले असते.

Database म्हणते:

"मला biography नको. मला unique ID द्या."

उदाहरण:

CREATE TABLE customers (
    customer_id INT PRIMARY KEY,
    name VARCHAR(100) NOT NULL,
    email VARCHAR(255)
);

इथे customer_id हा Surrogate Key म्हणून वापरला जाऊ शकतो.

15. Natural Key आणि Surrogate Key मधला फरक#

हे पाहून Surrogate Key नेहमीच better आहे असा निष्कर्ष काढू नका.

दोन्ही approaches योग्य असू शकतात.

Decision data च्या nature वर अवलंबून असतो.

16. Natural की Surrogate — विचार कसा करायचा?#

Key निवडताना असा विचार उपयोगी ठरतो:

पहिल्या step मध्ये आपल्याला stable row identity हवी आहे.

जर useful unique business valueच नसेल, तर Surrogate Key practical ठरतो.

Unique value असेल तरी पुढचा प्रश्न विचारायचा:

ती stable आहे का?

ती सतत बदलत असेल, खूप मोठी असेल किंवा business rules वर जास्त अवलंबून असेल, तर Surrogate Key सोपा ठरू शकतो.

पण value naturally unique, stable आणि manageable असेल तर Natural Key योग्य पर्याय असू शकतो.

17. काही Practical Primary Key Examples#

Students#

CREATE TABLE students (
    student_id INT PRIMARY KEY,
    student_name VARCHAR(100) NOT NULL
);

student_id प्रत्येक student ला स्वतंत्र identity देतो.

Products#

CREATE TABLE products (
    product_id INT PRIMARY KEY,
    product_name VARCHAR(150) NOT NULL,
    price DECIMAL(10, 2)
);

दोन products चे नाव सारखे असण्याची शक्यता असू शकते.

पण product_id unique ठेवता येतो.

Customers#

CREATE TABLE customers (
    customer_id INT PRIMARY KEY,
    customer_name VARCHAR(100) NOT NULL,
    email VARCHAR(255)
);

Customer ने नाव किंवा email बदलले तरी customer_id stable ठेवता येतो.

Countries#

CREATE TABLE countries (
    country_code VARCHAR(2) PRIMARY KEY,
    country_name VARCHAR(100) NOT NULL
);

इथे country_code ही meaningful Natural Key value आहे.

18. Primary Key फक्त id नावाचाच असावा का?#

नाही.

Column चे नाव काहीही meaningful असू शकते:

student_id
employee_id
product_id
order_id
customer_id
country_code

PRIMARY KEY हा database rule आहे.

Column चे नाव id असणे ही requirement नाही.

उदाहरण:

CREATE TABLE employees (
    employee_number INT PRIMARY KEY,
    employee_name VARCHAR(100) NOT NULL
);

इथे employee_number Primary Key असू शकतो.

19. Primary Key number असलाच पाहिजे का?#

नाही.

Primary Key हा integer असायलाच हवा असा rule नाही.

उदाहरण:

CREATE TABLE countries (
    country_code VARCHAR(2) PRIMARY KEY,
    country_name VARCHAR(100) NOT NULL
);

इथे Primary Key text-based आहे.

महत्त्वाचे काय?

तो selected key table design साठी योग्य असला पाहिजे आणि Primary Key rules satisfy केले पाहिजेत.

Integer surrogate IDs common आहेत.

पण Primary Key concept त्यापेक्षा मोठा आहे.

20. Auto-generated ID आणि Primary Key एकच गोष्ट आहे का?#

नाही.

ही beginner मध्ये खूप common confusion आहे.

काही databases IDs automatically generate करण्याची सुविधा देतात.

पण:

ID generation आणि Primary Key constraint या दोन वेगळ्या कल्पना आहेत.

Primary Key चा मुख्य प्रश्न:

"ही row uniquely identify होते का?"

Automatic number generation चा प्रश्न:

"नवीन ID value तयार कोण करणार?"

दोन्ही एकत्र वापरले जातात म्हणून ते एकच concept वाटू शकतात.

पण तसे नाही.

21. चुकीचा Primary Key निवडल्यास काय problem होऊ शकते?#

समजा customer table मध्ये आपण customer_name Primary Key करण्याचा विचार केला.

पहिला customer:

Amit Patil

दुसरा customer:

Amit Patil

आता duplicate.

म्हणून customer_name reliable identity नाही.

आता phone number वापरूया असे वाटले.

पण customer phone number बदलू शकतो.

Email वापरूया?

तोही बदलू शकतो.

म्हणून project मध्ये key निवडताना फक्त current sample data पाहून निर्णय घेऊ नये.

आज आपल्या test database मध्ये फक्त एक Amit आहे म्हणून नाव unique आहे असे समजू नका.

Production मध्ये दुसरा Amit दार ठोठावून म्हणेल:

"माझी entry कुठे करणार?"

Database design मध्ये sample data आणि business reality वेगळी असू शकते.

22. Good Primary Key निवडताना विचारायचे प्रश्न#

Primary Key candidate पाहताना स्वतःला हे प्रश्न विचारा:

• ही value प्रत्येक row साठी unique आहे का?
• ही value NULL होऊ शकते का?
• ही value वारंवार बदलते का?
• business rule बदलल्यास ही value बदलू शकते का?
• key unnecessarily मोठा किंवा complicated आहे का?
• row ची identity म्हणून ही value दीर्घकाळ reliable राहील का?

प्रत्येक प्रश्नाचे उत्तर "perfect" असायलाच हवे असे नाही.

Database design मध्ये context महत्त्वाचा असतो.

पण हे प्रश्न चुकीचे decisions कमी करतात.

23. Common Beginner Mistakes#

Mistake 1: नाव unique असेल असे गृहीत धरणे#

employee_name = Rahul Patil

हा row identifier म्हणून reliable नाही.

लोकांची नावे repeat होतात.

Mistake 2: Primary Key मध्ये duplicate values insert करणे#

101
102
101

Primary Key duplicate value reject करेल.

Mistake 3: NULL Primary Key चालेल असे समजणे#

Primary Key ला row identify करायचा आहे.

NULL identity हा contradiction आहे.

Mistake 4: प्रत्येक unique दिसणारी business value Primary Key करणे#

Email किंवा phone आज unique वाटू शकतात.

पण ते बदलू शकतात.

Uniqueness सोबत stability देखील विचारात घ्या.

Mistake 5: Surrogate Key ला business meaning देणे#

उदाहरणार्थ:

customer_id = 2026PUNEVIP1001

या एका ID मध्ये year, city, customer type आणि sequence कोंबणे आकर्षक वाटू शकते.

पण business detail बदलली तर ID awkward होऊ शकतो.

अति तिथे माती.

Simple identifier अनेकदा maintain करायला सोपा असतो.

24. छोटा Checkpoint#

समजा table आहे:

employee_name वरून row reliably identify करता येईल का?

नाही.

कारण Amit repeat झाला आहे.

employee_id वरून?

हो.

कारण:

501
502
503

प्रत्येक value वेगळी आहे.

हेच Primary Key च्या गरजेचे core आहे.

25. Hands-On Practice#

Practice 1#

Requirement

books नावाचा table तयार करा.

त्यात:

• book_id — integer Primary Key
• title — maximum 200 characters आणि required
• price — decimal value

Your Task

योग्य CREATE TABLE query लिहा.

CREATE TABLE books (
    book_id INT PRIMARY KEY,
    title VARCHAR(200) NOT NULL,
    price DECIMAL(10, 2)
);

Practice 2#

Requirement

हा data पाहा:

Your Task

Primary Key म्हणून customer_id वापरला असेल तर कोणती row problem निर्माण करेल आणि का ते सांगा.

customer_id = 1001

Practice 3#

Requirement

एका application मध्ये user email बदलू शकतो.

Developer म्हणतो:

"Email unique आहे, म्हणून email ला Primary Key करू."

Your Task

या design मधील मुख्य risk ओळखा.

26. Interview Preparation#

27. या Chapter मधून काय लक्षात ठेवायचे?#

• प्रत्येक table row ला reliable identity असणे महत्त्वाचे आहे.
• PRIMARY KEY प्रत्येक row uniquely identify करतो.
• Primary Key duplicate values allow करत नाही.
• Primary Key NULL allow करत नाही.
• एका table ला एक Primary Key constraint असतो.
• Primary Key शक्यतो stable आणि manageable असावा.
• Natural Key existing meaningful business value मधून येतो.
• Surrogate Key system-oriented artificial identifier असतो.
• प्रत्येक naturally unique value चांगली Primary Key असेलच असे नाही.
• key निवडताना uniqueness सोबत stability देखील विचारात घ्या.
• student_id, customer_id, product_id यांसारखे identifiers practical Primary Keys म्हणून खूप common आहेत.