Ravindra BagaleCourses & study guides English

SQL Database Design आणि Foreign Keys, उदाहरणांसह

CREATE TABLE येणं आणि कोणते tables बनवायचे हे कळणं, या दोन वेगळ्या गोष्टी आहेत. या chapter मध्ये आपण सगळे वापरतात अशा दोन apps, Instagram Reels आणि Flipkart, यांच्या मागचा database design करू, काय column होतं आणि कशाला वेगळा table लागतो ते ठरवू, आणि मग foreign key ने tables सुरक्षितपणे जोडू, म्हणजे कोणतीही order किंवा like अस्तित्वात नसलेल्या user कडे बोट दाखवू शकणार नाही.

या class मध्ये काय शिकणार

  • CREATE TABLE मध्येच keys लावणं: inline UNIQUE विरुद्ध comma नंतर table-level UNIQUE(email)
  • Duplicate email वर ERROR 1062, आणि पुढचा id एक number का सोडतो
  • Database design म्हणजे काय: किती tables, आणि कोणता column कुठे
  • Reels table मधले like आणि comment counters का fail होतात, आणि COUNT(*) सह likes table
  • नियम: प्रत्येक row ला अनेक values म्हणजे वेगळा table
  • User चा प्रवास चालून tables शोधणं (Flipkart), आणि actions columns का नाहीत
  • Foreign keys: orphan rows, parent आणि child, FOREIGN KEY ... REFERENCES, आणि DESC मधला MUL
  • Parent नसलेल्या child साठी ERROR 1452, children असलेल्या parent साठी ERROR 1451
  • is_active column ने soft delete

1. Practice data

का: खालच्या प्रत्येक command चा result दिलेला आहे. तुम्ही त्याच रिकाम्या database ने सुरुवात केली, तर तुम्हाला तीच उत्तरं मिळतील आणि स्वतः तपासता येईल.

कसं:

  1. mysql -u root -p ने login करा.
  2. नवीन instagram database ने सुरुवात करा. आधीच्या SQL chapter मधला असेल, तर हे तो काढून टाकतं:

    DROP DATABASE IF EXISTS instagram;
    CREATE DATABASE instagram;
    USE instagram;
    
  3. या वेळी आपण table बनवून नंतर दुरुस्त करणार नाही. Keys लगेच लागतात, पुढच्या section मध्ये.

2. Table बनवतानाच keys लावा

का: मागच्या SQL chapter मध्ये आपण keys नंतर ALTER TABLE ने लावल्या. ते चालतं, पण आधीच duplicates आले असतील तर ALTER TABLE fail होतो आणि आधी data साफ करावा लागतो. खऱ्या projects मध्ये पहिली row टाकण्याआधीच keys ठरलेल्या असतात.

Classroom line

Usually we don't create the table first and add the primary key later.

काय: CREATE TABLE मध्ये key दोन ठिकाणी लिहिता येते:

  1. Inline, column वरच: email VARCHAR(50) UNIQUE.
  2. Table level, सगळ्या columns नंतर वेगळा item म्हणून: UNIQUE(email).
  3. दोन्हीने अगदी तोच table बनतो. दोन्ही प्रकारे DESC email वर UNI दाखवतो.
  4. Table-level प्रकार list मधला अजून एक item आहे, म्हणून प्रत्येक column सारखा त्याच्या आधी comma लागतो.

Classroom line

Declare all the columns first, then declare the unique key at the end with UNIQUE.

कसं:

  1. Table-level प्रकाराने users बनवा:

    CREATE TABLE users (
      id INT PRIMARY KEY AUTO_INCREMENT,
      name VARCHAR(20),
      email VARCHAR(50),
      UNIQUE(email)
    );
    
  2. DESC users; id ला auto_increment सह PRI, आणि email ला UNI दाखवतो.

  3. Inline प्रकार email VARCHAR(50) UNIQUE असा असेल, शेवटची ओळ नसेल. तो आत्ता चालवू नका; users आधीच आहे.
  4. UNIQUE(email) च्या आधीचा comma सोडला तर MariaDB ERROR 1064 (42000): You have an error in your SQL syntax देऊन थांबतो, आणि (email) कडे बोट दाखवतो.
  5. नियम एकापेक्षा जास्त columns वर असेल, किंवा सगळे नियम शेवटी एकत्र ठेवायला आवडत असतील, तर table-level प्रकार वापरा. नाहीतर inline लहान आहे.
MariaDB terminal: create table users(id int primary key auto_increment, name varchar(20), email varchar(50), unique(email)); Query OK, 0 rows affected. desc users; lists id int(11) Null NO Key PRI Extra auto_increment, name varchar(20), email varchar(50) Key UNI.

Whiteboard: CREATE TABLE users, ज्यात UNIQUE(email) comma नंतर शेवटचा item म्हणून लिहिला आहे. DESC id वर auto_increment सह PRI आणि email वर UNI दाखवतो.

CREATE TABLE मध्ये email UNIQUEकरण्याचे दोन मार्ग Inline: column वरच UNIQUE शब्द CREATE TABLE users ( id INT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(20), email VARCHAR(50) UNIQUE); Table level: शेवटी वेगळी ओळ CREATE TABLE users ( id INT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(20), email VARCHAR(50), UNIQUE(email)); शेवटच्या column नंतरचा comma आवश्यक आहे. तो नसेल तर: ERROR 1064 near (email)). दोन्हीने तोच table बनतो: FieldTypeKeyidint(11)PRInamevarchar(20)emailvarchar(50)UNI INSERT ... ('amit', 'amit@example.com'); ERROR 1062: Duplicate entry 'amit@example.com' for key 'email' Keys table बनवतानाच लावा. नंतर लावताना आधीचduplicates आले असतील तर fail होतं.

Figure 1. CREATE TABLE मध्ये email UNIQUE करण्याचे दोन मार्ग: column वरच inline, किंवा comma नंतर वेगळी ओळ UNIQUE(email). दोन्हीने तोच table बनतो; duplicate email ERROR 1062 देतो.

3. UNIQUE चं काम: ERROR 1062 आणि सुटलेला id

का: एक email एकाच account चा असला पाहिजे. Login, password reset आणि "हा email आधीच registered आहे" हे सगळं त्यावर अवलंबून आहे.

कसं:

  1. एक user टाका. List मध्ये id नाही, म्हणून AUTO_INCREMENT तो निवडतो:

    INSERT INTO users (name, email) VALUES ('amit', 'amit@example.com');
    
  2. Query OK, 1 row affected. amit ला id 1 मिळतो.

  3. तोच email परत टाकून बघा:

    INSERT INTO users (name, email) VALUES ('amit', 'amit@example.com');
    
  4. MariaDB नाकारतो: ERROR 1062 (23000): Duplicate entry 'amit@example.com' for key 'email'. Key ला column चंच नाव मिळतं.

  5. अजून दोन users टाका:

    INSERT INTO users (name, email) VALUES ('neha', 'neha@example.com');
    INSERT INTO users (name, email) VALUES ('rahul', 'rahul@example.com');
    
  6. SELECT * FROM users; ids 1, 3, 4 दाखवतो. Fail झालेल्या insert ने id 2 वापरला, मागच्या SQL chapter मध्ये AUTO_INCREMENT gaps मध्ये बघितलं तसं.

