অধ্যাপক আমাদের সম্পর্কিত সিরিয়াল সংজ্ঞায়নের পরিবর্তে সিরিয়ালযুক্ত জাভা অবজেক্টগুলিকে ব্লব হিসাবে সংরক্ষণ করতে বলেছিলেন

Question

সঠিক বৈশিষ্ট্য সহ কোনও টেবিলকে প্রকৃতপক্ষে সংজ্ঞায়িত করার পরিবর্তে, আমার অধ্যাপক আমাদের বলেছিলেন যে আমরা এই জাতীয় আইডিতে আইটেমগুলি ম্যাপ করতে পারি:

id (int)  |   Serialized Object (blob)
   1               10010110110

আমি এ দিয়ে অনেক সমস্যা দেখতে পাচ্ছি; ডেটা রিডানডেন্সি, আইডি আলাদাভাবে ট্র্যাক করে রাখা, যেকোন কিছু সন্ধানের জন্য পুরো টেবিলটিকে মেমরির মধ্যে টানতে হবে, এবং ** আমি যদি জাভা কোডটিতে আমার মডেলটি পরিবর্তন করতে চাই তবে আমি আর সঞ্চিত ব্লবটিকে ডিসেরায়াল করতে সক্ষম হব না যে মডেল মধ্যে ডাটাবেস।

হয় আমি সেই মডেলের সাথে চিরতরে আটকে থাকি বা আমার মডেলটি পরিবর্তন করতে আমাকে অন্য কিছু সত্যিই কুরুচিপূর্ণ জিনিস করতে হয় * ** এই পুরো জিনিসটি আমার কাছে খারাপ রূপ বলে মনে হয়। আমি কি আমার প্রফেসরের সাথে একমত হওয়ার পক্ষে যুক্তিযুক্ত নই? আমি যা ভেবে দেখিনি এটি করার কিছু সুবিধা আছে? আমি যদি সঠিক হই তবে আমার প্রফেসরকে এ বিষয়ে কিছু বলা উচিত? তিনি আমার পুরো ক্লাসে এটি প্রচার করছিলেন এবং এমনকি তিনি বলেছিলেন যে তিনি প্রকল্পগুলি সেভাবেই তৈরি করেছেন। একটি দ্বিতীয় মতামত দুর্দান্ত হবে।

কোর্সটির নাম দেওয়া হয়েছে সফটওয়্যার ডিজাইন ।

আমার অধ্যাপক এটি বলেননি যে এটি সর্বোত্তম উপায়, তবে তিনি বলেছিলেন যে এটি সম্পর্কিত টেবিলগুলি সংজ্ঞায়নের জন্য একটি বৈধ বিকল্প ছিল।

মডেল কোনওভাবেই গতিশীল নয়।

Comments

মন্তব্যগুলি বর্ধিত আলোচনার জন্য নয়; এই কথোপকথন চ্যাটে সরানো হয়েছে ।

— পল হোয়াইট GoFundMonica বলেছেন

Answer 1

1. এটি নিজের মধ্যে কোনও খারাপ জিনিস নয়। যথাযথ প্রসঙ্গ (= সঠিক প্রয়োজনীয়তা) ছাড়াই "যা ভাল" সম্পর্কে তর্ক করা নিরর্থকতার একটি অনুশীলন।

2. গা bold় অংশটি ভুল। আপনি নতুন ক্ষেত্র যুক্ত করতে এবং পুরানো অবজেক্টগুলির সাথে সম্পূর্ণ বাইনারি সামঞ্জস্যতা অর্জন করতে ইতিমধ্যে সিরিয়ালযুক্ত অবজেক্টগুলিকে সহজেই প্রসারিত করতে পারেন। আপনি আসলটি পরিবর্তনের পরিবর্তে কেবল নতুন ক্লাস তৈরি করতে পারেন।

প্রফেসরের সাথে আপনার আলোচনার বিমূর্ত "বেটারনেস" নয়, বিভিন্ন পরিস্থিতিতে "রিলেশনাল" বনাম "কী-মান স্টোর" এর বিপরীতে ফোকাস করা উচিত। অথবা থ্যাঙ্কসগিভিংয়ের চেয়ে ক্রিসমাস সর্বোত্তম কিনা তা নিয়ে আপনিও আলোচনা করতে পারেন।

- অন্যান্য উত্তর পড়ার পরে একটি সম্পাদনা।

অন্য একটি উত্তর যতদূর জানতে পারে যে "" এমন একটি ক্ষেত্রে কল্পনা করা শক্ত যেখানে মীমাংসিত লোকেরা তুলনামূলক বেশি "।

কারণ পুরো আলোচনাটি অবশ্যই কংক্রিট সমস্যা সম্পর্কিত (অন্যথায় আমরা "আরও ভাল" এবং "আরও খারাপ" সংজ্ঞায়িত করতে পারি না), আমি আপনাকে একটি দৃ concrete় উদাহরণ দেই। এটি সম্পূর্ণরূপে তৈরি, তবে আমি যতটা সম্ভব বিশদটি বের করার চেষ্টা করেছি।

