পৃথক সারি পরিবর্তে এক সারির এক ক্ষেত্রে একাধিক মান সংরক্ষণের সম্ভাব্য সুবিধা

11

আমাদের সর্বশেষ সাপ্তাহিক বৈঠকের সময়, একজন ব্যক্তি যার ডেটাবেস প্রশাসনের কোনও পটভূমি অভিজ্ঞতা নেই এই প্রশ্নটি উত্থাপন করেছে:

"এমন কোনও পরিস্থিতি দেখা যাবে যা বেশ কয়েকটি লাইনের পরিবর্তে ইন-লাইন (স্ট্রিং) ডেটা সংরক্ষণের ন্যায্যতা দেয়?"

আসুন একটি টেবিল ধরে নেওয়া যাক countryStatesযেখানে আমরা কোনও দেশের রাজ্যগুলি সংরক্ষণ করতে চাই; আমি এই উদাহরণের জন্য ইউএসএ ব্যবহার করব এবং অলসতার জন্য সমস্ত রাজ্য তালিকাভুক্ত করব না।

সেখানে আমাদের দুটি কলাম থাকবে; একজন ডাকল Countryএবং অন্যজন ডাকল States। যেমনটি এখানে আলোচনা করা হয়েছে এবং @ শ্রুতজকির উত্তর দ্বারা প্রস্তাবিত , আইএসও 3166-1 আলফা -3PK দ্বারা সংজ্ঞায়িত কোড হবে ।

আমাদের টেবিলটি দেখতে এমন হবে:

+---------+-----------------------+-------------------------------------------------------+
| Country | States                | StateName                                             |
+---------+-----------------------+-------------------------------------------------------+
| USA     | AL, CA, FL,OH, NY, WY | Alabama, California, Florida, Ohio, New York, Wyoming |
+---------+-----------------------+-------------------------------------------------------+

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

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

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

sql-server database-design denormalization

— Human_AfterAll
সূত্র

এখন কল্পনা করুন যে আপনার একটি দ্বিতীয় সারণি, "বিক্রয়" রয়েছে, এতে যে রাজ্য কোডটি বিক্রি হয়েছিল তার সাথে সংঘটিত প্রতিটি বিক্রয় সম্পর্কিত ডেটা রয়েছে। আপনি কীভাবে এমন একটি ক্যোয়ারী লিখবেন যা কলামগুলির সাথে একটি প্রতিবেদন তৈরি করে (স্টেটনাম, টোটাল সেলসমেন্ট)? কঠিন, তাই না?

— zgguy

যথাযথভাবে। আমিও এই মডেলটির সাথে একমত নই। আমরা যে কোনও সময়ে আটকে যাই আমাদের যে কোনও ধরণের ডেটা (বা আপনি চাইলে দরকারী ডেটা) পুনরুদ্ধার করতে হবে।

— মানব_এফটারএল

ভেরিয়েবলগুলি সংরক্ষণ করার একটি সম্ভাব্য দৃশ্য হতে পারে। স্টোর a;b;c, তারপর আপনার স্ট্রিং আপনি পার্স পেতে সামনে শেষ ব্যবহার a, b, c, ফাঁসি উপর এবং বহন তাদের সাথে কিছু কাজ হয়তো ?. অনুভব করুন এটি সেই ফ্যাশনে কিছু নির্দিষ্ট প্রয়োজন অনুসারে উপযুক্ত হতে পারে ... দ্বিতীয় ভাবাতে, না। আপনি সর্বদা আইডি সঞ্চয় করে রাখতে পারেন, আপনার টেবিলগুলিতে যোগদান করতে পারেন এবং এফএ-তে সামগ্রী পাঠাতে

— পারার

সুষ্ঠু হওয়ার জন্য (আমার কাছে কমপক্ষে ;-), আমি অন্য উত্তরে ২-বর্ণের দেশ কোড :-) ব্যবহার করার প্রস্তাব দিয়েছিলাম ।

— সলোমন রুটজকি

2

