ডাটাবেসে জেএসএন সংরক্ষণ করে বনাম প্রতিটি কীটির জন্য একটি নতুন কলাম রয়েছে


213

আমি আমার টেবিলে ব্যবহারকারীর সম্পর্কিত ডেটা সংরক্ষণের জন্য নিম্নলিখিত মডেলটি বাস্তবায়ন করছি - আমার কাছে দুটি কলাম রয়েছে - uid(প্রাথমিক কী) এবং একটি metaকলাম যা জেএসওএন ফর্ম্যাটে ব্যবহারকারী সম্পর্কে অন্যান্য ডেটা সঞ্চয় করে।

 uid   | meta
--------------------------------------------------
 1     | {name:['foo'], 
       |  emailid:['foo@bar.com','bar@foo.com']}
--------------------------------------------------
 2     | {name:['sann'], 
       |  emailid:['sann@bar.com','sann@foo.com']}
--------------------------------------------------

এই একটি ভাল উপায় আছে কি (কর্মক্ষমতা ভিত্তিক, নকশা-অনুযায়ী) এক-কলাম-প্রতি-সম্পত্তি মডেল, যেখানে টেবিল মত অনেক কলাম থাকবে চেয়ে uid, name, emailid

প্রথম মডেলটি সম্পর্কে আমি যা পছন্দ করি তা হ'ল আপনি সর্বাধিক ক্ষেত্র যুক্ত করতে পারেন কোনও সীমাবদ্ধতা নেই।

এছাড়াও, আমি ভাবছিলাম, এখন আমি প্রথম মডেলটি প্রয়োগ করেছি। আমি কীভাবে এটিতে কোনও ক্যোয়ারী করব, যেমন, আমি 'ফু' এর মতো নামী সমস্ত ব্যবহারকারীকে আনতে চাই?

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


হালনাগাদ

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


40
দুর্দান্ত প্রশ্ন! কিন্তু কেন আপনি একটি উত্তর গ্রহণ করেন নি? যা অন্যান্য ব্যবহারকারীদের (আমার মতো) সহায়তা করবে
সাহার Ch

উত্তর:


198

আপডেট 4 জুন 2017

এই প্রশ্ন / উত্তরটি কিছু জনপ্রিয়তা পেয়েছে তা দেখে, আমি বুঝতে পেরেছিলাম এটি একটি আপডেটের জন্য মূল্যবান।

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

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

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

  • কোনও পরিচিতির জন্য ইমেল ঠিকানা এবং ফোন নম্বরগুলি সংরক্ষণ করার সময়, যেখানে কোনও JSON অ্যারেতে মান হিসাবে সংরক্ষণ করা একাধিক পৃথক পৃথক টেবিলের চেয়ে পরিচালনা করা অনেক সহজ where

  • স্বেচ্ছাসেবক কী / মান ব্যবহারকারীর পছন্দসমূহ সংরক্ষণ করা (যেখানে মানটি বুলিয়ান, পাঠ্য বা সংখ্যাসূচক হতে পারে এবং আপনি বিভিন্ন ডেটা ধরণের জন্য পৃথক কলাম রাখতে চান না)

  • কনফিগারেশন ডেটা সংরক্ষণ করে যার কোনও সংজ্ঞায়িত স্কিমা নেই (যদি আপনি জ্যাপিয়ার তৈরি করছেন, বা আইএফটিটিটি এবং প্রতিটি সংহতকরণের জন্য কনফিগারেশন ডেটা সংরক্ষণ করার প্রয়োজন আছে)

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

আসল উত্তর

যদি আপনি সত্যিই কোনও সীমাবদ্ধতা (স্বেচ্ছাসেবী নথির আকার সীমা ব্যতীত) যতগুলি ক্ষেত্র চান ঠিক তেমন যোগ করতে সক্ষম হতে চান, তবে মঙ্গোডিবি-র মতো নোএসকিউএল সমাধান বিবেচনা করুন।

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

প্রাসঙ্গিক ডাটাবেসগুলি ইনডেক্স করার সময় ডেটা ধরণের সুবিধা গ্রহণ করে এবং একটি সাধারণ কাঠামো দিয়ে প্রয়োগ করার উদ্দেশ্যে ।

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