কল্পনা করুন যে আপনার কাছে একটি অনলাইন গেমিং সাইট রয়েছে, এমন একটি ডাটাবেস যা বিভিন্ন অনলাইন গেমের খেলোয়াড়দের পরিসংখ্যান সঞ্চয় করে (ব্রাউজারে খেলেছে, জিডাব্লুটিটিতে লিখিত এবং জাভাস্ক্রিপ্টে ক্রস-সংকলিত)। কিছু গেম কৌশলগত, কিছু অ্যাকশন গেমস, কিছু প্ল্যাটফর্মার। ডাটাবেসটি সম্পর্কিত এবং খেলোয়াড় এবং নাটক এবং স্কোরের ইতিহাস সংরক্ষণ করে।

একদিন আপনি একটি অতিরিক্ত প্রয়োজনীয়তা পান: খেলোয়াড়রা গেমের সময়, খেলাগুলির মেঘে গেমের অবস্থাটি সংরক্ষণ করুন, যাতে তারা একই সময়ে, পরে খেলাটি পুনরায় আরম্ভ করতে পারে। বলা বাহুল্য, এই অস্থায়ী অবস্থা সংরক্ষণের একমাত্র কারণ হ'ল গেমটিতে ফিরে আসা, রাজ্যটি কখনই আত্মনিয়োগ করা হবে না।

এখন আপনার দুটি প্রাথমিক পছন্দ রয়েছে:

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

• আপনি আপনার 100 টি গেমের জন্য আলাদা আলাদা সম্পর্কিত মডেল তৈরি করতে পারেন (এটি প্রতি গেমের দশক টেবিল হবে)। একাকী প্যাকম্যানের জন্য, উদাহরণস্বরূপ, আপনাকে সমস্ত অপ্রচলিত পেললেট, বোনাস, অবস্থান এবং ভূতের বর্তমান অবস্থার একটি টেবিল সঞ্চয় করতে হবে। যদি কেউ, কোনও দিন, গেমটি সংশোধন করে, এমনকি সামান্যও হয় তবে আপনাকে রিলেশনাল মডেলটি আপডেট করতে হবে। এছাড়াও, প্রতিটি ধরণের গেমের জন্য, আপনাকে ডাটাবেসে জাভা মডেলটি লিখতে এবং এটি আবার পড়তে যুক্তি প্রয়োগ করতে হবে।

জাস্টিন কেভের উত্তর বলে, আপনার দ্বিতীয় বিকল্পটি নিয়ে যাওয়া উচিত। আমি মনে করি এটি একটি বিশাল ভুল হবে।

এছাড়াও, আমার একটি কুঁচক আছে যে জাস্টিন গুহর ধারণাটি যে আমি উপরে উপস্থাপন করেছি এটি একটি "প্রান্ত" বা "বিরল" কেস। আমি বিশ্বাস করি যে যদি না তিনি কিছু ধরণের হার্ড ডেটা (কেবলমাত্র মার্কিন যুক্তরাষ্ট্রে এন্টারপ্রাইজ অ্যাপ্লিকেশনগুলির প্রতিনিধির নমুনার উপর ভিত্তি করে) উপস্থাপন করতে না পারেন তবে আমি এ জাতীয় মতামতকে একটি প্রজেকশনটির একটি সর্বোত্তম বিষয় হিসাবে বিবেচনা করব পক্ষপাত।

প্রকৃতপক্ষে, একটি সম্পর্কিত ডেটাবেজে সিরিয়ালযুক্ত জাভা অবজেক্টগুলির সমস্যা মনে হয় তার থেকে অনেক গভীর। এটি 1NF এর একেবারে মূল অংশকে স্পর্শ করে, অর্থাত্ একটি গুনের ডোমেন কী? । আপনি যদি বিষয়টিতে সত্যই আগ্রহী হন, সিজে ডেটের একটি দুর্দান্ত নিবন্ধ আছে, তার ডেটাবেস-এ ডেটে: 2000-2006 রাইটিং ।

Comments

মন্তব্যগুলি বর্ধিত আলোচনার জন্য নয়; এই কথোপকথন চ্যাটে সরানো হয়েছে ।

— পল হোয়াইট GoFundMonica বলেছেন

Answer 2

(এবং কী) লোকেরা এই ধরণের কাজ করে এমন প্রকল্পগুলি সফলভাবে সরবরাহ করতে পারে? দুর্ভাগ্যক্রমে, হ্যাঁ, তারা যুক্তিযুক্তভাবে প্রায়শই এটি করে।

এই একটি ভাল পন্থা? না এইটা না. আপনি মূলত আপনার তুলনামূলকভাবে ব্যয়বহুল ডাটাবেস গ্রহণ করছেন এবং এটিকে তুলনামূলকভাবে ধীর ফাইল সিস্টেমে পরিণত করছেন। আপনি যদি সত্যই এমন একটি সিস্টেম তৈরি করতে চান যা অবজেক্টগুলি সিরিয়ালাইজ করে এবং ডি-সিরিয়ালাইজ করে তার রাজ্যটি সংরক্ষণ করে, আপনি একটি ডাটাবেস ব্যবহার না করে একটি ফাইল সিস্টেমও ব্যবহার করতে পারেন।