MariaDB terminal: insert into users(name,email) values('ravi','r@b.com'); Query OK. select * from users; shows 1, ravi, r@b.com. The same insert again fails: ERROR 1062 (23000): Duplicate entry 'r@b.com' for key 'email'. insert with 'r@c.com' works. select * from users; shows ids 1 and 3.

Whiteboard: तोच email दुसऱ्यांदा टाकणारा insert key 'email' साठी ERROR 1062 ने fail होतो. पुढच्या user ला id 3 मिळतो, कारण fail झालेल्या insert ने id 2 वापरला.

Classroom line

Do it, and try it without looking; see how much you can do on your own.

4. Database design म्हणजे काय

का: App त्याच्या tables इतकंच चांगलं असतं. वाईट design आठवडाभर चालतो आणि मग "ही reel कोणी like केली?" सारख्या साध्या प्रश्नांची उत्तरं देऊ शकत नाही.

काय: database design म्हणजे हे ठरवणं:

  1. App ला किती tables लागतात.
  2. कोणते columns कोणत्या table मध्ये जातात.
  3. Tables एकमेकांशी कसे जोडलेले आहेत.

Classroom line

Deciding how many tables there should be and which column goes in which table is called database design.

कसं: Design पहिल्या CREATE TABLE च्या आधी होतो, सहसा कागदावर:

  1. App प्रत्येक screen वर काय दाखवतं ते लिहा.
  2. Data "गोष्टीं"नुसार गटात टाका: व्यक्ती, reel, like, order.
  3. प्रत्येक प्रकारची गोष्ट table होते; तिच्याबद्दलची प्रत्येक एकटी माहिती column होते.
  4. प्रत्येक table साठी एक sample row लिहून बघा आणि प्रत्येक cell तपासा (section 7).

Classroom line

Only when you can separate all this data will you get a proper database design.

5. समजा आपण Instagram Reels बनवतोय

का: Reel ची screen सोपी दिसते: profile photo, username, video, caption, आणि likes व comments चे counts. यातलं प्रत्येक काहीतरी कुठल्यातरी table मधून यायला हवं.

Classroom line

Every reel that gets uploaded must be stored as a record in the database.

काय: बहुतेक लोकांना पहिली कल्पना सुचते ती म्हणजे सगळं काही असलेला एक reels table:

  1. id, user_id (कोणी upload केली), caption, video_url.
  2. आणि counters: likes, comments, shares, प्रत्येक साधा number.

Classroom line

Let's make the mistakes and see.

कसं: खऱ्या प्रश्नांनी design तपासा.

  1. Reel 102 वर likes = 3. कोणी like दाबलं; app ते 4 करतं. इथपर्यंत ठीक.
  2. कोणी like केलं? Counter सांगू शकत नाही. तो फक्त number आहे.
  3. कधी like केलं? तेही store नाही.
  4. एकाच व्यक्तीने दोनदा like केलं का? तपासायला मार्गच नाही.
  5. कोणी unlike दाबलं. कोणाचं like काढायचं?
  6. Comments ला हीच अडचण, आणि त्याहून वाईट: comment ला text पण असतो.

Classroom line

If someone has liked it, then who liked it? That should be visible too.

Like counter किती ते सांगतो, कोणी आणि कधी कधीचनाही reels, counters सह (कमकुवत design) id user_id caption likes comments 101 1 sunset 0 0 102 4 chai time 3 1 Reel 102 वर 3 likes दिसतात. App number दाखवू शकतं, आणि त्याला एवढंच माहीत आहे. 102 4 chai time 4 1 कोणी like दाबलं: 3 चे 4. कोणी like केलं? Store नाही. कधी? Store नाही. तीच व्यक्ती दोनदा? तपासता येत नाही. Unlike: कोणाचं like काढायचं? likes: प्रत्येक like ची एक row id user_id reel_id liked_at 1 1 102 ... 15:30:04 2 3 102 ... 15:31:40 3 4 102 ... 18:02:15 4 1 105 ... 09:10:33 SELECT COUNT(*) FROM likes WHERE reel_id = 102; --3 Count मोजला जातो, store केला जात नाही. कोणी आणि कधी प्रत्येक rowमध्ये आहे. Unlike = ती एक row delete. reels table मध्ये फक्त प्रत्येक reel चं एकदाच असणारं: कोणीupload केली, caption, video link.

Figure 2. Animation: reels table मधला likes counter फक्त किती ते सांगतो; कोणी किंवा कधी सांगू शकत नाही, unlike पण सांभाळू शकत नाही. प्रत्येक like ची एक row असलेला likes table या सगळ्यांची उत्तरं देतो, आणि COUNT(*) number देतो.

6. likes table, आणि COUNT(*)

का: Counter "कोणी" किंवा "कधी" सांगू शकला नाही. प्रत्येक like ही स्वतंत्र घटना आहे, म्हणून प्रत्येक like ला स्वतःची row.

Classroom line

Now how will you find out who liked it?

काय: likes table ज्यात:

  1. id: like चा स्वतःचा number.
  2. user_id: कोणी like केलं.
  3. reel_id: कोणती reel.
  4. liked_at: कधी. DEFAULT CURRENT_TIMESTAMP आत्ताची तारीख आणि वेळ आपोआप भरतो.

Likes चा number कुठेच store केला जात नाही. लागेल तेव्हा rows वरून तो मोजला जातो.

कसं:

  1. Table बनवा:

    CREATE TABLE likes (id INT PRIMARY KEY AUTO_INCREMENT, user_id INT, reel_id INT,
      liked_at DATETIME DEFAULT CURRENT_TIMESTAMP);
    
  2. तीन users reel 102 like करतात, आणि amit reel 105 पण like करतो:

    INSERT INTO likes (user_id, reel_id) VALUES (1, 102), (3, 102), (4, 102), (1, 105);
    
  3. Query OK, 4 rows affected. प्रत्येक row ला liked_at मध्ये आजची तारीख आणि वेळ मिळाली.

  4. Reel 102 चे likes likes table मधून मोजा:

    SELECT COUNT(*) FROM likes WHERE reel_id = 102;
    
  5. उत्तर 3.

  6. Count वर tap करा, आणि app कोणी like केलं त्यांची list दाखवतं:

    SELECT user_id, liked_at FROM likes WHERE reel_id = 102;
    
  7. Users 1, 3 आणि 4 मिळतात, प्रत्येकाची वेळ सोबत. मग app users मधून त्यांची नावं आणि profile photos दाखवतं.

  8. Unlike आता सोपं: ती एक row delete करा, उदा. DELETE FROM likes WHERE user_id = 4 AND reel_id = 102;
  9. reels table मध्ये फक्त reel कडे एकदाच असणारं राहतं: कोणी upload केली, caption, video link.