লক্ষ্য করুন যে "স্টেট স্টেটের নামতে এনথ ক্যারেক্টার সি আছে" এর জন্য স্ট্যাট, এন ও সি কলামের সাথে আলাদা আলাদা টেবিল না রেখে কলামে "আলাবামা" মান সংরক্ষণ করার বিষয়ে কোয়ালিটি নেই। যেহেতু হয় ১। আমরা নামের বা দুটি বর্ণের সম্পর্কে জিজ্ঞাসা করতে চাই না 2. আমরা কোনও ক্রমের সাথে NTH_CHAR (N, S) কল করতে কিছু মনে করি না যদি প্রতিটি সারিতে "স্ট্রিং এস এর Nth অক্ষর" ফিরে আসে তবে যদি আমরা করি । (বনাম যোগ দিন এবং অন্যান্য রিলেশনাল অপারেটর অতিরিক্ত টেবিলের মাধ্যমে এ জাতীয় কিছু সারি মুছে ফেলে।) পূর্ণসংখ্যা এবং এনটিএইচ_ডিজিট (এন, আই) এর জন্য ডিটো। নির্দিষ্ট ডাটাবেসের মধ্যে কী পারস্পরিকভাবে পারমাণবিক হয় তা এটি সর্বদা বিচারের ডাক।

— ফিলিপ্সি

13

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

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

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

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

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

এবং যদি ব্যবসায়ের প্রয়োজনীয়তা সময়ের সাথে সাথে পরিবর্তন হয় এবং আপনার এই আইটেমগুলির অতিরিক্ত বৈশিষ্ট্যগুলি ট্র্যাক করতে হবে তবে কী হবে? "রাজ্যের" শর্তাবলী, রাজধানী, বা জনসংখ্যা, বা একটি বাছাই-অর্ডার, বা অন্য কিছু সম্পর্কে? সারি হিসাবে সঠিকভাবে সঞ্চিত আপনি অতিরিক্ত বৈশিষ্ট্যের জন্য আরও কলাম যুক্ত করতে পারেন। অবশ্যই, আপনার একাধিক স্তরের পার্সেবল ডেটা থাকতে পারে, |StateCode,Capital,Population |StateCode,Capital,Populate|...তবে আশা করি যে কেউ সমস্যাটি দ্রুত নিয়ন্ত্রণের বাইরে চলেছে তা দেখতে পাবে। অবশ্যই, এই নির্দিষ্ট সমস্যাটি বরং এক্সএমএল এবং জেএসএন ফর্ম্যাটগুলির সাথে সহজেই মোকাবেলা করা হয় এবং এটি উপরে বর্ণিত হিসাবে তাদের মান। তবে মডেলিংয়ের প্রাথমিক উপায় হিসাবে তাদের যে কোনও একটিই আলাদা সারিগুলিতে বিচ্ছিন্ন ক্ষেত্রগুলি ব্যবহার করার মতো দক্ষ হবে না বলে আপনার এখনও খুব ভাল কারণ প্রয়োজন ।

— সলোমন রুটজকি
সূত্র

9

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

OutputType   OutputHeader
PersonalData Name|Address|City|State|Zip
JobInfo      Name|JobName|JobTitle

মূলত এটি দেখে মনে হচ্ছে এটি একটি সীমিত তালিকা। এবং একভাবে এটি ছিল। কিন্তু আমাদের উদ্দেশ্যে এটি ছিল একক দীর্ঘ স্ট্রিং।

এটাই এখানে কৌশল। আপনি যদি তালিকাটি বিশ্লেষণের পরিকল্পনা না করেন তবে তালিকাটি সংরক্ষণের পক্ষে মূল্যবান। তবে আপনাকে যদি তালিকাটি বিশ্লেষণের প্রয়োজন হয় এমনকি প্রয়োজন হয় তবে এটি আলাদা করে আলাদা আলাদা সারিতে সংরক্ষণ করার জন্য অতিরিক্ত স্থান ও সময় মূল্য।

— কেনেথ ফিশার
সূত্র

1

আমি এটি বরং একটি ছোট টেবিল দিয়ে একবার ব্যবহার করেছি, উদাহরণস্বরূপ:

CREATE TABLE t1 (
  ID number,
  some_feature   varchar2(100),
  valid_channels  varchar2(100));

CREATE TABLE channel_def (
  channel varchar2(100));

এবং তারপর মান সংরক্ষণ CRM,SMS,SELF-CAREমধ্যে valid_channel।

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

তবে সাধারণভাবে আমি এড়ানো, এটি 3 এনএফ নয়।

আমি বর্তমানে যে জায়গাতে কাজ করি সেখানে পুরো জায়গায় জুড়ে কয়েক ডজন কলাম রয়েছে। তাদের সমর্থনযোগ্যতা হ'ল এটি তাদের প্রশ্নগুলি আরও সহজ করে তোলে: লিঙ্কিং টেবিলটি ব্যবহার করে তিনটি টেবিলের পরিবর্তে তারা সংজ্ঞা টেবিলটি ব্যবহার করে সরাসরি যেতে পারবেন LIKE। যেমন