আপনি যদি এমন সিস্টেমগুলি তৈরি করেন যেগুলি ডাটাবেসে অবজেক্টগুলি সিরিয়ালাইজ করে ডেটা সঞ্চয় করে, আপনি আপনার ডিবিএর সাথে বন্ধুত্ব করবেন না। অপ্রয়োজনীয় ডেটা আপনি সংরক্ষণ করবেন। আপনি মারাত্মক অসঙ্গতিপূর্ণ ডেটা দিয়ে শেষ করবেন - যে কোনও সময় ভাগ করা ডেটা আপডেট হওয়ার পরে কিছু বস্তু নতুন মানগুলির সাথে শেষ হবে এবং কিছু বস্তু পুরানো মানগুলির সাথে সমাপ্ত হবে। আপনি ডেটাতে কোনও ধরণের প্রতিবেদন করা অসম্ভব করে ফেলবেন - যে কেউ ডেটা দিয়ে যা করতে চায় তার জন্য অতিরিক্ত কোড লেখার জন্য কারওর প্রয়োজন হয়। এটি বেশিরভাগ উদ্যোগে একটি বিশাল, বিশাল সমস্যা কারণ তারা অন্য সিস্টেমে লোড করার জন্য একটি সিস্টেম থেকে ডেটা আহরণ করার মতো প্রতিবেদন করতে বা একটি রিপোর্টিং সিস্টেম রাখতে চায় যা একাধিক ফ্রন্ট-এন্ড অ্যাপ্লিকেশনগুলি থেকে প্রতিবেদন সরবরাহ করতে পারে। এছাড়াও, আপনি উল্লেখ হিসাবে, আপনি যখন নিয়মিত সমস্যাগুলি মোকাবেলা করতে যাবেন যখন আপনি '

এই পদ্ধতির সুবিধা আছে? আমি অনুমান করি আপনি যুক্তি দিতে পারেন যে অ্যাপ্লিকেশনটির প্রথম সংস্করণটি প্রয়োগ করা বেশ সহজ। এবং এটি বিকাশকারীকে একটি ডাটাবেসের সাথে সঠিকভাবে ইন্টারঅ্যাক্ট করার সাথে সম্পর্কিত যে কোনও কিছুই সম্পূর্ণ উপেক্ষা করতে দেয়। আমি অনেকগুলি ক্ষেত্রে কল্পনা করতে কঠোর চাপ দিয়েছি যেখানে এই সুবিধাগুলি পদ্ধতির থেকে অনেকগুলি ডাউন সাইডকে ছাড়িয়ে যায়।

এই বিশেষ অধ্যাপকের সাথে আপনার কীভাবে আচরণ করা উচিত, এটি একটি পৃথক সমস্যা (এবং এটি সম্ভবত এই ফোরামের আওতার বাইরে)। যদি আপনার অধ্যাপক সত্যিকারের বিশ্বে সক্রিয়ভাবে প্রকল্পগুলি বিকাশ করছেন, তবে সম্ভবত তিনি কোনও শিক্ষার্থীর কাছ থেকে যে কোনও যুক্তির পক্ষে ভয়ানকভাবে গ্রহণযোগ্য হতে যাবেন না যে তার পদ্ধতির মূলত ভুল (এমনকি যদি দৃষ্টিভঙ্গিটি মূলত ভুল হয়)। আপনার প্রকল্পটি অধ্যাপক যেভাবে চান এবং আপনার নিজের (বা অন্য কোনও কোর্সে) ডেটা সংরক্ষণের সঠিক উপায় শেখার জন্য আপনাকে আরও ভাল পরিবেশিত হতে পারে।

Comments

আপনি যা বলেছিলেন, প্লাস আমার দুটি সেন্ট। পুনরায় ব্যবহারযোগ্যতা মডুলারিটি এবং ভাগ করে নেওয়া সম্পর্কে। অবজেক্ট মডেল বিষয়বস্তু ভাগ করে নেওয়ার এবং কোড পুনরায় ব্যবহারের দিকে মনোনিবেশ করে। ডাটাবেস মডেল ডেটা ভাগ করে নেওয়ার ও পুনরায় ব্যবহারের উপর দৃষ্টি নিবদ্ধ করে। কোনও মডেলই সম্পূর্ণ মরোনিক নয়। কোনও মডেলই পরিপূর্ণতা নয়। এবং দু'জনের মধ্যে পুনর্মিলন করা খুব কঠিন।

— ওয়াল্টার মিট্টি

আমি এটির সাথে একমত, তবে আমি কোনও অধ্যাপককে কিছু শেখানো এবং এটির মুখোমুখি না হয়ে এটিই ভাল উপায় বলে দেখে ঘৃণা করি। অন্য যে সমস্ত দরিদ্র শিক্ষার্থীর ক্ষেত্রে এটি কী সঠিক ক্লাস যা ভেবে বাস্তব জগতে প্রবেশ করবে?

— কেভিন

অবশ্যই। এই সূত্রটি ডেটা বলে ভান করে এমন বস্তুর পরিমাণে। এবং এগুলি ডেটা, তবে খুব দরকারী ডেটা নয়।