1
যেহেতু খুব বেশি কলাম নেই যার উপরে আমার অনুসন্ধান করা দরকার, তাই উভয় মডেল ব্যবহার করা কি বুদ্ধিমানের কাজ? আমার যে ডেটা সন্ধান করতে হবে তার জন্য প্রতি কলামে কী এবং অন্যদের জন্য জেএসওন (একই মাইএসকিউএল ডাটাবেসে)?
শুক্লস্নিধ্য্যা

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

5
" virtually impossible to query" - আজ পিএসএইচএল আপনাকে এর জেসনব
টেড

1
@ সত্য। তবে, এই উত্তরটি লেখার সময় যা সত্যিই পাওয়া যায় নি। এছাড়াও, এই প্রশ্নটি মাইএসকিউএলকে উল্লেখ করে যেখানে সামর্থ্য উপস্থিত নেই।
কলিন এম

3
@ কলিনম, হ্যাঁ, আমি বুঝতে পারি যে আমার মন্তব্যটি আপনার পোস্টের চেয়ে 3 বছর কম। আমি এটি ছেড়ে যাওয়ার কারণ এটি অন্যের জন্য সহায়ক এবং সিদ্ধান্ত পরিবর্তন হতে পারে। সত্য হতে পারে, কিন্তু আছে: মাইএসকিউএল রেফারেন্স হিসাবে "For relational databases"= পি আপনার উত্তর
টেড

69

বেশিরভাগ জিনিসের মতো "এটি নির্ভর করে"। এটি কলাম বা জেএসএনে ডেটা সঞ্চয় করা নিজের মধ্যে সঠিক বা ভুল / ভাল বা খারাপ নয়। এটি এর পরে আপনার কী করা দরকার তার উপর নির্ভর করে। এই ডেটা অ্যাক্সেস করার জন্য আপনার পূর্বাভাসের উপায় কী? আপনার কি অন্যান্য ডেটা রেফারেন্সের প্রয়োজন হবে?

অন্যান্য লোকেরা প্রযুক্তিগত বাণিজ্য বন্ধ কী তা বেশ ভাল উত্তর দিয়েছেন।

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

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

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

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

JSON ক্ষেত্রগুলি এটি এবং এর সামান্য টুকরাগুলির জন্য জাঙ্ক ড্রয়ারে পরিণত হয়েছিল। ডাটাবেস স্তরে কোনও ডেটা বৈধতা নেই, নথির মধ্যে কোনও ধারাবাহিকতা বা অখণ্ডতা নেই। এটি responsibilityতিহ্যগত কলামগুলি থেকে হার্ড টাইপ এবং সীমাবদ্ধতা পরীক্ষা করার পরিবর্তে সেই সমস্ত দায়বদ্ধতাটিকে অ্যাপে চাপিয়ে দিয়েছে।

পিছনে তাকাতে, জেএসএন আমাদের খুব দ্রুত পুনরাবৃত্তি করতে এবং দরজা থেকে কিছু বের করার অনুমতি দেয়। ইহা অনেক ভাল ছিল. তবে আমরা একটি নির্দিষ্ট দলের আকারে পৌঁছানোর পরে এটি নমনীয়তা আমাদের প্রযুক্তিগত debtণের দীর্ঘ দড়ি দিয়ে ঝুলতে দেয় যা পরবর্তী বৈশিষ্ট্য বিবর্তনের অগ্রগতি কমিয়ে দেয়। সতর্কতার সাথে ব্যবহার করুন.

আপনার ডেটার প্রকৃতি কী তা সম্পর্কে দীর্ঘ এবং কঠোর চিন্তা করুন। এটি আপনার অ্যাপের ভিত্তি। সময়ের সাথে সাথে কীভাবে ডেটা ব্যবহার করা হবে। এবং কীভাবে এটি পরিবর্তনের সম্ভাবনা রয়েছে?


7
"এটি নমনীয়তা আমাদের প্রযুক্তিগত debtণের দীর্ঘ দড়ি দিয়ে নিজেকে ঝুলতে দেয়" খুব সুন্দর রূপক!
এন্টোইন গ্যালিক্স

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

27

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

এটি সীমাহীন কীগুলি মঞ্জুরি দেয় এবং জেএসএন ব্লব ব্যবহার করার চেয়ে দ্রুত অনুসন্ধান করতে পারে তবে নোএসকিউএল সমাধানগুলির মতো তত দ্রুত নয়।

uid   |   meta_key    |   meta_val
----------------------------------
1         name            Frank
1         age             12
2         name            Jeremiah
3         fav_food        pizza
.................

সম্পাদনা

ইতিহাস / একাধিক কী সঞ্চয় করার জন্য

