SQL vs NoSQL: আপনার অ্যাপে কোন ডেটাবেস ব্যবহার করা উচিত?

SQL ডেটাবেস (যাকে রিলেশনাল ডেটাবেসও বলা হয়) টেবিলে নির্দিষ্ট কাঠামোসহ ডেটা রাখে, যেখানে থাকে সারি ও কলাম, এবং সম্পর্কিত টেবিলগুলো একসাথে লিংক করা হয়। এগুলোতে SQL ভাষা দিয়ে কোয়েরি করা হয়। Postgres, MySQL ও SQLite এর উদাহরণ। NoSQL ডেটাবেস ডেটা রাখার অন্য উপায় ব্যবহার করে, যেমন ডকুমেন্ট, কী-ভ্যালু জোড়া, ওয়াইড কলাম বা গ্রাফ, এবং সাধারণত আরও নমনীয় কাঠামোর সুযোগ দেয়। MongoDB, Redis, DynamoDB ও Firestore এর উদাহরণ। বেশিরভাগ ব্যবসায়িক অ্যাপের জন্য SQL ডেটাবেসই যুক্তিসংগত ডিফল্ট; NoSQL নির্দিষ্ট কাজে ভালো চলে।

AI দিয়ে বানানোর সময় এই পছন্দ কেন গুরুত্বপূর্ণ

অ্যাপের সবচেয়ে কঠিন বদলযোগ্য অংশগুলোর একটি হলো ডেটাবেস। স্ক্রিন এক বিকেলেই নতুন করে ডিজাইন করা যায়; বছরের পর বছরের গ্রাহক ডেটা অন্য ধরনের ডেটাবেসে সরানো একটি প্রকল্প।

AI অ্যাপ বিল্ডার যখন আপনার জন্য ডেটা স্টোরেজ যোগ করে, তখন সে এর একটি বেছে নেয়। পার্থক্যটি জানলে আপনি:

• বুঝতে পারেন আপনার ডেটা কেমন এবং পরে যে প্রশ্নগুলো করবেন ("মাস অনুযায়ী প্রোডাক্ট প্রতি আয়") সেগুলোর উত্তর দিতে পারবে কিনা।
• প্ল্যাটফর্মের পছন্দ বিচার করতে পারেন। কিছু প্ল্যাটফর্ম ডকুমেন্ট ডেটাবেসের উপর, অন্যগুলো রিলেশনালের উপর তৈরি। প্রতিটির একটি সাধারণ উদাহরণের জন্য Supabase বনাম Firebase দেখুন।
• ভেন্ডর লক-ইন এড়াতে পারেন। SQL একটি সর্বজনীন মান, তাই রিলেশনাল ডেটা সাধারণত প্রোভাইডারদের মধ্যে সরানো সহজ।

একটি দৈনন্দিন উপমা

একটি SQL ডেটাবেস যেন কড়া কলামসহ সাবধানে ডিজাইন করা কয়েকটি স্প্রেডশিট: একটি শিট গ্রাহকদের, একটি অর্ডারের, এবং প্রতিটি অর্ডারের সারি ID দিয়ে একটি গ্রাহকের সারির দিকে নির্দেশ করে। শিটের প্রতিটি সারিতে একই কলাম থাকে। একটু পরিকল্পনা লাগে, কিন্তু শিটগুলো জুড়ে প্রশ্ন করা সহজ এবং ডেটা গোছানো থাকে।

একটি NoSQL ডকুমেন্ট ডেটাবেস যেন ফোল্ডারের একটি ফাইলিং ক্যাবিনেট। প্রতিটি গ্রাহকের ফোল্ডারে তার বিবরণ ও অর্ডার একসাথে থাকতে পারে, আর একটি ফোল্ডারে অন্যদের নেই এমন অতিরিক্ত কাগজ থাকতে পারে। একজন গ্রাহকের পুরো ইতিহাস দ্রুত পাওয়া যায়। কিন্তু "গত মাসে সবাই কী অর্ডার করেছিল?" জানতে অনেক ফোল্ডার খুলতে হয়।

আসল পার্থক্যগুলো

"NoSQL" একটি একক জিনিস নয়। প্রধান ধরনগুলো:

একটি কাজের উদাহরণ: একই দোকানের ডেটা, দুই উপায়ে

একটি ছোট অনলাইন দোকান ধরুন, যেখানে একজন গ্রাহক ও তার অর্ডার আছে।

SQL (রিলেশনাল): ডেটা টেবিলে ভাগ করা হয় এবং ID দিয়ে লিংক করা হয়।

-- customers: id=1, name='Lena Ortiz'
-- orders:    id=101, customer_id=1, total=42.00
--            id=103, customer_id=1, total=25.00

SELECT c.name, SUM(o.total)
FROM customers c JOIN orders o ON o.customer_id = c.id
GROUP BY c.name;

Lena তার ইমেইল বদলালে তা একটিমাত্র জায়গাতেই বদলায়। "এই মাসে প্রতি গ্রাহকের মোট বিক্রি" জানতে একটিমাত্র কোয়েরি লাগে।

NoSQL (ডকুমেন্ট): তার অর্ডারগুলো তার ডকুমেন্টের ভেতরেই থাকতে পারে।

{
  "_id": "cust_1",
  "name": "Lena Ortiz",
  "email": "lena@example.com",
  "orders": [
    { "id": 101, "total": 42.00, "items": ["Green tea"] },
    { "id": 103, "total": 25.00, "items": ["Teapot"] }
  ]
}