— ওয়াল্টার মিট্টি

আপনি আপনার অ্যাপ্লিকেশনটির v2 প্রকাশ করতে চাইলেই সুবিধাটি প্রায় সর্বদা নিশ্চিহ্ন হয়ে যায়।

— অ্যান্ডি

Answer 3

এমন কিছু পরিস্থিতি রয়েছে যেখানে এই ধরণের ডিজাইনটি বোধগম্য, আপনার প্রকল্পগুলি কী এবং কীভাবে এটি ব্যবহার করা হয় তা বর্ণনা না করেই এটি উপযুক্ত কিনা তা বলা শক্ত।

আপনি ডিএলবিএ সংরক্ষণ করলে আপনার ডিবিএ আপনাকে ঘৃণা করতে পারে, তবে অনেক পরিস্থিতিতে কেবলমাত্র অন্য বিকল্প হ'ল টেবিলগুলি সত্তা-বৈশিষ্ট্য-মানে পরিণত করা, যা ডিবিএ থেকে আরও ঘৃণা পায়। অন্য বিকল্পটি হ'ল একটি সম্পর্কহীন ডাটাবেসগুলি, সাধারণত অবজেক্ট-ভিত্তিক বা অভিধান ভিত্তিক ডাটাবেস বা একটি নথিভিত্তিক ডাটাবেস ব্যবহার করা, যা কিছু ডিবিএ, বিশেষত যারা কেবলমাত্র সম্পর্কযুক্ত জানেন, আরও বেশি আবেগের সাথে ঘৃণা করে। যদিও আপেক্ষিক ডাটাবেসের সাথে সম্পর্কিত বিষয়গুলির নিজস্ব সমস্যা রয়েছে তবে অবশ্যই এটি হতে পারে যে অবজেক্ট সংরক্ষণ করার জন্য অবজেক্ট ডাটাবেস ব্যবহার করা অন্যান্য সমস্যাগুলি উন্মোচিত করতে পারে যা আপনি রিলেশনাল সিস্টেমে সহজেই সমাধান করতে সক্ষম হয়েছিলেন।

আমি যা ভেবে দেখিনি এটি করার কিছু সুবিধা আছে?

সিরিয়ালযুক্ত অবজেক্ট সংরক্ষণ করার অর্থ আপনি স্কেমাবিহীন ডেটা সংরক্ষণ করতে পারবেন (নোট করুন যে নাম সত্ত্বেও স্কিমহলেস বলতে সাধারণত বোঝায় না যে বাস্তবে কোনও স্কিমা নেই, বরং কেবল অন্তর্নিহিত স্কিমা রয়েছে)। অনেকগুলি সমস্যাযুক্ত ডোমেন রয়েছে যেখানে আপনি সম্ভবত উন্নয়নের সময়ে স্কিমাটি সংজ্ঞায়িত করতে পারবেন না এবং whereতিহ্যবাহী রিলেশনাল ডাটাবেস ডিজাইনের অনুসরণ করার অর্থ হ'ল প্রতি অন্য সপ্তাহে আপনাকে ডাটাবেসের স্কিমাটি পরিবর্তন করতে হবে, বা আপনার কোনও টেবিল দিয়ে শেষ করা উচিত ৮০% কলাম যা 80% অব্যবহৃত থাকে বা শত শত বিভিন্ন টেবিলগুলি সত্যই একই ডেটা সংরক্ষণ করতে পারে যার মধ্যে কোনওটিই ভাল ডিজাইনের ইঙ্গিত দেয় না। এই ইস্যুটির মূলটি সাধারণত কারণ আপনি একটি সম্পর্কযুক্ত ডেটাবেজে কোনও সম্পর্কহীন সমস্যা ডোমেনকে জোর করে ফিরিয়ে আনছেন।

অবশ্যই, অনেকগুলি প্রকল্প রয়েছে যেখানে লোকেরা মনে করে যে তাদের EAV, স্কিমহীন বা ব্লব স্টোরটি ব্যবহার করা দরকার যা অহেতুকভাবে পরিণত হয় যা এড়ানো যায় এমন ব্যথা হতে পারে। আপনার প্রফেসরের সাথে তাঁর যুক্তি কী তা অবশ্যই আপনার আলোচনা করা উচিত এবং আপনার নিজের যুক্তি সরবরাহ করা উচিত; যুক্তি শুনুন, এবং প্রস্তুত থাকুন যে আপনি তাঁর সাথে একমত হতে পারেন, না, সম্ভবত তিনি ভুল।

Answer 4

আমি এটি আগেও করেছি - এটি নির্দিষ্ট পরিস্থিতিতে একটি দরকারী কৌশল তবে ব্যবহৃত সিরিয়ালাইজেশন ফর্ম্যাটের উপর নির্ভর করে। আমি যদি এটি করি তবে আমি নিশ্চিত হয়েছি যে আমি একটি সিরিয়ালাইজেশন ফর্ম্যাট ব্যবহার করেছি যা আমাকে আমার মডেল (যেমন এক্সএমএল) এর পুরানো সংস্করণগুলি ডি-সিরিয়াল করার অনুমতি দেয়।