7. नियम: प्रत्येक row ला अनेक values, वेगळा table

का: कोणत्याही app च्या कोणत्याही column ला लावता येईल अशी झटपट कसोटी हवी.

Classroom line

If a column is going to hold more than one value, that data becomes a separate table.

काय:

  1. प्रत्येक row ला एक value: column म्हणून ठेवा. Reel ला एक caption, एक video link, एक uploader.
  2. प्रत्येक row ला अनेक values, किंवा वाढत जाणारी list: वेगळा table द्या, प्रत्येक value ची एक row. Reel ला अनेक likes, अनेक comments, अनेक tags.
  3. '1,3,4' सारखी list एका cell मध्ये कधीच भरू नका. त्यातली एक नीट मोजता, शोधता किंवा काढता येत नाही.

कसं: paper test.

  1. Table चे columns कागदावर लिहा.
  2. खऱ्यासारख्या values ने एक sample row भरा.
  3. प्रत्येक cell बघा. त्यात comma ने वेगळी केलेली list लागत असेल, तर त्या data ला वेगळा table हवा.
  4. उदाहरण: caption = 'chai time' एक value; liked by = 1, 3, 4, ... अनेक, म्हणून likes हा table.
  5. उदाहरण: tags = chai, rain, pune अनेक, म्हणून tags reel_tags table मध्ये: प्रत्येक reel आणि tag ची एक row.
Paper test: एक sample row लिहा आणि प्रत्येक cellबघा Reel 102 साठी sample caption 'chai time' एक value reels मध्ये column video_url '.../102.mp4' एक value reels मध्ये column uploaded by 4 एक value column user_id liked by 1, 3, 4, ... अनेक, वाढत जातात वेगळा table: likes comments 'nice!', 'wow', ... अनेक, वाढत जातात वेगळा table: comments tags chai, rain, pune अनेक वेगळा table: reel_tags प्रत्येक row ला एक value: column. प्रत्येक row ला अनेकvalues: वेगळा table, प्रत्येक value ची एक row. 1,3,4 सारखी list एका cell मध्ये कधीच भरू नका: त्यातली एक नीट मोजता, शोधताकिंवा delete करता येत नाही.

Figure 3. Paper test: एक sample row लिहा आणि प्रत्येक cell तपासा. प्रत्येक row ला एक value column राहते; प्रत्येक row ला अनेक values वेगळा table होतात, प्रत्येक value ची एक row.

8. समजा आपण Flipkart बनवतोय: user चा प्रवास चाला

का: Shopping app मध्ये डझनभर tables असतात. अंदाजाने शोधले तर काही सुटतात; customer सारखं app मधून चाललं तर ते क्रमाने सापडतात.

Classroom line

Whenever you think something through, think step by step.

कसं: एका customer च्या मागे चला आणि प्रत्येक step ला काय store करायचं ते लिहा.

  1. Register आणि profile: users table, प्रत्येक व्यक्तीची एक row.
  2. Delivery address: addresses table. एका user चे अनेक addresses असू शकतात: तुम्ही Pune मध्ये राहता पण दुसऱ्या शहरातल्या आई-वडिलांना gift पाठवता. एका user ला अनेक values म्हणजे वेगळा table.
  3. Browse: categories (mobiles, shoes, books) आणि products.
  4. Cart आणि wishlist: cart (user, product, quantity) आणि wishlist (user, product).
  5. Pay: orders (कोणी घेतलं, किती रुपये) आणि payments (एका order साठी एक किंवा जास्त).
  6. Order नंतर: order_tracking (प्रत्येक status बदलाची row), returns, ratings.
  7. पडद्यामागे: sellers, offers, support_tickets.

Table किंवा column नसलेलं: search, filter, sort, "add to cart", "buy now". या actions आहेत. Action एकतर rows वाचतो (WHERE आणि ORDER BY सह SELECT) किंवा row जोडतो (add to cart म्हणजे cart मध्ये INSERT).

Classroom line

What is add to cart? It is a functionality, an action.

समजा आपण Flipkart बनवतोय: user चा प्रवास चालूनtables शोधा Register → Profile users प्रत्येक व्यक्तीची एक row addresses एक user, अनेक addresses Browse → Cart categories mobiles, shoes, books products विकायच्या प्रत्येक item ची row cart user + product + quantity wishlist user + product Address → Pay → Track orders कोणी घेतलं, किती रुपये payments एका order साठी एक किंवा जास्त order_tracking प्रत्येक status बदलाची row ratings user + product + stars Actions म्हणजे tables किंवा columns नाहीत: search, filter,sort, add to cart, buy now. Action rows वाचतो (SELECT) किंवा row जोडतो (add to cart = cartमध्ये INSERT).

Figure 4. Animation: Flipkart चा user प्रवास (register, profile, browse, cart, address, pay, track) चालल्यावर tables एकेक करून सापडतात. Search, filter आणि add to cart सारख्या actions म्हणजे tables किंवा columns नाहीत.

9. products design: column की वेगळा table?

का: products मध्ये लोक खूप काही भरतात. Section 7 चा नियम प्रत्येक कल्पनेला लावा.

काय:

  1. Columns, प्रत्येक product ची एक value: id, name, brand, price DECIMAL(10,2), description, return_days.
  2. Size म्हणजे तीन numbers, म्हणून तीन columns: length_cm, width_cm, depth_cm. मग प्रत्येकावर filter लावता येतो.
  3. Category: प्रत्येक product row मध्ये "Mobiles" टाइप करू नका. categories table (id, name) ठेवा आणि products मध्ये फक्त number ठेवा: category_id. मग spelling दुरुस्ती एकाच row मध्ये होते.
  4. वेगळे tables, कारण values अनेक आहेत किंवा सतत बदलतात:
    1. product_photos: एका product चे अनेक photos.
    2. ratings: एका product ला अनेक users rating देतात.
    3. stock: प्रत्येक sale ला बदलतो.
    4. price_history: जुन्या किंमती त्यांच्या तारखांसह.
    5. sellers: एक product अनेक sellers विकू शकतात.
    6. offers: येतात आणि जातात.
  5. Column अजिबात नाही: "good quality" हे मत आहे; ते ratings मध्ये राहतं. "Add to cart" हा action आहे.
products: काय column राहतं, कशाला वेगळाtable Columns: प्रत्येक product ची एक value id INT PRIMARY KEY name VARCHAR brand VARCHAR price DECIMAL(10,2) description TEXT category_id INT length_cm, width_cm, depth_cm DECIMAL return_days INT वेगळे tables: अनेक values, किंवा सतत बदलतं product_photos एका product चे अनेक photos ratings अनेक users rating देतात stock प्रत्येक sale ला बदलतो price_history जुन्या किंमती तारखेसह sellers एका product चे अनेक sellers offers येतात आणि जातात categories (id, name) प्रत्येक category ची row: mobiles, shoes Columns नाहीत: good quality (मत आहे; ratingsमध्ये येतं) आणि add to cart (action). Category एकदाच categories मध्ये लिहा; products मध्येफक्त त्याचा number, category_id.