তার সব অর্ডারসহ প্রোফাইল পেজ লোড করা একটিমাত্র রিড। কিন্তু সব গ্রাহক জুড়ে প্রশ্ন, যেমন এই মাসের সবচেয়ে বেশি বিক্রি হওয়া প্রোডাক্ট, বেশি কাজ লাগে, আর একই প্রোডাক্টের বিবরণ অনেক অর্ডারে কপি হলে সেগুলো সমান রাখা অ্যাপের দায়িত্ব হয়ে ওঠে।

কোনোটিই ভুল নয়। প্রশ্ন হলো আপনার অ্যাপ বেশিরভাগ সময় কোন প্যাটার্ন ব্যবহার করে।

কীভাবে বেছে নেবেন

একটি রিলেশনাল SQL ডেটাবেস সাধারণত সঠিক ডিফল্ট, যদি:

• আপনার ডেটার অনেক সম্পর্ক থাকে: ইউজার, টিম, বুকিং, ইনভয়েস, প্রোডাক্ট।
• রেকর্ড জুড়ে রিপোর্ট, ফিল্টার ও মোট হিসাব দরকার হয়।
• সঠিকতা গুরুত্বপূর্ণ: টাকা, স্টক লেভেল, পারমিশন।

একটি NoSQL ডেটাবেস বিবেচনা করার মতো, যদি:

• আপনার একটি দ্রুত ক্যাশ বা সেশন স্টোর দরকার, এখানে Redis সাধারণ, প্রায়ই একটি SQL ডেটাবেসের পাশাপাশি।
• আপনার রেকর্ড সংখ্যায় বিশাল, সহজ ও স্বতন্ত্র, যেমন ইভেন্ট লগ বা সেন্সর রিডিং।
• আপনি একটি সেরকম প্ল্যাটফর্মে আছেন, যেমন Firebase-এর Firestore, এবং এর রিয়েল-টাইম ফিচারই মূল আকর্ষণ।

অনেক অ্যাপ দুটোই ব্যবহার করে: SQL প্রধান সত্যের উৎস হিসেবে, আর ক্যাশিং বা একটি নির্দিষ্ট ফিচারের জন্য একটি NoSQL স্টোর।

মূল শব্দ

সাধারণ ভুল ধারণা

• "NoSQL মানে কোনো স্কিমা নেই।" আপনার ডেটার সবসময় একটি আকার থাকে। NoSQL-এ ডেটাবেস তা নাও বাধ্য করতে পারে, তাই আপনার কোডকে তা করতে হয়।
• "SQL স্কেল করে না।" রিলেশনাল ডেটাবেস অনেক বড় সেবা চালায়। বেশিরভাগ অ্যাপ তাদের সীমার কাছেও যায় না।
• "NoSQL সবসময় দ্রুত।" শুধু তার জন্য ডিজাইন করা প্যাটার্নে। সব জায়গা জুড়ে করা রিপোর্ট ধীর হতে পারে।
• "একবার বেছে নিলে চিরকাল ওটাই।" অনেক অ্যাপ দুটোই মেলায়। আর Postgres-এর মতো SQL ডেটাবেসও JSON রাখে, তাই কয়েকটি নমনীয় ফিল্ডের জন্য NoSQL লাগে না।
• "NoSQL মানে আপনি SQL ব্যবহার করতে পারবেন না।" নামটি সাধারণত "শুধু SQL নয়" হিসেবে পড়া হয়, আর কিছু NoSQL প্রোডাক্ট SQL-সদৃশ কোয়েরি ভাষা দেয়।

আপনার AI বিল্ডারকে কী জিজ্ঞেস করবেন

• "এই অ্যাপ কোন ধরনের ডেটাবেস ব্যবহার করে, এবং কেন এটি আমার ডেটার জন্য ভালো?"
• "টেবিল বা কালেকশন এবং সেগুলো কীভাবে সম্পর্কিত, তা আঁকুন।"
• "ছয় মাস পরে কোন রিপোর্টগুলো চাইব? এই ডেটাবেস কি সেগুলো সহজে দিতে পারবে?"
• "কয়েকটি ফিল্ড সত্যিই নমনীয় হলে, দ্বিতীয় ডেটাবেস যোগ না করে Postgres-এ সেগুলো JSON হিসেবে রাখুন।"
• "শুধু তখনই ক্যাশ যোগ করুন যখন মেপে দেখা গতির সমস্যা থাকবে।"

Mythex-এ ডেটাবেস

Mythex যে প্রতিটি প্রজেক্টের একটি প্রয়োজন, তাকে একটি নিবেদিত Postgres ডেটাবেস দেয়, অর্থাৎ একটি রিলেশনাল SQL ডেটাবেস, যা অ্যাপের প্রয়োজন হলে যোগ হয়: চ্যাটে চাইলে, অথবা /database কমান্ড দিয়ে (Database)। এটি বেশিরভাগ ব্যবসায়িক অ্যাপের জন্য মানানসই: ইউজার, বুকিং, অর্ডার ও রিপোর্ট। আপনার যদি একটি নির্দিষ্ট বাইরের সেবা দরকার, যেমন একটি হোস্টেড ডকুমেন্ট ডেটাবেস, এজেন্ট এমন কোড লিখতে পারে যা আপনার সংরক্ষিত প্রজেক্ট সিক্রেটের কী দিয়ে সেটির সাথে সংযোগ করে। ভাষাটি সম্পর্কে আরও জানতে SQL কী পড়ুন।

প্রশ্নোত্তর