স্বপ্নচারী লিখেছেন:ইনভারব্রাস, আমি আসলে সিকুয়েলে যেতে চাচ্ছি না। এখানে বেশ কিছু জিনিস ওভার-নরমালাইজড হয়ে গেছে। প্রচুর জয়েন করা লাগবে একটা কুয়েরি করতে। প্রথম থেকেই তাই নোসিকুয়েল মডেল বানিয়েছি আমি। partsofspeech, dictionary, synonyms, antonyms টেবিলগুলোর আসলে কোন প্রয়োজনই নাই। এগুলো অহেতুক জয়েনার বাড়াবে। ডাটা নরমালাইজ করা হয় যখন স্থানের সমস্যা থাকে। আজকাল মেমরি নিয়ে কোন সমস্যা নাই। তাই ছোটখাট কয়েকটা ফিল্ডের জন্য আলাদা টেবিল বানিয়ে জয়েন করে সিপিইউ খরচ করার কোন মানে নাই। word_translations আলাদা রাখার কোন সুবিধাও আমি দেখছি না।
এখানে ডেমো সাইটটা সবাই দেখতে পারেন - http://bengdict.appspot.com/
একটু আধটু নাড়াচাড়া শুরু করুন। তবে এখনই আসল ডাটা এন্ট্রি শুরু করবেন না। পরীক্ষামূলকভাবে নাড়াচাড়া করুন। উদ্বোধনের আগে সকল ডাটা মুছে ফেলা হবে। তাছাড়া এটা ফাইনালও না। সবার মন্তব্য জানা যাক আগে। গ্রাফিক্স ডিজাইন নিয়ে এখনই মাথা ঘামানোর সময় হয়নি। সেটা পরে আসবে।
দ্বিমত পোষণ করছি। SQL একটা DSL (domain specific language) মাত্র, আর কিছু না। আপনি সম্ভবত: RDBMS বনাম OODB-র ব্যাপারে বলতে চাইছেন। BigTable অবজেক্ট ডেটাবযে কিনা জানিনা, তবে নি:সন্দেহে নন-রিলেশনাল।
আপনি যদি কেবলমাত্র একটি জায়গায় (bengdict.appspot.com) ডিক্সনারীটি হোস্ট করতে চান তাহলে ঠিক আছে। কিন্তু ওয়াইড ডিপ্লয়মেন্টের কথা মাথায় রাখলে অবশ্যই রিলেশনাল ডেটাবেযে যেতে হবে - এবং ৯৯% ক্ষেত্রেই তা হলো mysql (আজকাল sqlite এবং pgsql-ও থাকে বেশিরভাগ ওয়েবহোস্টেই)
পেশাগত কারণে কিছুদিন ধরে InterSystems Caché নামে একটি অবজেক্ট ডেটাবেয নিয়ে ঘাঁটাঘাঁটি করছি। আগেও OODB নিয়ে হালকা নাড়াচাড়া করেছিলাম (db4o, Perst), তবে এখন ক্যাশে নিয়ে বেশ সিরিয়াসলী লেগে আছি। অবজেক্ট ডেটাবেযে কাজ করা বেশ সহজ, মজাও পাচ্ছি। তবে একটা ব্যাপার খেয়াল করেছি - অবজেক্ট ডেটাবেয সিস্টেমে এন্টিটি মডেলিং করা যত সোজা, রিলেশনাল সিস্টেম সেই কাজটি করা ততটাই ঝামেলার।
মশা তাড়ানোর অনেক পদ্ধতি আছে - এ্যারোসল দিয়েও তাড়ানো যায়, আবার কয়েল জ্বালিয়েও করা যায়। এ্যারোসল ব্যবহার করতে চাইলে আমাকে বোতাম চাপতে হবে, আগুন ধরালে হবে না। আবার কয়েলে আগুন ধরাতে হবে, টিপতে গিয়ে ভেংগে ফেললে হবে না।
তেমনি, বিজনেস প্রসেস একই হলেও - রিলেশনাল ডেটাবেয এবং অবজেক্ট ডেটাবেযের ডিজাইনের মধ্যে ভিন্নতা থাকবেই।
পাইথনে যখন ক্লাস লাইব্রেরী লিখি, সেটি আসলে লজিকাল এন্টিটি। আর একই কাজ ম্যানুয়ালী SQL দিয়ে যখন করি - সেটি হলো ফিজিকাল মডেল। আর SQL যেহেতু closer to the metal, স্বাভাবিকভাবেই জটিল এবং বিদঘুটে হবেই। 
রিলেশনাল ডিজাইনটা একটু কম্পলিকেটেড লাগছে কারণ এই মডেলটা প্রচুর extensibility এবং flexibility দিচ্ছে। যদি শুধুমাত্র ইংরেজী-বাংলার জন্য ডিজাইন করতাম তাহলে ১ টা টেবিল দিয়েই হয়ে যেত।
মডেলটা থার্ড নর্মালাইযড ফর্মে আছে। অপ্টিমাইজেশনের জন্য কিছুটা ডিনরমালাইয করা যেতে পারে। আর এমনিতেও ওটা একটা প্রোটোটাইপ, ফাইনাল ভার্সনে (যদি হয় আরকি) প্রায় পুরোটাই বদলে যাবে। তবে এই ব্যাপারে একমত: এটা যদি অবজেক্ট ডেটাবেয সিস্টেমে মডেল করতাম, তাহলে খুবই সহজভাবে করা যেত, সর্বোচ্চ ২-৩টি এন্টিটি/অবজেক্ট দিয়েই হয়ে যেত (স্বপ্নচারী ভাইয়ের বিগটেবল-বেইজড মডেলটার মতই হতো)। কিন্তু এখানে হাত পা বাঁধা - রিলেশনাল মডেলটাই এরকম 
অনুপদার পোস্ট থেকে বুঝতে পারছি ডিজাইনটি একটু ব্যাখ্যা করার প্রয়োজন আছে।
ডেটাবেযটি এভাবে নরমালাইয করার কারণ আছে বেশ কয়েকটি। আগের পোস্টেই বলেছি, আমার টার্গেট ছিলো scalability এবং extensibility।
আমরা সবাই শুধু ইংরেজী - বাংলা নিয়ে চিন্তা করছি। কিন্তু দুনিয়ায় আরো তো ভাষা আছে। আমাদের দেশেই তো প্রচলিত আছে আরবী, উর্দু, হিন্দী ইত্যাদি, এদের সাথে আদিবাষী ভাষাও (যেমন চাকমা, সাওতাঁল) যোগ করুন। এছাড়া লক্ষ লক্ষ বাংলাভাষী বিদেশে থাকে; তাদের জন্য ফ্রেন্চ, স্প্যানিশ, জাপানী, চীনা, কোরিয়ান, মালয়, তাগালগ ইত্যাদি ভাষাও গুরুত্বপূর্ণ। এরা কি দোষ করলো?
ডায়াগ্রামটি আবার দিচ্ছি এখানে:

এই (রিলেশনাল) মডেলটিতে যেকোনো ধরণের ভাষা যোগ করার সিস্টেম আছে। dictionary টেবিলটি খেয়াল করুন - এটাতে ইংরেজী=>বাংলা, বাংলা=>ইংরেজী, আরবী=>বাংলা=>আরবী, হিন্দী=>বাংলা=>হিন্দী এরকম অসংখ্য ভাষার ডিক্সনারী যোগ করার সুযোগ আছে।
এবার words_main টেবলটি দেখুন -
`dict_id` INTEGER NOT NULL,
`original_word` VARCHAR(40) NOT NULL,
এখানে খেয়াল করুন, original_word ফিল্ডে আমরা যেকোনো ভাষার শব্দ এন্টৃ করতে পারবো - হোক সেটি বাংলা, বা ইংরেজী, আরবী, ফ্রেন্চ কিংবা এমনকি বামবারা (আফ্রিকান একটি ভাষা
) শব্দ - the language doesn't matter। আমরা যাস্ট সঠিক dict_id ফিল্ডে উপযুক্ত ডিক্সনারীর আইডি নাম্বারটি দিয়ে দেবো। যেমন ধরি, বাংলা=>ইংরেজী ডিক্সনারীর আইডি নাম্বার হলো ১০১, আবার ফ্রেন্চ=>বাংলা ডিক্সনারীর আইডি হলো ৫০৫। তাহলে নীচের টেবিল থেকে নিশ্চয়ই বোঝা কঠিন হবে না কোন শব্দটা কোন ভাষায়:
dict_id original_word
------- -------------
101 car
505 voiture
ইনফ্যাক্ট, এই টেবিল দু'টো যদি SQL JOIN করি তাহলে আরো সহজ হয়ে যাচ্ছে:
dictionary original_word
---------- -------------
en-bn car
fr-bn voiture
word_translations, word_usages, word_synonyms, word_antonyms এইসব টেবিলগুলোও একই রকম language agnostic।
একটা লাইভ উদাহরণ দেই:
bengdict.appspot.com-এ book শব্দের অর্থ দেয়া আছে এরকম:
Book
* [None] (Noun (বিশেষ্য)) বই
None
Synonyms:
Antonyms:
Comments
এটা একটা পৃলিমিনারী ডেমো অবশ্যই, তবুও একটি গুরুতর লিমিটেশন দেখা যাচ্ছে। এই মডেলে আমরা ধরেই নিচ্ছি Book শব্দটির একটিই মাত্র অর্থ আছে এবং অন্য কোনো অর্থ নেই।
obhidhan.org-এ এই স্ক্যানটি পেলাম:

দু'টোর মধ্যে পার্থক্য খেয়াল করুন (ডেটা ভলিউমের কথা বলছি না, মডেল/আরকিটেকচারের দিকে নির্দেশ করছি)। এই ধরণের ডিক্সনারী বানাতে গেলে আপনাকে অবশ্যই মডেল আপগ্রেড করতে হবে।
অবজেক্ট ডেটাবেযে করতে চাইলে হয়তো এরকম হতে পারে:
class Word(db.Model):
....
translated = db.ListProperty(unicode)
....
একই কাজ রিলেশনাল ডেটাবেযে করতে চাইলে foreign key, SQL JOIN ইত্যাদি ব্যবহার করতে হবে। সাইটটা django with RDBMS backend (pgsql, mysql) করলেও তো মোটামুটি এই ভাবেই করতে হবে।
দু'টোর মধ্যে যেকোনো একটা পছন্দের কথা যদি বলেন, ৯৯% মানুষের মত আমিও নি:সন্দেহে অবজেক্ট ডেটাবেযই পছন্দ করবো। শুধু যে সিস্টেমটা বুঝতে বা ডেভেলপ করতে সহজ তাই না, OODB-র পার্ফর্ম্যান্সও অনেক ভালো।
তবে এখানে ডীলব্রেকার হলো: রিলেশনাল ডেটাবেয টেকনোলজী যত সহজলভ্য, অবজেক্ট ডেটাবেয ততই বিরল। (একই ক্রাইটেরিয়া মোংগো, টোকিও ক্যাবিনেট বা ক্যাসান্ড্রার মত নোসিকল ডেটাস্টোরের ক্ষেত্রেও খাটে)
ডিক্সনারীর মত ওপেনসোর্স কমিউনিটি প্রযেক্ট ডিসেন্ট্রালাইযড থাকা উচিৎ। আগামীকাল যদি GAE কমার্শিয়াল সার্ভিস করে দেয় (বা গুগলে মারা যায়
) তখন বিপদে পড়তে হবে। তবে রিলেশনাল সিস্টেমে থাকলে (mysql, sqlite) যেকোনো জায়গায় সহজে পোর্ট করা যায়।
Calm... like a bomb.