Figure 5. products: एकटी माहिती columns राहते, categories table कडे बोट दाखवणारा category_id सुद्धा; photos, ratings, stock, price history, sellers आणि offers यांना वेगळे tables.

10. Foreign keys का: orphan rows

का: आता tables एकमेकांचे ids ठेवतात: likes.user_id, orders.user_id, products.category_id. ते ids खरे आहेत का हे आत्तापर्यंत कोणीच तपासत नाही.

काय बिघडू शकतं:

  1. users मध्ये ids 1, 3 आणि 4 आहेत.
  2. reels ची एक row सांगते reel 103 user 30 ने upload केली. User 30 नाहीच. App कोणाचा profile photo दाखवणार? ही orphan row आहे: parent नसलेला child.
  3. orders ची एक row सांगते order 2, Rs 1,00,000, user 10 ने दिली, जो अस्तित्वातच नाही. Audit मध्ये ते पैसे कोणी भरले हे कोणीच सांगू शकत नाही.
  4. अस्तित्वात नसलेल्या users चे likes प्रत्येक like count चुकवतात.

Classroom line

Only the users you actually have will place orders; a user who doesn't exist can't place an order.

काय: foreign key हा एका table च्या column वरचा नियम आहे: "इथली प्रत्येक value त्या दुसऱ्या table च्या त्या column मध्ये असलीच पाहिजे". Database प्रत्येक insert, update आणि delete वर तो तपासतो.

Foreign key शिवाय, row अस्तित्वात नसलेल्याव्यक्तीकडे बोट दाखवू शकते users id name 1 amit 3 neha 4 rahul reels id user_id caption 101 1 sunset 102 4 chai time 103 30 rain 30 ? no such user User 30 ची reel 103 User 30 नाही. कोणाचा profile photo दाखवायचा? Orphan (अनाथ) row. orders id user_id amount 1 4 499.00 2 10 100000.00 10 ? no such user Order 2: Rs 1,00,000 User 10 ने भरले, जो अस्तित्वातच नाही. Audit मध्ये कोणीच सांगू शकतनाही कोणी. Foreign key मुळे database अशा rows नाकारतो: user_id हा usersमध्ये असलाच पाहिजे.

Figure 6. Foreign key शिवाय reel 103 user 30 कडे आणि Rs 1,00,000 ची order 2 user 10 कडे बोट दाखवते, आणि दोन्ही users अस्तित्वात नाहीत: orphan rows.

11. Parent आणि child

का: प्रत्येक foreign key ला दोन बाजू असतात, आणि या chapter मधला प्रत्येक error message त्यातली एक सांगतो. Parent table कोणता हे माहीत असलं की कोणती row दुरुस्त करायची ते कळतं.

काय:

  1. ज्या table कडे बोट दाखवलं जातं तो parent: users.
  2. बोट दाखवणारा column ज्या table मध्ये आहे तो child: orders, त्याच्या user_id column सह.
  3. एका parent row चे अनेक children असू शकतात: एक user, अनेक orders.

नियम:

  1. Child च्या foreign key column मधली value parent column मध्ये असलीच पाहिजे. Column NOT NULL केला नसेल तर NULL चालतो.
  2. Parent column PRIMARY KEY किंवा UNIQUE column असला पाहिजे. सहसा तो parent चा primary key असतो, users(id). users(email) सारखा unique column पण चालतो.
  3. दोन्ही columns चा type सारखा हवा: INT ला INT.
  4. आधी parent table बनवा. Child त्याला नावाने refer करतो.

कसं: नियम मोडला तर काय होतं ते बघा. ही दोन उदाहरणं फक्त वाचा; ती मुद्दाम fail होतात.

  1. Key नसलेला parent column:

    CREATE TABLE bad (id INT PRIMARY KEY, uname VARCHAR(20), FOREIGN KEY (uname) REFERENCES users(name));
    
  2. तो fail होतो: ERROR 1005 (HY000): Can't create table `instagram`.`bad` (errno: 150 "Foreign key constraint is incorrectly formed"). name ला key नाही, म्हणून तो parent column होऊ शकत नाही.

  3. Types वेगळे असतील (INT कडे बोट दाखवणारा VARCHAR), किंवा parent table अजून बनलाच नसेल, तेव्हा पण हाच ERROR 1005 येतो.
Parent आणि child: foreign key child कडून parentकडे बोट दाखवतो Parent: users id (PK) name 1 amit 3 neha 4 rahul user_id → id Child: orders id user_id (FK) amount 1 4 499.00 3 1 1299.50 CREATE TABLE orders (id INT PRIMARY KEY AUTO_INCREMENT, user_id INT, product_id INT, amount DECIMAL(10,2), FOREIGN KEY (user_id) REFERENCES users(id)); नियम 1. Child मधली value parent मध्ये असलीच पाहिजे. Column NOT NULLनसेल तर NULL चालतो. 2. Parent चा column PRIMARY KEY किंवा UNIQUE असला पाहिजे. 3. दोन्ही columns चा type सारखा हवा: INT ला INT. 4. आधी parent table बनवा. मग DESC orders user_id वर MUL दाखवतो.

Figure 7. users हा parent आणि orders हा child: प्रत्येक orders.user_id एका users.id कडे बोट दाखवतो. Parent column त्याच type चा PRIMARY KEY किंवा UNIQUE column असला पाहिजे, आणि parent table आधी बनतो.

12. FOREIGN KEY सह CREATE TABLE

का: Foreign key CREATE TABLE मध्येच लिहिला की पहिल्या row पासूनच नियम database मध्ये असतो, म्हणून एकही orphan row आत घुसू शकत नाही.

कसं:

  1. Child table बनवा. Foreign key UNIQUE(email) सारखी table level ला, comma नंतर लिहिली आहे:

    CREATE TABLE orders (
      id INT PRIMARY KEY AUTO_INCREMENT,
      user_id INT,
      product_id INT,
      amount DECIMAL(10,2),
      FOREIGN KEY (user_id) REFERENCES users(id)
    );
    
  2. असं वाचा: "या table मधला user_id, users मधल्या id ला refer करतो".

  3. amount DECIMAL(10,2) पैसे अचूक ठेवतो: जास्तीत जास्त 10 अंक, त्यातले 2 दशांश चिन्हानंतर, उदा. 1299.50.
  4. DESC orders; user_id च्या Key column मध्ये MUL दाखवतो.
  5. MUL म्हणजे "multiple": column वर index आहे, आणि तीच value परत येऊ शकते. MariaDB प्रत्येक foreign key साठी हा index बनवतो. हे बरोबरच आहे: एका user च्या अनेक orders असू शकतात.
  6. तुलना: PRI म्हणजे primary key, UNI म्हणजे unique, MUL मध्ये repeat चालतात.