SELECT * 
  FROM t1 
 INNER JOIN channel_def cd
    ON ','||t1.valid_channels||',' LIKE '%,'||cd.channel||',%';

ভয়াবহ + ওরাকলে এটি সূচনার ব্যবহারটি অক্ষম করে কারণ এটি শুরু হয়েছিল '%,'।

— Robotron
সূত্র

কোনটি ধীর হবে: LIKEবা একটি সাধারণ যোগদান?

— হিউম্যান_এফটারল সব

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

— রোবোট্রন

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

— সলোমন রুটজকি

1

@ হুমান_এর পরে আমি সবই বলব যে এই মডেলিংয়ের সিদ্ধান্তটি অভিজ্ঞতা এবং জ্ঞানের অভাব (এবং কখনও কখনও অলসতা) দ্বারা উত্পন্ন হয়েছিল । একটি অতিরিক্ত যোগে যা কিছু সংরক্ষিত তা হ'ল তবে যা বলি দেওয়া হয় তা হ'ল বিদেশী কী করার ক্ষমতা যা পুরোপুরি বোগাস ডেটা পেতে বাধা দেয় (এমনকি যদি তা LIKEদফাটির সাথে মেলে না এবং বিজোড় ফলাফল প্রকাশ না করে, তবুও এটি অন্যান্য সমস্যার কারণ হতে পারে বা কমপক্ষে ডিবাগিং আরও শক্ত / দীর্ঘ করুন)। valid_channelsক্ষেত্রটি আপডেট করা আরও জটিল করে তোলে । এই শুধু নেই বলতে চাই যে এই কাজ করে না নয়, ভাল এরকম কারণ।

— সলোমন রুটজকি

"অভিজ্ঞতার অভাব" - সবচেয়ে খারাপটি হ'ল এই নির্দিষ্ট নকশার সিদ্ধান্তটি সিনিয়র স্টাফ সদস্য দ্বারা চাপিয়ে দেওয়া হয়েছিল ...

— রোবট্রন

1

এটি এখানে এসই করা হয়েছিল। মার্ক গ্র্যাভেল যেমন লিখেছেন :

... কিছু চিন্তা ও বিবেচনা করার পরে, আমরা একটি পাইপ (বার) সীমানা / অগ্রবর্তী পাইপ সহ প্রাকৃতিক উপস্থাপনার উপর স্থির হয়েছি, সুতরাং "। নেট সি #" সহজভাবে "|। নেট | সি # |" হয়ে যায়। এর গুণাবলী রয়েছে:

পার্স করা খুব সহজ

বাল্ক আপডেট এবং ট্যাগগুলি অপসারণ একটি সহজ প্রতিস্থাপন (পাইপ সহ মিড-ট্যাগ ম্যাচগুলি প্রতিস্থাপন এড়াতে) দিয়ে সম্পন্ন করা যেতে পারে

...

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

তারা সম্ভবত কাজের পরিমাণ এবং পারফরম্যান্স উভয়ের কারণে জিনিসটিকে সম্পূর্ণরূপে স্বাভাবিক করেনি ize

— ইউজিন রায়বতসেভ
সূত্র

0

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

এই উদাহরণটি দেখুন:

http://aboutsqlserver.com/2013/07/22/clr-vs-t-sql-performance-considerations/

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

— দংশন
সূত্র

2

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

— সলোমন রুটজকি

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

— স্টিং

0

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

আমাদের পূর্বের ভূমিকায় একই রকম নকশার পছন্দ ছিল যার মাধ্যমে আর্কিটেক্ট টিম একটি "ডেটা" ক্ষেত্র রাখতে চেয়েছিল যা সীমানাযুক্ত হয়ে পরে বাইনারিতে রূপান্তরিত হয়েছিল। আমরা কয়েকটি কারণে শেষ পর্যন্ত সেই পথে নামিনি।

যদি আপনাকে এই ধরণের ডেটাতে যোগ দিতে হয় তবে এটি হবে এক কুরুচিপূর্ণ অভিজ্ঞতা। স্ট্রিংয়ের একক উপাদান আপডেট করাও অপ্রীতিকর হবে।

— ক্লাইভ স্ট্রং
সূত্র