আমি সাধারণত এটি এমন পরিস্থিতিতে ব্যবহার করতাম যেখানে ডেটা ফর্ম্যাটটির ফলে কোনও জটিল রিলেশনাল মডেল তৈরি হয় যা কোনও সুবিধা দেয় না (উদাহরণস্বরূপ যখন ব্যবসায়ের জন্য কোনও ফিল্টারিং ইত্যাদির প্রয়োজন হয় না ...) এবং আমি ইতিমধ্যে একটি ডাটাবেস ব্যবহার করছি (এর জন্য অন্যান্য সম্পর্কিত তথ্য)। এরকম একটি কেস ছিল এমন একটি অ্যাপ্লিকেশন যা ব্যবহারকারীদের কাছে প্রশ্ন ছিল - রিলেশনাল মডেলটিতে শর্তাবলী, নেস্টেড শর্তাদি (ওআর / এবং ইত্যাদি ...), বাছাইয়ের বিকল্প ইত্যাদি জিনিস সংরক্ষণের জন্য কয়েকটি টেবিল ছিল had এটি বেশ জটিল ছিল এবং তাই যখন আমাদের একটি নতুন বৈশিষ্ট্য যুক্ত করার দরকার ছিল যা ডাটাবেসে পরিবর্তন দরকার হয়েছিল আমি পুরো বিষয়টিকে একক টেবিলের সাথে প্রশ্নের পরিবর্তে সিরিয়ালযুক্ত ব্লব দিয়ে অন্য বিকল্পগুলির প্রতিনিধিত্ব করে প্রতিস্থাপন করেছি।

অন্য কেসটি এমন একটি সিস্টেম ছিল যা বিভিন্ন "কাজ" প্রক্রিয়া করে। বিভিন্ন ধরণের কাজ ছিল এবং প্রতিটি কাজের বিভিন্ন পরামিতি ছিল, সেই পরামিতিগুলির উপর ভিত্তি করে কোনও ব্যবসায়ের প্রয়োজনীয়তা / ফিল্টার জব অনুসন্ধান করতে সক্ষম হবেনা। এটিকে রিলেশনাল ডাটাবেস হিসাবে সংরক্ষণ করার জন্য কমপক্ষে প্রতিটি কাজের ক্ষেত্রে কমপক্ষে 1 টি নতুন টেবিলের প্রয়োজন হবে, যাতে নতুন কাজের ধরণের যুক্ত করতে অসুবিধা হয়। পরিবর্তে প্যারামিটারগুলি ডাটাবেজে একটি ব্লব হিসাবে সংরক্ষণ করা হয় - প্রতিটি কাজের ধরণ সিরিয়ালাইজেশন এবং নিজস্ব প্যারামিটারগুলি ডি-সিরিয়ালাইজ করার জন্য দায়ী।

এটি প্রায়শই নয় আপনি এই জাতীয় পরিস্থিতিগুলি দেখতে পাবেন, তবে এখন এবং পরে উপরের ফসলের মতো পরিস্থিতি যেখানে ব্লব ডেটা সিরিয়ালাইজ করা আপনাকে প্রচেষ্টার বোঝা বাঁচায়, আপনার অ্যাপ্লিকেশনটিকে আরও রক্ষণাবেক্ষণ করে তোলে এবং এর কোনও প্রকৃত অসুবিধা নেই।

Answer 5

জাস্টিন কেভ সঠিক যে এটি অনর্থক ডেটা হতে পারে, কিন্তু আপনি আপনার ডাটাবেসটি কীভাবে ডিজাইন করেন তার উপর এটি নির্ভর করে।

একটি পুরো বস্তুকে একটি ফোঁড়ায় সিরিয়ালাইজ করার পদ্ধতির পক্ষে এতোটা আপত্তিজনক নয় যেহেতু এখানকার বেশিরভাগ লোক মনে করে think প্রকৃতপক্ষে, কিছু অ্যাপ্লিকেশনগুলির জন্য, এটি আপনি করতে পারেন সেরা ডিজাইন হতে পারে, আমি এখানে যেমন ব্যাখ্যা করেছি: /programming//a/12644223/1121352 ।

প্রকৃতপক্ষে, কোনও বস্তুর ক্রমিকায়নের ফলে কমপক্ষে দুটি উপকার হয়:

1- প্রতিবন্ধকতা অমিল হ্রাস : কিছু জাভা প্রকারগুলি এসকিউএল-তে কেবল উপলভ্য নয়, বিশেষত যদি আপনি প্রচুর ক্লাস এবং কাস্টম প্রকার ব্যবহার করেন, সুতরাং জাভা অবজেক্টগুলি থেকে এসকিউএলকে সামনে এবং পিছনে রূপান্তর করা একটি বিরাট ঝামেলা হতে পারে এবং এমনকি দ্ব্যর্থতা তৈরি করতে পারে।