MariaDB terminal: desc orders; lists id int(11) Null NO Key PRI Extra auto_increment, userid int(11) Null YES Key MUL, prodid int(11) Null YES. 3 rows in set.

Whiteboard: Foreign key सह बनवल्यानंतर DESC orders: id auto_increment सह PRI आहे, आणि foreign key column MUL दाखवतो.

13. ERROR 1452: child ला parent हवाच

का: Foreign key चा मुख्य उद्देश हाच: अस्तित्वात नसलेल्या user ची order नको.

कसं:

  1. rahul (id 4) ची order, जो अस्तित्वात आहे:

    INSERT INTO orders (user_id, product_id, amount) VALUES (4, 1001, 499.00);
    
  2. Query OK, 1 row affected. तिला id 1 मिळतो.

  3. User 30 ची Rs 1,00,000 ची order, जो अस्तित्वात नाही:

    INSERT INTO orders (user_id, product_id, amount) VALUES (30, 1001, 100000.00);
    
  4. MariaDB नाकारतो: ERROR 1452 (23000): Cannot add or update a child row: a foreign key constraint fails (`instagram`.`orders`, CONSTRAINT `orders_ibfk_1` FOREIGN KEY (`user_id`) REFERENCES `users` (`id`)).

  5. Message शेवटून वाचा: constraint orders_ibfk_1 सांगतो की user_id हा users.id शी जुळला पाहिजे, आणि 30 जुळत नाही.
  6. orders_ibfk_1 हे MariaDB ने foreign key ला दिलेलं नाव आहे, कारण आपण नाव दिलं नाही.
  7. amit (id 1) ची order:

    INSERT INTO orders (user_id, product_id, amount) VALUES (1, 1002, 1299.50);
    
  8. तिला id 3 मिळतो, 2 नाही. Fail झालेल्या insert ने id 2 वापरला, section 3 मधल्या duplicate email सारखाच.

  9. SELECT * FROM orders; order 1 (user 4, 499.00) आणि order 3 (user 1, 1299.50) दाखवतो.
MariaDB terminal: insert into orders(userid,prodid) values(3,1001); Query OK. select * from orders; shows id 1, userid 3, prodid 1001. insert into orders(userid,prodid) values(30,1001); fails: ERROR 1452 (23000): Cannot add or update a child row: a foreign key constraint fails (instgram.orders, CONSTRAINT orders_ibfk_1 FOREIGN KEY (userid) REFERENCES users (id)).

Whiteboard: अस्तित्वात असलेल्या user ची order चालते; अस्तित्वात नसलेल्या user 30 ची order ERROR 1452 Cannot add or update a child row ने fail होते.

14. ERROR 1451: आधी child delete करा

का: नियम दोन्ही बाजूंनी काम करतो. Children असलेला parent delete केला तर ते children orphan होतील, म्हणून database तेही नाकारतो.

कसं:

  1. Order 3 असलेल्या amit ला delete करून बघा:

    DELETE FROM users WHERE id = 1;
    
  2. MariaDB नाकारतो: ERROR 1451 (23000): Cannot delete or update a parent row: a foreign key constraint fails (`instagram`.`orders`, CONSTRAINT `orders_ibfk_1` FOREIGN KEY (`user_id`) REFERENCES `users` (`id`)).

  3. आधी child delete करा:

    DELETE FROM orders WHERE id = 3;
    
  4. आता parent जाऊ शकतो:

    DELETE FROM users WHERE id = 1;
    
  5. दोन्ही Query OK, 1 row affected देतात. SELECT * FROM users; neha आणि rahul दाखवतो.

  6. हेच संरक्षण parent id बदलण्यावर (UPDATE users SET id = 33 WHERE id = 4; ERROR 1451 देतो) आणि पूर्ण parent table drop करण्यावर पण आहे (orders refer करत असेपर्यंत DROP TABLE users; ERROR 1451 देतो).
  7. दोन्ही tables काढायचे असतील तर आधी child drop करा: DROP TABLE orders; मग DROP TABLE users;
MariaDB terminal: delete from users where id=1; fails: ERROR 1451 (23000): Cannot delete or update a parent row: a foreign key constraint fails (instgram.orders, CONSTRAINT orders_ibfk_1 FOREIGN KEY (userid) REFERENCES users (id)). delete from orders where id=3; Query OK, 1 row affected. delete from users where id=1; Query OK, 1 row affected.

Whiteboard: अजून order असलेल्या user चा delete ERROR 1451 ने fail होतो. आधी order delete केल्यावर user चा तोच delete चालतो.

Foreign key चं काम: चुकीचा child, मग parent deleteकरणं users 1 amit · 3 neha · 4 rahul INSERT INTO orders (user_id, product_id, amount) VALUES (4, 1001, 499.00); -- OK, id 1 VALUES (30, 1001, 100000.00); -- ERROR 1452 VALUES (1, 1002, 1299.50); -- OK, id 3 ERROR 1452 Cannot add or update a child row. User 30 नाही. Fail झालेल्या insertने id 2 वापरला. orders: 1 → user 4 · ✗2 → user 30 · 3 → user 1 DELETE FROM users WHERE id = 1; -- ERROR 1451: order 3 still points to user 1 ERROR 1451 Cannot delete or update a parent row. Order 3 अजून user 1 कडे बोटदाखवते. Child बोट दाखवत असेपर्यंत parent राहतो. DELETE FROM orders WHERE id = 3; -- OK: the child goesfirst DELETE FROM users WHERE id = 1; -- OK: no child pointsto user 1 now आधी child, मग parent आता दोन्ही deletes चालतात. किंवा user ठेवा आणि त्याला inactive करा:soft delete.

Figure 8. Animation: user 30 ची order ERROR 1452 ने fail होते आणि id 2 वापरते; order 3 बोट दाखवत असताना user 1 चा delete ERROR 1451 ने fail होतो; आधी order, मग user delete केल्यावर चालतं.

15. is_active ने soft delete

का: Customer account बंद करतो. Orders असेपर्यंत user चा delete अडवला जातो, आणि orders delete केल्या तर bills, tax records आणि returns नष्ट होतात. खरी apps अशा rows जवळजवळ कधीच delete करत नाहीत.

Classroom line

Even if a user deactivates their account, we won't have to remove that user.

काय: soft delete मध्ये row ठेवली जाते आणि flag column ने, सहसा is_active, inactive म्हणून mark केली जाते: active साठी 1, deactivate साठी 0. App फक्त active rows दाखवतं.