uid   | meta_id    |   meta_key    |   meta_val
----------------------------------------------------
1        1             name            Frank
1        2             name            John
1        3             age             12
2        4             name            Jeremiah
3        5             fav_food        pizza
.................

এবং এই জাতীয় কিছু মাধ্যমে ক্যোয়ারী:

select meta_val from `table` where meta_key = 'name' and uid = 1 order by meta_id desc

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

+1 টি। আমি এটাও লক্ষ্য করেছি! তবে এটি আপনাকে একটি বিশাল টেবিল দেয় (সারিগুলির ক্ষেত্রে)। এছাড়াও আপনি একাধিক মান সংরক্ষণ করতে পারবেন না , বলুন, যদি ব্যবহারকারী তার নাম পরিবর্তন করে তবে আমি পুরানো নামটিও সংরক্ষণ করতে চাই, সেক্ষেত্রে আমার জেএসওএন টাইপের ডেটা মডেল লাগবে।
শুক্লস্নিধ্য্যা

@ সান, আপনি যদি জেএসএনে পুরানো মান রাখতে চান তবে আপনাকে কীটির নতুন নামও দিতে হবে: আপনি একটি ইএভি (যা এই উদাহরণটি যা) বা জেএসওএন দিয়ে করতে পারেন। এটি বিশেষভাবে আলাদা নয়।
ব্রুনো

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

অবশ্যই আপনার নকল কী থাকতে পারে না তবে সেই কীটির সাথে একটি অ্যারে যুক্ত থাকতে পারে। emailidআমি আমার প্রশ্নের যে উদাহরণটি দিয়েছি তাতে কীটি দেখুন ।
শুক্লস্নিধ্য্যা

13

পদ্ধতির অপূর্ণতা হুবহু আপনি যা উল্লেখ করেছেন:

প্রতিবার এটিতে কোনও পাঠ্য-অনুসন্ধান করা দরকার হওয়ায় এটি জিনিসগুলি খুঁজে পেতে এটি খুব ধীর করে তোলে।

পরিবর্তে প্রতি কলামে মান পুরো স্ট্রিংয়ের সাথে মেলে।

আপনার পদ্ধতির (জেএসএন ভিত্তিক ডেটা) এমন ডেটার জন্য ঠিক আছে যা আপনাকে অনুসন্ধান করার দরকার নেই এবং আপনার সাধারণ ডেটা সহ কেবল প্রদর্শন করা প্রয়োজন।

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


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

4
হ্যাঁ. এইভাবে, আপনি প্রতি কলামে ডেটা-তে তথ্য অনুসন্ধান থেকে প্রয়োজনীয় কর্মক্ষমতা পান এবং যখন প্রয়োজন হয় তখন কোডে JSON ব্লবটি ধরুন।
নিক অ্যান্ড্রিওপ্লোস

9

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

দ্বিতীয় মডেলটি জনপ্রিয় সম্পর্কযুক্ত ডাটাবেস কাঠামো।

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

আপনার দ্বিতীয় প্রশ্নের উত্তর দেওয়ার জন্য, আপনি যদি প্রথম মডেল ব্যবহার করেন তবে 'ফু' এর মতো নামের কোয়েরির কোনও উপায় নেই


মডেল দুটি ব্যবহার করা কি বুদ্ধিমানের কাজ? আমার যে ডেটা সন্ধান করতে হবে তার জন্য প্রতি কলামে কী এবং অন্যদের জন্য JSON (একই ডাটাবেসে)?
শুক্লস্নিধ্য্যা

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

অপ্রয়োজনীয় ডেটা যখন ছোট হয় তখন অতিরিক্ত কাজ ব্যয়বহুল হয় না, বলুন, কেবলমাত্র দুটি ক্ষেত্র রয়েছে যার উপরে আমার অনুসন্ধান করা দরকার, তাই আমি তাদের জন্য দুটি নতুন কলাম তৈরি করেছি, [সম্ভবত] আমার জেএসএন ডেটা থেকে তাদের সরিয়ে ফেলুন [/ সম্ভবত] । এটি ঠিক ব্যয়বহুল নকল হবে না?
শুক্লস্নিধ্য্যা

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