2- আপনার স্কিমা আরও নমনীয়তা । প্রকৃতপক্ষে, একই কাঠামো ভাগ করে নেওয়ার জন্য রিলেশনাল স্কিমাগুলি সত্যই দুর্দান্ত but তবে একক শ্রেণীর মধ্যে যদি আপনার কিছু বস্তুর রানটাইমের সময়কালের উপর নির্ভর করে বিভিন্ন বৈশিষ্ট্য থাকতে পারে তবে রিলেশনাল স্কিমাগুলি আপনার কর্মপ্রবাহকে উল্লেখযোগ্যভাবে বাধা দিতে পারে।

সুতরাং, অবশ্যই এই পদ্ধতির সুবিধাগুলি রয়েছে (কমপক্ষে এই দুটি, তবে অবশ্যই অন্যরা উদ্ধৃত করি নি), তবে অবশ্যই প্রদানের জন্য প্রচুর ব্যয়টি হ'ল আপনি প্রায় সমস্ত রিলেশনাল স্কিমার সুবিধা হারাবেন।

তবে আপনি যদি সাবধানে আপনার ডাটাবেসটি ডিজাইন করেন তবে আপনি উভয় বিশ্বের সেরাটি পেতে পারেন: আপনি এখনও প্রতিটি বস্তুর জন্য স্বতন্ত্র বৈশিষ্ট্যগুলি ব্যবহার করে একটি রিলেশনাল স্কিমা (অর্থাত্: অনন্য কী কলাম) সেট করতে পারেন এবং তারপরে অবজেক্টটি ব্লবটিতে সংরক্ষণ করুন । এইভাবে, আপনি তখনও আপনার অবজেক্টের বৈশিষ্ট্য দ্বারা নির্ধারিত কিছু অনন্য শনাক্তকারীকে দেওয়া আপনার অবজেক্টের দ্রুত পুনরুদ্ধার নিশ্চিত করতে পারবেন, রিডানডেন্সি হ্রাস করবেন, যখন আপনি প্রতিবন্ধকতা অমিলকে নির্মূল করেন এবং জাভা অবজেক্টগুলির সম্পূর্ণ নমনীয়তা বজায় রাখেন।

পার্শ্ব নোট হিসাবে, কিছু ডিবি নির্মাতারা রিলেশনাল এবং অবজেক্ট মডেলগুলিকে একসাথে পোস্ট করার জন্য কয়েকটি প্রচেষ্টা করেছেন যেমন পোস্টএসকিউএল এবং পোস্টগ্রিসকিউএল তে জেএসএন ডেটাটাইপ যাতে আপনি সরাসরি কোনও রিলেশনাল কলামের মতো জেএসএন প্রসেস করতে পারেন এবং এসকিউএল 3 এবং ওকিউএল (অবজেক্ট) ক্যোরি ল্যাঙ্গুয়েজ) এসকিউএলে (সীমিত) অবজেক্ট সমর্থন যোগ করতে to

শেষ পর্যন্ত, এটি সম্পর্কিত নকশা এবং আপেক্ষিক মডেল এবং অবজেক্ট মডেলের মধ্যে সমঝোতার বিষয়।

/ মন্তব্যগুলি পড়ার পরে সম্পাদনা করুন : অবশ্যই, যদি আপনার ডেটা অবশ্যই অনুসন্ধানযোগ্য ("অনুসন্ধানযোগ্য") হতে পারে তবে আপনার ডেটাটি একটি ব্লাব হিসাবে সংরক্ষণ করা উচিত নয়। তবে যদি আপনার ডেটাগুলির কিছু অংশ অনুসন্ধানযোগ্য নয় , বরং কোনও ধরণের মেটা-ডেটা বোঝানো হয় , তবে এই ডেটা অংশটি একটি ব্লকের অভ্যন্তরে কোনও বস্তু হিসাবে সংরক্ষণ করা ভাল সমাধান হতে পারে, বিশেষত যদি এই মেটা-ডেটার একটি নমনীয় কাঠামো থাকে এবং অবজেক্ট থেকে অবজেক্টে পরিবর্তন করতে পারে।

Answer 6

অতীতে আমি কখন এটি করেছি তার একটি ব্যবহারিক উদাহরণ দেওয়া যাক।

আমাদের কাছে একটি ডাটাবেস রয়েছে যাতে মুলি-ব্যবহারকারী অ্যাপ্লিকেশনটির জন্য সমস্ত ডেটা থাকে; ডাটাবেসটিতে তাদের অ্যাক্সেস অধিকার সহ ব্যবহারকারীদের একটি সারণীও রয়েছে। প্রত্যাশা অনুযায়ী এই সমস্ত ডেটা স্বাভাবিক করা হয়েছে।

তারপরে আমাদের একটি অনুরোধ রয়েছে যে অ্যাপ্লিকেশনটি কোনও ব্যবহারকারী কী উইন্ডো খোলা ছিল এবং তারা কী করছে তা মনে রাখে, যাতে পরের দিন সকালে ব্যবহারকারী যখন কাজ শুরু করে তখন এটি রাষ্ট্রটি পুনরুদ্ধার করতে পারে।

• প্রথমত যদি এটি কখনও কখনও ব্যর্থ হয় তবে তা কি অনর্থক নয়

  • উদাহরণস্বরূপ, যদি কেউ প্রথমবার অ্যাপ্লিকেশনটির নতুন সংস্করণ ব্যবহার করে তবে এটি তাদের যে উইন্ডোগুলি খোলা ছিল তা ভুলে যায়, তাই কি…