कसं:

  1. Flag जोडा. आधीचे सगळे users active ने सुरू होतात:

    ALTER TABLE users ADD COLUMN is_active TINYINT NOT NULL DEFAULT 1;
    
  2. rahul (id 4) त्याचं account बंद करतो:

    UPDATE users SET is_active = 0 WHERE id = 4;
    
  3. App फक्त active users दाखवतं:

    SELECT * FROM users WHERE is_active = 1;
    
  4. फक्त neha दिसते. rahul ची row अजून आहे, आणि त्याची order 1 पण: SELECT * FROM orders; ती अजून दाखवतो, खऱ्या user कडे बोट दाखवत.

  5. rahul परत आला? UPDATE users SET is_active = 1 WHERE id = 4; आणि सगळं पूर्वीसारखं.
  6. App मध्ये users ची list काढणाऱ्या प्रत्येक query ला WHERE is_active = 1 लावायला विसरू नका.
User सोडून गेला: row delete करायची, कीinactive करायची? Hard delete DELETE FROM users WHERE id = 4;-- ERROR 1451 while orders point to 4 User च्या orders असेपर्यंत अडवलं जातं. आधी orders delete केल्या तर sales history कायमची जाते: bills, audits, returns. Soft delete: is_active flag ALTER TABLE users ADD COLUMN is_active TINYINT NOT NULL DEFAULT 1;UPDATE users SET is_active = 0 WHERE id = 4; idnameis_active3neha14rahul0 SELECT * FROM users WHERE is_active = 1; App फक्त active users दाखवतं; row आणि तिच्या ordersराहतात, म्हणून history सुरक्षित. User परत आला? परत SET is_active = 1.

Figure 9. Orders असेपर्यंत hard delete ERROR 1451 ने अडवला जातो, आणि history नष्ट करेल. Soft delete row is_active = 0 सह ठेवतो; app WHERE is_active = 1 ने list काढतं.

Ravindra Bagale's Tip

एकही CREATE TABLE लिहिण्याआधी tables कागदावर काढा, प्रत्येक child column पासून त्याच्या parent पर्यंत बाण काढा, आणि प्रत्येकात एक sample row भरा. Cell ला list लागत असेल तर table बनवा; column मध्ये दुसऱ्या table चा id असेल तर त्याला FOREIGN KEY द्या. Child ला नेहमी parent हवाच असेल, उदा. order चा user_id, तर foreign key column ला NOT NULL लावा. कागदावरची दहा मिनिटं नंतर orphan rows साफ करण्याचे दिवस वाचवतात.

Practice झाल्यावर exit; टाइप करा आणि EC2 instance stop करा.

16. Hands-on lab: keys, foreign key आणि soft delete

हा lab का. Keys म्हणजे database चे स्वतःचे नियम. हा lab प्रत्येक नियम मुद्दाम मोडून बघतो (duplicate email, नसलेल्या user ची order, orders असलेला user delete करणं) आणि खऱ्या apps वापरतात त्या soft delete ने संपतो.

  1. नवीन database बनवा
    • Command: CREATE DATABASE shop; USE shop;
    • काय दिसेल: Query OK, 1 row affected, मग Database changed.
    • Check करा: Prompt मध्ये [shop] दिसतं.
    • का: नवीन database म्हणजे तुमचे results या steps शी तंतोतंत जुळतील.
  2. keys सकट users बनवा
    • Command: CREATE TABLE users (id INT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(20), email VARCHAR(50) UNIQUE);
    • काय दिसेल: Query OK, 0 rows affected
    • Check करा: DESC users; मध्ये id वर PRI आणि email वर UNI.
    • का: CREATE TABLE मध्ये keys दिल्या की पहिल्या row पासून नियम लागू. नंतर जोडल्या तर आधीच duplicates आले असतील तर fail होतं.
  3. दोन users जोडा
    • Command: INSERT INTO users (name, email) VALUES ('amit', 'amit@example.com'), ('neha', 'neha@example.com');
    • काय दिसेल: Query OK, 2 rows affected
    • Check करा: SELECT * FROM users; → ids 1 आणि 2.
    • का: ids type केले नाहीत: AUTO_INCREMENT 1 आणि 2 देतो.
  4. Duplicate email करून बघा
    • Command: INSERT INTO users (name, email) VALUES ('amit2', 'amit@example.com');
    • काय दिसेल: ERROR 1062 (23000): Duplicate entry 'amit@example.com' for key 'email'
    • Check करा: SELECT COUNT(*) FROM users; → 2.
    • का: एक email एकाच account चा असायला हवा, नाहीतर login आणि password reset बिघडतात. UNIQUE हे लागू करतो.
  5. foreign key सकट orders बनवा
    • Command: CREATE TABLE orders (id INT PRIMARY KEY AUTO_INCREMENT, user_id INT, amount DECIMAL(10,2), FOREIGN KEY (user_id) REFERENCES users(id));
    • काय दिसेल: Query OK, 0 rows affected
    • Check करा: DESC orders; मध्ये user_id वर MUL.
    • का: orders child; users parent. दोन्ही columns INT, जे foreign key साठी आवश्यक आहे.
  6. योग्य order जोडा
    • Command: INSERT INTO orders (user_id, amount) VALUES (1, 499.00);
    • काय दिसेल: Query OK, 1 row affected
    • Check करा: SELECT * FROM orders; → 1 | 1 | 499.00.
    • का: User 1 अस्तित्वात आहे, म्हणून child row ला परवानगी.
  7. नसलेल्या user ची order करून बघा
    • Command: INSERT INTO orders (user_id, amount) VALUES (30, 100.00);
    • काय दिसेल: ERROR 1452 (23000): Cannot add or update a child row: a foreign key constraint fails ...
    • Check करा: SELECT COUNT(*) FROM orders; → 1.
    • का: User 30 नाही, म्हणून user 30 ची order नाही. Foreign key नसता तर ही orphan row ज्याला bill करायचं असा कोणीही नसताना sales data मध्ये बसली असती.
  8. orders असलेला user delete करून बघा
    • Command: DELETE FROM users WHERE id = 1;
    • काय दिसेल: ERROR 1451 (23000): Cannot delete or update a parent row: a foreign key constraint fails ...
    • Check करा: SELECT name FROM users; मध्ये अजून amit दिसतो.
    • का: नियम दोन्ही बाजूंनी चालतो: मुलं असलेला parent orphans मागे सोडून नाहीसा होऊ शकत नाही.
  9. त्याऐवजी soft delete
    • Command: ALTER TABLE users ADD COLUMN is_active TINYINT NOT NULL DEFAULT 1; UPDATE users SET is_active = 0 WHERE id = 1;
    • काय दिसेल: दोन्हीसाठी Query OK; update 1 row affected सांगतो.
    • Check करा: SELECT name FROM users WHERE is_active = 1; → neha.
    • का: Account app मधून दिसेनासा होतो, पण bills आणि audits साठी order history राहते. User परत आला तर is_active = 1 करा.
  10. साफ करा
    • Command: DROP DATABASE shop;
    • काय दिसेल: Query OK, 2 rows affected (दोन tables काढले).
    • Check करा: SHOW DATABASES; मध्ये आता shop नाही. Exit करा आणि instance stop करा.
    • का: पूर्ण practice database drop केल्याने दोन्ही tables एकाच step मध्ये जातात. खऱ्या data वर हे कधीच चालवू नका.