সুবিধাটি কোনও এপিআই থেকে জেএসওএন অবজেক্ট / কলব্যাকগুলি সঞ্চয় করতে পারে না? উদাহরণস্বরূপ, ইউটিউবের API, URL, থাম্ব ইত্যাদির জন্য কল করার পরিবর্তে, আপনি JSON অবজেক্টের জন্য কেবল আপনার স্থানীয় ডিবি (মাইএসকিএল, লাইট ইত্যাদি) অনুসন্ধান করতে পারবেন? আমি জানি না, আমার কাছে তা উপলব্ধি করে, বিশেষত আপনি যদি ক্যাশে চেষ্টা করছেন বা কোনও অ্যাপ্লিকেশন দ্রুত চালিত করার চেষ্টা করছেন। তবে আমি পেশাদার নই: /
মার্কব্রাতানোভ 26'15

4

দেখে মনে হচ্ছে আপনি মূলত কোনও সম্পর্কিত মডেল ব্যবহার করবেন কিনা তা নিয়ে দ্বিধা করছেন।

এটি যেমন দাঁড়ায়, আপনার উদাহরণটি একটি যুক্তিযুক্ত মডেলকে যথাযথভাবে মাপসই করে তবে আপনার অবশ্যই এই মডেলটি বিকশিত করার দরকার পড়লে সমস্যাটি অবশ্যই আসতে পারে।

আপনার প্রধান সত্তা (ব্যবহারকারী) এর জন্য যদি কেবলমাত্র এক (বা কয়েকটি পূর্ব নির্ধারিত) বৈশিষ্ট্যের মাত্রা থাকে তবে আপনি এখনও একটি সম্পর্কিত ডেটাবেসে একটি সত্তা অ্যাট্রিবিউট মান (EAV) মডেলটি ব্যবহার করতে পারেন। (এটিতে এর উপকারিতাও রয়েছে cons)

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

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

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

সম্পাদনা করুন:

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

দুটি মডেলের মিশ্রণ অগত্যা ভুল নয় (অতিরিক্ত স্থান তুচ্ছ বলে ধরে নেওয়া), তবে সমস্যা তৈরি হতে পারে যদি আপনি দুটি ডাটা সেট সিঙ্কে রেখেছেন তা নিশ্চিত না করেন: আপনার অ্যাপ্লিকেশনটিকে অন্যটি আপডেট না করে কখনও কোনও পরিবর্তন করতে হবে না ।

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


আমি উপরে যা বলেছিলাম তা ছাড়াও পোস্টগ্র্রেএসকিউএল 9.4 এবং তারপরে জেএসওএনবি ডেটাটাইপের জন্য অপারেটরগুলির দিকে নজর রাখা ভাল।
ব্রুনো

1

কিছু সময় টেবিলে যোগ দেবে একটি ওভারহেড head ওএলএপ-এর জন্য বলি। আমার যদি দুটি টেবিল থাকে তবে একটি হল ORDERS টেবিল এবং অন্যটি হল ORDER_DETAILS। সমস্ত অর্ডার বিশদ পাওয়ার জন্য আমাদের দুটি টেবিলের সাথে যোগ দিতে হবে এটি স্বেচ্ছাসেবীর সারণীতে কোনও সারি বাড়ানোর কারণে কয়েক মিলিয়ন বা তার চেয়ে বেশি বলা চলবে না .. আমি মনে করি যদি আমরা সম্পর্কিত অর্ডারগুলিতে JSON স্ট্রিং / অবজেক্ট যুক্ত করি তবে JOIN এড়ানো হবে। প্রতিবেদন জেনারেশন দ্রুত হবে ...


1

সংক্ষিপ্ত উত্তর আপনাকে তাদের মধ্যে মিশ্রিত করতে হবে, এমন তথ্যের জন্য জসন ব্যবহার করুন যা আপনি তাদের সাথে যোগাযোগের ডেটা, ঠিকানা এবং পণ্যগুলির ভেরিয়েবলের মতো সম্পর্ক তৈরি করতে যাচ্ছেন না


0

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

db.mycollection.find(
    {
      name: 'sann'
    }
)

2
কৌতূহলের বাইরে, আপনি কী ধরে নিতে পেরেছিলেন যে তাঁর মডেলটি সম্পর্কহীন। তিনি উপরে যে তথ্য রেখেছিলেন তা আমার কাছে খুব আপেক্ষিক বলে মনে হয়।
কলিন এম

0

অন্যরা যেমন নির্দেশ করেছে যে প্রশ্নগুলি ধীরে ধীরে হবে। আমি এর পরিবর্তে ক্যোয়ারিতে কমপক্ষে একটি '_ID' কলাম যুক্ত করার পরামর্শ দেব।

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.