• সুতরাং যদি বস্তুগুলি পরিবর্তন হয় তবে 100% ফ্যালব্যাক রয়েছে এবং তাই আমরা ব্লকটি পড়তে পারি না।

• অ্যাক্সেস নিয়ন্ত্রণ, ব্যাকআপ নেওয়া ইত্যাদির সাথে ইতিমধ্যে আমাদের একটি কেন্দ্রীয় ডাটাবেস রয়েছে
• ফাইলগুলিতে ডেটা সংরক্ষণের ব্যয় বেশি, কারণ সমস্ত ব্যবহারকারী মেশিনের অ্যাক্সেস রয়েছে এমন ফাইল সার্ভারের মধ্যে ফাইলগুলি রাখতে হবে বা এই ফাইলগুলি পড়তে একটি এপিআই লিখতে হবে।

অন্য সময় , আমাদের কাছে একটি অ্যাপ্লিকেশন ছিল যা প্রচুর দীর্ঘমেয়াদি গণনা করেছিল এবং ব্যবহারকারীরা বিদ্যুৎ কাটা ইত্যাদি থাকলে শেষ জানার ভাল পয়েন্টটি থেকে গণনাগুলি পুনরায় চালু করতে সক্ষম হতে চান, ইত্যাদি কোনও উপায় নেই যে এর আলাদা সংস্করণ রয়েছে version অ্যাপ্লিকেশনগুলি গণনা পুনরায় আরম্ভ করার আশা করা যেতে পারে, এবং প্রচুর পরিমাণে অবজেক্টের প্রয়োজন ছিল যেগুলি সংরক্ষণের প্রয়োজন ছিল, ডেটা স্বাভাবিককরণ ব্যয়বহুল হত।

ডেটাবেস ইতিমধ্যে স্থানে রয়েছে এবং ভাল-সংজ্ঞায়িত নরমালাইজড অ্যাপ্লিকেশন ডেটার জন্য ব্যবহার করা হচ্ছে এবং ব্লগগুলি সংরক্ষণের জন্য এটি ব্যবহার না করার কোনও সত্য কারণ নেই বলে আমরা বুদ্ধিমান এবং দ্রুত বিকল্পটি গ্রহণ করেছি।

Answer 7

একটি খুব গুরুত্বপূর্ণ ফ্যাক্টর: জাভা সিরিয়ালাইজেশন (এটি সম্পন্ন করে এমনটি সম্পন্ন করা হয়েছে Serializable) নিজেই খুব খারাপ ফর্ম্যাট, সুতরাং আপনাকে স্থায়ী অবজেক্ট স্টোরেজ করার জন্য সত্যই এটি ব্যবহার করা উচিত নয়।

জাভা সিরিয়ালাইজেশন এর ত্রুটিগুলি অন্তর্ভুক্ত:

• অন্যান্য ভাষা থেকে ডেটা সত্যই পঠনযোগ্য নয়।
• সিরিয়ালযুক্ত বস্তুর সামনের সামঞ্জস্যতা বজায় রাখা খুব সহজ নয়, এটি হল: আপনি যদি শ্রেণিতে ক্ষেত্রগুলি যুক্ত (বা অপসারণ) করেন তবে শ্রেণীর পূর্ববর্তী সংস্করণ দ্বারা নির্মিত বস্তুগুলি পড়া এত সহজ নয়।
• এটি এত দ্রুত নয় (তবে আপনার মাইলেজটি ভিন্ন হতে পারে)

সুতরাং আপনি যদি অন্য কোনও সিরিয়ালাইজেশন ফর্ম্যাট ব্যবহার করেন তবে আপনি একটি দুর্দান্ত কী-ভ্যালু স্টোর পাবেন, যদি আপনি জাভা সিরিয়ালাইজেশন ব্যবহার করেন তবে আপনি গোলযোগ পাবেন।

Comments

উত্তরের তথ্যগুলি কেবল মিথ্যা: 1) ফর্ম্যাটটি একটি বিস্তৃত স্পেসিফিকেশন দ্বারা আবৃত; 2) ক্ষেত্রগুলি যুক্ত করা মোটেই কোনও সমস্যা নয়, ফর্ম্যাটটি খুব নমনীয়; 3) গতি প্রকৃত ডেটার উপর নির্ভর করে, তবে জেএসএন বা এক্সএমএলের মতো ফর্ম্যাটগুলির সাথে তুলনাযোগ্য (কখনও কখনও দ্রুত, কখনও কখনও ধীর) ara মূলত, পুরো উত্তরটি ভুল, এক লাইন বাদে: "ডেটা অন্য ভাষা থেকে সত্যই পঠনযোগ্য নয়"।

— fdreger