17. पूर्ण class एका page वर

  1. Keys CREATE TABLE मध्येच: inline email VARCHAR(50) UNIQUE, किंवा comma नंतर table level ..., UNIQUE(email).
  2. Duplicate वर ERROR 1062 ... for key 'email', आणि fail झालेला insert एक id वापरतो.
  3. Database design: किती tables, कोणते columns कुठे, आणि ते कसे जोडलेले.
  4. Counters कोणी किंवा कधी सांगू शकत नाहीत. प्रत्येक घटनेची एक row (likes), आणि SELECT COUNT(*) FROM likes WHERE reel_id = 102;
  5. प्रत्येक row ला एक value: column. प्रत्येक row ला अनेक values: वेगळा table.
  6. User चा प्रवास चालून tables शोधा. Actions (search, filter, add to cart) columns नाहीत.
  7. Category नावासारखा परत परत येणारा text वेगळा table आणि id column (category_id) होतो.
  8. Foreign key: FOREIGN KEY (user_id) REFERENCES users(id). Parent = users, child = orders. DESC MUL दाखवतो.
  9. Parent column त्याच type चा PRIMARY KEY किंवा UNIQUE column असला पाहिजे; नाहीतर ERROR 1005 (errno 150).
  10. Parent नसलेला child: ERROR 1452. Children असलेला parent delete किंवा बदलणं: ERROR 1451. आधी child delete करा.
  11. Soft delete: is_active 1 / 0, आणि app मध्ये WHERE is_active = 1.

18. Try at home

Try at home

Task 1: बनवतानाच keys

  1. id INT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(50), sku VARCHAR(20), आणि table-level UNIQUE(sku) असलेला products table बनवा.
  2. तोच sku दोनदा टाका आणि error वाचा. मग नवा टाका आणि त्याचा id समजावून सांगा.
  3. नव्या table मध्ये UNIQUE(sku) च्या आधीचा comma काढा आणि error वाचा.

Task 2: कागदावर design

  1. Food delivery app चा प्रवास चाला: sign up, restaurant शोधणं, dishes जोडणं, pay, track, rate.
  2. Tables ची list करा. प्रत्येकासाठी एक sample row लिहा आणि अनेक-values चा नियम लावा.
  3. दुसऱ्या table चा id ठेवणारा प्रत्येक column mark करा. त्याच तुमच्या foreign keys.

Task 3: foreign keys सह reels

  1. FOREIGN KEY (user_id) REFERENCES users(id) सह reels (id, user_id, caption) बनवा.
  2. likes दोन foreign keys सह परत बनवा: user_id ते users(id) आणि reel_id ते reels(id).
  3. एक reel आणि तीन likes टाका, COUNT(*) ने मोजा, मग user 30 चं like टाकून बघा.

Task 4: सुरक्षित delete

  1. Reel असलेल्या user ला delete करून बघा, आणि error वाचा.
  2. योग्य क्रमाने delete करून ते चालवा.
  3. users ला is_active जोडा, एका user ला deactivate करा, आणि फक्त active users ची list काढा.

Recap

थोडक्यात

  1. Keys CREATE TABLE मध्येच लावा: column वर inline UNIQUE, किंवा comma नंतर शेवटचा item म्हणून UNIQUE(email); duplicate वर ERROR 1062.
  2. Database design किती tables, कोणते columns कुठे, आणि tables कसे जोडलेले ते ठरवतो.
  3. Counter column कोणी किंवा कधी सांगू शकत नाही; प्रत्येक like ची एक row ठेवा आणि SELECT COUNT(*) FROM likes WHERE reel_id = ... ने मोजा.
  4. प्रत्येक row ला एक value म्हणजे column; प्रत्येक row ला अनेक values म्हणजे वेगळा table, प्रत्येक value ची एक row.
  5. Tables शोधायला user चा प्रवास चाला; add to cart सारख्या actions columns नाहीत.
  6. Foreign key orphan rows थांबवतो: FOREIGN KEY (user_id) REFERENCES users(id); parent column PRIMARY KEY किंवा UNIQUE असला पाहिजे, आणि DESC child column वर MUL दाखवतो.
  7. ERROR 1452: child च्या value ला parent नाही. ERROR 1451: parent ला अजून children आहेत, म्हणून आधी child delete करा.
  8. Soft delete history वाचवतो: delete ऐवजी is_active = 0 करा, आणि WHERE is_active = 1 ने list काढा.

सराव Tasks

या scenario बद्दल

Dublin Fitness Club हा डब्लिन मधला फिटनेस व्यवसाय आहे. Siobhan Murphy त्यांचं IT व cloud काम पाहतात. त्यांचे पैसे EUR मध्ये मोजले जातात आणि AWS resources eu-west-1 Region मध्ये चालतात. खालच्या tasks मध्ये तुम्ही या lesson मध्ये शिकलेलं वापरून त्यांची खरी कामं करता. सगळी नावं, account IDs, IP addresses व numbers सरावासाठी काल्पनिक आहेत.

0 / 10

सोपं मोठ्या orders आधी

का: RDS setup नंतर database query करणं रोजचं काम.

काय करायचं: Order id व amount, मोठी amount आधी.

Tables: customers(id, name, city) व orders(id, customer_id, amount, odate).

कसं करायचं:
  1. Task कोणत्या table बद्दल आहे ते पाहा (box वरची table list).
  2. SQL statement step by step लिहा: काय, कुठून, कोणते rows.
  3. Statement ; ने संपवा.
  4. Check answer दाबा. Query table च्या practice copy वर चालते.

सोपं City नुसार customers

का: RDS setup नंतर database query करणं रोजचं काम.

काय करायचं: Pune मधल्या customers ची नावं.

Tables: customers(id, name, city) व orders(id, customer_id, amount, odate).

कसं करायचं:
  1. Task कोणत्या table बद्दल आहे ते पाहा (box वरची table list).
  2. SQL statement step by step लिहा: काय, कुठून, कोणते rows.
  3. Statement ; ने संपवा.
  4. Check answer दाबा. Query table च्या practice copy वर चालते.

सोपं MariaDB मध्ये login करा

का: mysql client ने database server वर SQL चालवता येतं.

काय करायचं: MariaDB client root user म्हणून उघडा व password विचारू द्या.

कसं करायचं:
  1. हे काम करणारा Linux command शोधा.
  2. Task ला लागणारे options (उदा. -r, -h) जोडा.
  3. File नावं, folders किंवा users योग्य क्रमाने लिहा.
  4. System files/users बदलत असाल तर sudo वापरा. Check answer दाबा.

मध्यम एकूण sales

का: RDS setup नंतर database query करणं रोजचं काम.

काय करायचं: सगळ्या order amounts ची बेरीज.

Tables: customers(id, name, city) व orders(id, customer_id, amount, odate).

कसं करायचं:
  1. Task कोणत्या table बद्दल आहे ते पाहा (box वरची table list).
  2. SQL statement step by step लिहा: काय, कुठून, कोणते rows.
  3. Statement ; ने संपवा.
  4. Check answer दाबा. Query table च्या practice copy वर चालते.

मध्यम Customer नावांसह orders

का: RDS setup नंतर database query करणं रोजचं काम.

काय करायचं: प्रत्येक customer नाव व order amount.

Tables: customers(id, name, city) व orders(id, customer_id, amount, odate).

कसं करायचं:
  1. Task कोणत्या table बद्दल आहे ते पाहा (box वरची table list).
  2. SQL statement step by step लिहा: काय, कुठून, कोणते rows.
  3. Statement ; ने संपवा.
  4. Check answer दाबा. Query table च्या practice copy वर चालते.

मध्यम लहान orders काढा

का: RDS setup नंतर database query करणं रोजचं काम.

काय करायचं: 200 पेक्षा कमी amount चे orders delete.

Tables: customers(id, name, city) व orders(id, customer_id, amount, odate).

कसं करायचं:
  1. Task कोणत्या table बद्दल आहे ते पाहा (box वरची table list).
  2. SQL statement step by step लिहा: काय, कुठून, कोणते rows.
  3. Statement ; ने संपवा.
  4. Check answer दाबा. Query table च्या practice copy वर चालते.

मध्यम City दुरुस्त करा

का: RDS setup नंतर database query करणं रोजचं काम.

काय करायचं: Customer 5 Rome ला गेले. Record update करा.

Tables: customers(id, name, city) व orders(id, customer_id, amount, odate).

कसं करायचं:
  1. Task कोणत्या table बद्दल आहे ते पाहा (box वरची table list).
  2. SQL statement step by step लिहा: काय, कुठून, कोणते rows.
  3. Statement ; ने संपवा.
  4. Check answer दाबा. Query table च्या practice copy वर चालते.

अवघड Customer नुसार sales

का: RDS setup नंतर database query करणं रोजचं काम.

काय करायचं: Customer नुसार total, फक्त 1000 पेक्षा जास्त.

Tables: customers(id, name, city) व orders(id, customer_id, amount, odate).

कसं करायचं:
  1. Task कोणत्या table बद्दल आहे ते पाहा (box वरची table list).
  2. SQL statement step by step लिहा: काय, कुठून, कोणते rows.
  3. Statement ; ने संपवा.
  4. Check answer दाबा. Query table च्या practice copy वर चालते.

अवघड Orders नसलेले customers

का: RDS setup नंतर database query करणं रोजचं काम.

काय करायचं: कधीच order न केलेल्या customers ची नावं.

Tables: customers(id, name, city) व orders(id, customer_id, amount, odate).

कसं करायचं:
  1. Task कोणत्या table बद्दल आहे ते पाहा (box वरची table list).
  2. SQL statement step by step लिहा: काय, कुठून, कोणते rows.
  3. Statement ; ने संपवा.
  4. Check answer दाबा. Query table च्या practice copy वर चालते.

अवघड Database चा file मध्ये backup घ्या

का: mysqldump पूर्ण database SQL म्हणून लिहितो. मोठ्या बदलांआधी save करा.

काय करायचं: dublinfit_wp database root user ने (password विचारून) dublinfit_wp.sql मध्ये dump करा.

कसं करायचं:
  1. हे काम करणारा Linux command शोधा.
  2. Task ला लागणारे options (उदा. -r, -h) जोडा.
  3. File नावं, folders किंवा users योग्य क्रमाने लिहा.
  4. System files/users बदलत असाल तर sudo वापरा. Check answer दाबा.

उजळणी, तुलना आणि मुलाखत cards

हा lesson काही मिनिटांत revise करा. Cards phone वर save करा किंवा PNG download करा. प्रत्येक card वरचा QR हा lesson उघडतो.

उजळणी card: Database design म्हणजे काय?. वाईट design म्हणजे repeated data, चुकीचे counts आणि slow queries. कोणते tables आणि कोणता column कुठे हे ठरवणं. User journey चाला; एका row ला अनेक values म्हणजे नवीन table. Flipkart: users, products, orders, order_items.
उजळणी card: Database design म्हणजे काय? · PNG download करा
उजळणी card: Counter नाही, likes table का. like_count column कोणी like केलं ते सांगत नाही, एकाला दोनदा like करू देतो. likes table प्रत्येक user प्रत्येक reel साठी एक row ठेवतो. COUNT(*) ने मोजा; UNIQUE(user_id, reel_id) add करा. Count:
उजळणी card: Counter नाही, likes table का · PNG download करा
उजळणी card: Foreign keys. अस्तित्वात नसलेल्या users च्या orders (orphan rows) reports बिघडवतात. Foreign key child column ला parent च्या primary key कडे point करते. FOREIGN KEY ... REFERENCES add करा. DESC column वर MUL दाखवतो. orders मध्ये:
उजळणी card: Foreign keys · PNG download करा
उजळणी card: Soft delete. User delete केल्यास जुन्या orders तुटतात आणि history जाते. Soft delete row काढण्याऐवजी inactive mark करतो. is_active add करा; queries त्यावर filter करतात. Deactivate:
उजळणी card: Soft delete · PNG download करा
तुलना: Hard delete vs Soft delete. Hard delete: DELETE row कायमची काढतो. Soft delete: is_active flag row गेली असं mark करतो.
तुलना: Hard delete vs Soft delete · PNG download करा
मुलाखत card: Foreign key म्हणजे काय, काय टाळते?. दुसऱ्या table च्या primary key शी जुळायलाच हवा असा column. Deleted users च्या orders सारख्या orphan rows टाळते. orders.user_id REFERENCES users.id.
मुलाखत card: Foreign key म्हणजे काय, काय टाळते? · PNG download करा
मुलाखत card: ERROR 1452 आणि ERROR 1451 म्हणजे काय?. 1452: parent नसलेला child insert. 1451: children असलेला parent delete. दोन्ही foreign key तुमचा data वाचवते. अस्तित्वात नसलेल्या user_id 99 ची order › 1452.
मुलाखत card: ERROR 1452 आणि ERROR 1451 म्हणजे काय? · PNG download करा
मुलाखत card: "liked" सारख्या user actions users table मध्ये columns का नाहीत?. एक user अनेक actions करतो; प्रत्येकाला स्वतःच्या table मध्ये row हवी. Columns एका row ला एकच value ठेवतात. likes(user_id, reel_id), orders(user_id, total).
मुलाखत card: "liked" सारख्या user actions users table मध्ये columns का नाहीत? · PNG download करा

अजून cards: Ravi Sir's Cards.