এগুলি বাদে 1)ভুল উত্তরটি আইএমও বৈধ। যদি আপনি ডেসেরিয়ালিসটনের উপর নিয়ন্ত্রণ রাখতে চান - যা আপনি ক্ষেত্রগুলি যুক্ত / মুছে ফেলার সময় প্রয়োজন (এবং বিশেষত চূড়ান্ত ক্ষেত্রগুলি রাখার সময়) ইন্টারফেসগুলি জটিল বলে মনে হচ্ছে এবং আপনাকে আরও পদ্ধতিগুলি ওভাররাইড করতে হবে যা এটি প্রয়োজনীয় readObjectএবং readReplaceচূড়ান্ত ক্ষেত্রগুলির জন্য)।

— জেবি।

আপনি ভুল, ক্ষেত্রগুলি যুক্ত এবং সরানোর জন্য কোনও পদ্ধতি লেখার প্রয়োজন নেই। চূড়ান্ত ক্ষেত্রগুলি হিসাবে - আপনার মূল উত্তরটি সেগুলির মোটেও উল্লেখ করে না, এবং যদি এটি হয় তবে তা অপ্রাসঙ্গিক হবে (সমস্যাটি অন্য সমস্ত ফর্ম্যাটের ক্ষেত্রে সাধারণ হবে)। অবশেষে, "এটি তাত্পর্যপূর্ণ নয় (তবে আপনার মাইলেজটি বিভিন্ন হতে পারে)" বলার অর্থ কিছু নেই। আপনার একটি মাত্র সত্য আছে: অন্য ভাষা সম্পর্কে। এটি কোনও "গোলযোগ" বলার জন্য খুব দুর্বল ভিত্তি।

— fdreger

ক্ষেত্রগুলি যুক্ত করার জন্য আপনাকে কোনও পদ্ধতি লেখার প্রয়োজন নেই, তবে আপনি কীভাবে সেগুলি deserialized করা হয় তা প্রভাবিত করতে চান তবে আপনাকে সেই আচরণটি নির্দিষ্ট করতে হবে। আমি বিকশিত অবজেক্ট স্কিমাটির ডিসিরিয়ালাইজেশন নিয়ে কিছু সমস্যা উল্লেখ করার চেষ্টা করব।

— জেবি।

Answer 8

এটি বেশ সুচিন্তিত উত্তর সহ একটি আকর্ষণীয় থ্রেড। সিরিয়ালযুক্ত বস্তুগুলি সংরক্ষণ এবং পুনরুদ্ধার সম্পর্কিত সমস্ত বিষয়গুলির সাথে কথোপকথন না করে আমি মনে করি যে কোনও ডিবিএ দল বা উন্নয়ন দলকে আমি যে উত্তর দিতে পারি তা সরবরাহ করা আকর্ষণীয় হবে:

মূলটি হ'ল বর্তমান এবং ভবিষ্যতের প্রয়োজনীয়তাগুলি পূরণ করা এবং সমাধানটি যতটা সম্ভব সহজ রাখা যাতে ভবিষ্যতের সহায়তা কাজের কাজটি হ্রাস করা যায়। ক্রিয়ামূলক প্রয়োজনীয়তা এবং অ-কার্যকরী প্রয়োজনীয়তা উভয়ই (যেমন: অবকাঠামো এবং ডাটাবেস) অবশ্যই পূরণ করতে হবে। 80/20 নিয়ম মনে রাখবেন। ব্যবসায়ের কাছে অ্যাপটির গুরুত্ব এবং কোন বিকাশের প্রচেষ্টা উপযুক্ত তা বুঝুন tand

ডাটাবেস স্পেস, গতি এবং মেমরি যদি এগুলি সমস্যা না করে তবে তাদের জন্য স্তব্ধ হবেন না।

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

সমাধানটি যদি প্রোটোটাইপ বা প্রারম্ভিক পর্যায়ে / সংস্করণ হতে হয় তবে জিনিসগুলি সহজ রাখার জন্য আরও চাপ দেওয়া দরকার। যতক্ষণ আপনি এটি পরিকল্পনা করছেন ততক্ষণ আপনি ডেটা স্কিমাটি পরে প্রসারিত করতে পারেন।

মনে রাখবেন যে রিলেশনাল ডাটাবেসের অখণ্ডতা বা ধারাবাহিকতা প্রয়োগ করবে না যতক্ষণ না স্কিমা কোনও স্ব-অন্তর্ভুক্ত ব্যবসায়িক ক্ষেত্র এবং ব্যবসায় বিধি কঠোর না হয় covers (উদাহরণস্বরূপ সিরিয়ালাইজড অবজেক্ট প্রশ্নের সমাধান বিধি প্রয়োগের জন্য অভিধান / অ্যান্টোলজির স্টাইলের ভাণ্ডার বিবেচনা করতে পারে)।

সমস্ত রিলেশনাল ডাটাবেসগুলি খাঁটি রিলেশনাল ডাটাবেস স্কিম (যেমন তারা, স্পেসিয়াল, অ-রিলেশনাল ..) ব্যবহার করে না তা বিবেচনা করার মতো বিষয়ও অ্যাপ্লিকেশন প্রশ্নবিদ্ধভাবে রিলেশনাল ডাটাবেসগুলিকে অ-রিলেশনাল স্টোর হিসাবে ব্যবহার করতে পারে। অনেকগুলি মূল ব্যবসায়িক ডাটাবেস এইভাবে কাজ করে।