ব্যবহারকারী সংজ্ঞায়িত ক্ষেত্রগুলির জন্য কীভাবে একটি ডেটাবেস ডিজাইন করবেন?

145

আমার প্রয়োজনীয়তাগুলি হ'ল:

কোনও তথ্য প্রকারের ব্যবহারকারী-সংজ্ঞায়িত ক্ষেত্রগুলি গতিশীলরূপে যুক্ত করতে সক্ষম হওয়া দরকার
ইউডিএফগুলি দ্রুত জিজ্ঞাসা করতে সক্ষম হওয়া প্রয়োজন
ডেটাটাইপের ভিত্তিতে ইউডিএফ-তে গণনা করতে সক্ষম হওয়া প্রয়োজন
ডেটাটাইপের ভিত্তিতে ইউডিএফগুলি বাছাই করতে সক্ষম হওয়া দরকার

অন্যান্য তথ্য:

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

বিকল্প:

স্ট্রিংভ্যালু 1, স্ট্রিংভ্যালু 2 ... ইন্টভ্যালু 1, ইন্টভ্যালু 2, ... ইত্যাদি দিয়ে একটি বড় টেবিল তৈরি করুন আমি এই ধারণাটিকে ঘৃণা করি তবে কেউ যদি আমাকে বলতে পারে যে এটি অন্যান্য ধারণাগুলির চেয়ে ভাল এবং কেন।
একটি গতিশীল টেবিল তৈরি করুন যা প্রয়োজন অনুযায়ী চাহিদা অনুযায়ী একটি নতুন কলাম যুক্ত করে adds আমি এই ধারণাটিও পছন্দ করি না কারণ আমার মনে হয় যে আপনি প্রতিটি কলামকে সূচি না দিলে পারফরম্যান্সটি ধীর হবে।
UDFName, UDFDataType, এবং মান সমন্বিত একটি একক সারণী তৈরি করুন। যখন কোনও নতুন ইউডিএফ যুক্ত হয়, তখন এমন একটি ভিউ তৈরি করুন যা কেবলমাত্র সেই ডেটাটি টানতে পারে এবং যে কোনও প্রকারের মধ্যে যা নির্দিষ্ট করে তা এতে পার্স করে। পার্সিংয়ের মানদণ্ড পূরণ না করে এমন আইটেমগুলি NULL প্রদান করে।
একাধিক ইউডিএফ টেবিল তৈরি করুন, প্রতিটি ডাটা টাইপের জন্য। সুতরাং আমাদের কাছে ইউডিএফএসআরটিংস, ইউডিএফডিটস ইত্যাদির টেবিলগুলি থাকতে হবে সম্ভবত # 2 এর মতোই হবে এবং যে কোনও সময় নতুন ক্ষেত্র যুক্ত হওয়ার সাথে সাথে একটি দৃশ্য স্বয়ংক্রিয়ভাবে উত্পন্ন করবে would
এক্সএমএল ডেটাটাইপস? আমি এর সাথে আগে কাজ করি নি তবে তাদের উল্লেখ করতে দেখেছি। নিশ্চিত নয় যে তারা আমাকে যে ফলাফলগুলি দিতে চাইবে, বিশেষত পারফরম্যান্স সহ।
অন্যকিছু?

— রেচেল
সূত্র

7

মার্টিন ফওলার 2 (ব্যবহারকারী-আপডেটযোগ্য স্কিমা) বা 5 (ইনডেক্সড এক্সএমএল এলওবি

— নীল ম্যাকগুইগান

গতিশীল ডাটাবেস স্কিমায় স্ট্যাকওভারফ্লো প্রশ্নটিও দেখুন ।

— ফ্লাওয়ারওয়ে

49

যদি পারফরম্যান্স প্রাথমিক উদ্বেগ হয় তবে আমি # 6 দিয়ে যাব ... ইউডিএফ প্রতি একটি টেবিল (সত্যই, এটি # 2 এর একটি বৈকল্পিক)। এই উত্তরটি বিশেষত এই পরিস্থিতিতে এবং ডেটা বিতরণ এবং বর্ণিত অ্যাক্সেস নিদর্শনগুলির বর্ণনা অনুসারে তৈরি করা হয়েছে।

পেশাদাররা:

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

কনস:

এটি প্রচুর টেবিল তৈরি করতে পারে। স্কিমা বিচ্ছেদ এবং / অথবা একটি নামকরণ কনভেনশন কার্যকর করা এটিকে হ্রাস করবে।
ইউডিএফ সংজ্ঞা এবং পরিচালনা পরিচালনার জন্য আরও অ্যাপ্লিকেশন কোড প্রয়োজন। আমি আশা করি এটি এখনও মূল বিকল্প 1, 3 এবং 4 এর চেয়ে কম কোডের প্রয়োজন।

অন্যান্য বিবেচ্য বিষয়:

ইউডিএফদের দলবদ্ধ করার জন্য ডেটাগুলির প্রকৃতি সম্পর্কে যদি কিছু থাকে তবে তা উত্সাহিত করা উচিত। এইভাবে, এই ডেটা উপাদানগুলিকে একক টেবিলের সাথে একত্রিত করা যেতে পারে। উদাহরণস্বরূপ, ধরা যাক রঙ, আকার এবং ব্যয়ের জন্য আপনার কাছে ইউডিএফ রয়েছে। ডেটাতে প্রবণতা হ'ল এই ডেটার বেশিরভাগ দৃষ্টান্ত দেখে
```
 'red', 'large', 45.03 
```
বরং
```
 NULL, 'medium', NULL
```
এই জাতীয় ক্ষেত্রে, আপনি 1 টি টেবিলের 3 টি কলাম একত্রিত করে একটি লক্ষণীয় গতির জরিমানা ব্যয় করতে পারবেন না কারণ কয়েকটি মানগুলি NULL হবে এবং আপনি আরও 2 টি টেবিল তৈরি করা এড়িয়ে যাবেন, যখন আপনাকে সমস্ত 3 টি কলাম অ্যাক্সেস করার দরকার হয় তখন 2 কম সংযুক্ত হয় ।
আপনি যদি কোনও ইউডিএফ থেকে এমন একটি পারফরম্যান্স প্রাচীর মারেন যা প্রচুর জনবহুল এবং প্রায়শই ব্যবহৃত হয়, তবে এটিকে মাস্টার সারণিতে অন্তর্ভুক্ত করার জন্য বিবেচনা করা উচিত।
লজিকাল টেবিল ডিজাইন আপনাকে একটি নির্দিষ্ট পর্যায়ে নিয়ে যেতে পারে, তবে যখন রেকর্ড গণনাগুলি সত্যই বিশাল আকার ধারণ করে, আপনার পছন্দের আরডিবিএমএস দ্বারা কী টেবিল বিভাজনের বিকল্পগুলি সরবরাহ করা হবে তাও আপনার শুরু করা উচিত।

— ফিল হেলমার
সূত্র

1

Checklists! আমার এবং ফিলের মধ্যে রসিকতার ভিতরে, আমি আশা করি এটি নিয়মের বিরুদ্ধে নয়।

— গুনার এল 3510

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

— রাহেল

আমি একটি টেবিলের সাথে কাজ করছি যা ইউডিএফের তারিখ / সংস্করণিত হয়েছে , সর্বশেষ মানগুলি পেতে আমি এই পদ্ধতিটি স্ট্যাকওভারফ্লো.com /a/123481/328968 ব্যবহার করি ।

— পিটার

22

আমি এই সমস্যা সম্পর্কে অনেক লিখেছি । সর্বাধিক সাধারণ সমাধান হ'ল এন্টি-অ্যাট্রিবিউট-ভ্যালু অ্যান্টিপ্যাটার্টার, যা আপনি নিজের বিকল্প # 3 এ বর্ণনা করেছেন তার অনুরূপ। প্লেগের মতো এই নকশাটি এড়িয়ে চলুন ।

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

আপনি এই সমাধান সম্পর্কে 2009 থেকে একটি আকর্ষণীয় নিবন্ধটি পড়তে পারেন: http://backchannel.org/blog/friendfeed-schemaless-mysql

অথবা আপনি কোনও দস্তাবেজ-ভিত্তিক ডাটাবেস ব্যবহার করতে পারেন, যেখানে আশা করা যায় যে প্রতি নথিতে আপনার কাস্টম ক্ষেত্র রয়েছে। আমি বেছে নিতে চাই Solr ।

— বিল কারভিন
সূত্র

1

আপনি ব্যাখ্যা করতে পারেন কেন আমার বিকল্প # 3 এড়ানো উচিত? আমি আপনার কয়েকটি উদাহরণ দেখেছি, তবে তারা যা করার চেষ্টা করছি তা আসলে একই নয়। আমি কেবল অতিরিক্ত ডেটা সঞ্চয় করার জন্য একটি জায়গা চাই, সমস্ত বৈশিষ্ট্য সঞ্চয় করার জায়গা নয়।

— রাহেল

2

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

— বিল কারভিন

2

সংক্ষিপ্ত উত্তরটি হ'ল "ডেটা এবং মেটাডেটা মেশান না" " ডেটা স্ট্রিং হিসাবে মেটাডেটা সনাক্তকারীদের জন্য বারচার কলাম তৈরি করা fieldnameবা tablenameতা সংরক্ষণ করা এবং এটি বেশ কয়েকটি সমস্যার শুরু of এছাড়াও en.wikedia.org/wiki/Inner-platform_effect দেখুন

— বিল কারভিন

2

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

— বিল কারভিন

2

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

— বিল কারভিন

10

আমি সম্ভবত নিম্নলিখিত কাঠামোর একটি টেবিল তৈরি করব:

ভারচার নাম
বারচার প্রকার
দশমিক সংখ্যা মূল্য
স্ট্রিংভ্যালু
তারিখ তারিখ মূল্য

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

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

আপনি কিছু ধরণের মেটা ডেটা তথ্য পেতে চাইতে পারেন। সুতরাং আপনি নিম্নলিখিত দিয়ে শেষ:

টেবিল উদফমেটাডাটা

আইটি
ভারচার নাম
বারচার প্রকার

সারণী মাস্টারউডভ্যালু

int মাস্টার_এফকে
int মেটাডেটা_এফকে
দশমিক সংখ্যা মূল্য
স্ট্রিংভ্যালু
তারিখ তারিখ মূল্য

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

— স্টিফান স্টেইনগার ger
সূত্র

আমি আপনার কৌশলটি পছন্দ করি এবং সম্ভবত এটির জন্য বেছে নিতে পারি তবে ২০১ 2017 সালে আপনি কি অন্যরকম কিছু বেছে নেবেন? json এর মত

— maztt

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

— স্টিফান স্টেইনগার

এর বাইরে, ২০১১ সালে আমি যা প্রস্তাব করেছি তা হ'ল আইএমএইচও এখনও একটি বৈধ সমাধান।

— স্টিফান স্টেইনগার

10

এটি এমন একটি সমস্যার মতো শোনাচ্ছে যা মংগোডিবি বা কাউচডিবি-এর মতো একটি সম্পর্কহীন সমাধানের মাধ্যমে আরও ভাল সমাধান করা যেতে পারে।

আপনি যে দ্বৈত সততাটি খুঁজছেন তা বজায় রাখতে উভয়ই গতিশীল স্কিমা বিস্তারের অনুমতি দেয় for

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

আপনার অবজেক্ট স্তরে স্কিমা বিধিগুলি এম্বেড না করে কোনও নাল বা অনুপস্থিত মান বৈধ প্রবেশিকা বা প্রবেশের অভাব কিনা তা আপনি নির্ধারণ করতে পারবেন না।

আপনি আপনার স্কিমা দক্ষতার সাথে পরিচালনা করার ক্ষমতা হারাবেন। "মান" ক্ষেত্রের জন্য কি 100-বর্ণের বর্ণচরটি সঠিক টাইপ? 200-অক্ষর? পরিবর্তে এটি nvarchar করা উচিত? এটি আপনার ব্যবসায়ের গতিশীল প্রকৃতির উপর কৃত্রিম সীমাবদ্ধতা স্থাপনের পরে একটি কঠোর বাণিজ্য ও বন্ধ হতে পারে। "আপনার কাছে কেবল এক্স ব্যবহারকারী-সংজ্ঞায়িত ক্ষেত্র থাকতে পারে এবং প্রতিটি কেবল y অক্ষর দীর্ঘ হতে পারে।

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

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

— ডেটা সন্ন্যাসী
সূত্র

6

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

বিকল্প 1

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

বিকল্প 3,4,5

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

বিকল্প 2,6

এটি সত্যিই একটি পছন্দ ছেড়ে দেয়: নির্দিষ্টকরণ সংগ্রহ করুন এবং তারপরে স্কিমা তৈরি করুন out

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

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

কলামগুলি স্পার করুন

— টমাস
সূত্র

5

একাধিক ইউডিএফ টেবিল তৈরি করুন, প্রতিটি ডাটা টাইপের জন্য। সুতরাং আমাদের কাছে ইউডিএফএসআরটিংস, ইউডিএফডিটস ইত্যাদির টেবিলগুলি থাকতে হবে সম্ভবত # 2 এর মতোই হবে এবং যে কোনও সময় নতুন ক্ষেত্র যুক্ত হওয়ার সাথে সাথে একটি দৃশ্য স্বয়ংক্রিয়ভাবে উত্পন্ন করবে would

আমার গবেষণা অনুসারে ডেটা টাইপের ভিত্তিতে একাধিক টেবিল আপনাকে পারফরম্যান্সে সহায়তা করবে না। বিশেষত যদি আপনার কাছে বাল্ক ডেটা থাকে, যেমন 50K ইউডিএফ সহ 20K বা 25K রেকর্ড রয়েছে। পারফরম্যান্স সবচেয়ে খারাপ ছিল।

একাধিক কলাম সহ আপনার একক টেবিলের সাথে যাওয়া উচিত:

varchar Name
varchar Type
decimal NumberValue
varchar StringValue
date DateValue

— অমিত ঠিকাদার
সূত্র

এটি একটি সঠিক এবং upvated হওয়া উচিত। ফিলের দ্বারা 2011 এর পূর্ববর্তী উত্তরটি আজকের দিনে আর ভাল পরামর্শ নয়

— ইয়াপ কা লুন লিওন

আমি কীভাবে এসকিএল-তে এই জাতীয় প্রক্রিয়া করব তার একটি সহজ উদাহরণ পেতে পারি?

— নির্জ

দেরী জবাবের জন্য দুঃখিত, তবে আপনি একই জন্য ডাটাবেস কাঠামো চান। আমি তোমাকে নিরোজকে পাইনি। আপনি কি চান দয়া করে বিস্তারিত বলতে পারেন।

— অমিত ঠিকাদার

4

এটি একটি সমস্যাযুক্ত পরিস্থিতি এবং এর সমাধানগুলির কোনওটিই "ডান" হিসাবে উপস্থিত হয় না। তবে বিকল্প 1 সম্ভবত সরলতার দিক থেকে এবং পারফরম্যান্সের দিক থেকে উভয়ই সেরা।

এটি কয়েকটি বাণিজ্যিক উদ্যোগ অ্যাপ্লিকেশনগুলিতে ব্যবহৃত সমাধান।

সম্পাদনা

আর একটি বিকল্প যা এখন উপলভ্য, তবে উপস্থিত ছিল না (বা কমপক্ষে পরিপক্ক ছিল না) যখন প্রশ্নটি জিজ্ঞাসা করা হয়েছিল মূলত ডিবিতে জেসন ক্ষেত্রগুলি ব্যবহার করা।

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

postgress

মাইএসকিউএল

— ওফির ইওকতান
সূত্র

1

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

— রাচেল

একটি একক টেবিলের জন্য 1300 বিভিন্ন ইউডিএফ? প্রতিটি ব্যবহারকারীর কাছে ইউডিএফ যুক্ত করার বিকল্প রয়েছে, বা কেবলমাত্র একরকম শক্তি ব্যবহারকারী?

— ওফির ইয়োকটান

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

— রাচেল

2

আমার অভিজ্ঞতা হয়েছে বা 1, 3 এবং 4 ছিল এবং তারা সকলেই বাজে ফাঁকা হয়ে যায়, তথ্যটি কী তা স্পষ্ট হয় না বা ডায়নামিক ধরণের রেকর্ডে ডেটা ভাঙ্গতে কোনও ধরণের নরম শ্রেণিবদ্ধকরণের সাথে সত্যই জটিল।

আমি এক্সএমএল চেষ্টা করার জন্য প্রলুব্ধ হব, আপনি ডাটা টাইপিং ইত্যাদি যাচাইয়ের জন্য এক্সএমএল এর বিষয়বস্তুর বিরুদ্ধে স্কিমার প্রয়োগ করতে সক্ষম হবেন যা ইউডিএফ ডেটার ডিফারেন্স সেটগুলি রাখতে সহায়তা করবে। এসকিউএল সার্ভারের নতুন সংস্করণগুলিতে আপনি এক্সএমএল ক্ষেত্রগুলিতে সূচক করতে পারেন, যা কার্য সম্পাদন করতে সহায়তা করবে। ( উদাহরণস্বরূপ http://blogs.technet.com/b/josebda/archive/2009/03/23/sql-server-2008-xML-indexing.aspx দেখুন )

— জন এগারটন
সূত্র

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

— রাচেল

1

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

— কেল

2

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

এক্সএমএল ডেটাটাইপগুলি পারফরম্যান্সের কারণে খুব ভাল নয়। আপনি যদি সার্ভারে গণনা করে থাকেন তবে আপনি ক্রমাগত এগুলি ডিসরিয়ালাইজ করে যাচ্ছেন।

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

— টিম রজার্স
সূত্র

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

— রাচেল

সন্ধান পেয়েছি স্কেল_ভিয়ারেন্টসকে লাইক ক্লজ দিয়ে ব্যবহার করা যাবে না ... আমার কাছে বিশাল ক্ষতি হয় down অবশ্যই, আমি যদি প্রতিটি ইউডিএফের জন্য একটি ভিউ তৈরি করি তবে আমি এটি এসকিউএল_ভিআরআইএনএসপ্রাইটির (মান, 'বেসটাইপ') এর উপর ভিত্তি করে উপযুক্ত ডেটাটাইপটিতে কাস্ট করতে পারি ... এখনও, পারফরম্যান্সের জন্য এটি খারাপ বলে মনে হচ্ছে

— রাচেল

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

— টিম রজার্স

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

— রাচেল

1

শেয়ারপয়েন্টটি বিকল্প 1 ব্যবহার করে এবং যুক্তিসঙ্গত কর্মক্ষমতা রয়েছে।

— নাথান ডিউইট
সূত্র

1

আমি অতীতে এই বিকল্পগুলির কোনওটিই ব্যবহার করে খুব সফলভাবে পরিচালনা করেছি (বিকল্প 6? :))।

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

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

— কেল
সূত্র

1

আমাদের ডাটাবেস একটি সাস অ্যাপ (হেল্পডেস্ক সফটওয়্যার) ক্ষমতা দেয় যেখানে ব্যবহারকারীদের 7 কেরও বেশি "কাস্টম ক্ষেত্র" রয়েছে। আমরা একটি সম্মিলিত পদ্ধতির ব্যবহার:

(EntityID, FieldID, Value)তথ্য অনুসন্ধানের জন্য টেবিল
entitiesটেবিলের একটি JSON ক্ষেত্র , যা সমস্ত সত্তার মান ধারণ করে , ডেটা প্রদর্শনের জন্য ব্যবহৃত হয় । (এইভাবে মানগুলির মান পেতে আপনার মিলিয়ন জয়েন্টের দরকার নেই)।

আপনি আরও # 1 মত একটি "ডাটাটাইপ প্রতি সারণী" আছে বিভক্ত পারে এই উত্তরটি প্রস্তাব দেওয়া হয়, এই ভাবে আপনি এমনকি নিজের UDFs সূচক পারেন।

"সত্তা-বৈশিষ্ট্য-মান" রোধের জন্য পিএস দু'এক শব্দ শোনার জন্য প্রত্যেকে পটান। আমরা কয়েক দশক ধরে # 2 ছাড়াই # 1 ব্যবহার করেছি এবং এটি ঠিক কাজ করেছে। কখনও কখনও এটি একটি ব্যবসায়িক সিদ্ধান্ত। আপনার অ্যাপটি পুনরায় লেখার জন্য এবং ডিবিটিকে নতুন করে ডিজাইন করার কি সময় আছে বা আপনি ক্লাউড-সার্ভারগুলিতে কয়েক হাজার টাকা ফেলে দিতে পারেন, যা এই দিনগুলিতে সত্যই সস্তা? যাইহোক, যখন আমরা # 1 পদ্ধতির ব্যবহার করছিলাম, তখন আমাদের ডিবি কয়েক মিলিয়ন সত্তা ধরে রেখেছে, শত শত হাজার ব্যবহারকারীর দ্বারা অ্যাক্সেস পেয়েছিল এবং 16 জিবি ডুয়াল-কোর ডিবি সার্ভার ঠিক জরিমানা করছে

— অ্যালেক্স
সূত্র

হাই @ অ্যালেক্স, আমি একটি অনুরূপ সমস্যা জুড়ে এসেছি। যদি আমি ভালভাবে বুঝতে পারি তবে আপনি পেয়েছেন: 1) 1 custom_fieldsটেবিলের স্টোর মান যেমন 1 => last_concert_year, 2 => band, 3 => musicএবং তারপরে custom_fields_values001, 1, 1976 002, 1, 1977 003, 2, Iron Maiden003, 3 , Metal আশা করি উদাহরণটি আপনাকে বোঝায় এবং বিন্যাসের জন্য দুঃখিত!

— থিতামি

পছন্দ করেছেন আপনার উদাহরণ অনুসরণ: আমি একটি আছে bandsটেবিল একটি সারিতে সঙ্গে 1,'Iron Maiden'তারপর custom_fieldsসারি দিয়ে 1,'concert_year' | 2,'music'তারপর custom_fields_valuesসারি দিয়ে1,1,'1977'|1,2,'metal'

— অ্যালেক্স

0

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

সম্ভবত অন্য বিকল্পটি হ'ল প্রতিটি ব্যবহারকারীর তৈরি ইউডিএফের সংখ্যা ট্র্যাক করা এবং তারা 6 (বা অন্য কিছু সমানভাবে এলোমেলো সীমা) কাস্টম ক্ষেত্রের শীর্ষগুলি ব্যবহার করতে পারে তা বলে ক্ষেত্রগুলি পুনরায় ব্যবহার করতে বাধ্য করা।

আপনি যখন এটির মতো কোনও ডাটাবেস কাঠামোগত সমস্যার মুখোমুখি হন তবে অ্যাপ্লিকেশনটির প্রাথমিক নকশায় (আপনার ক্ষেত্রে আমদানি ব্যবস্থা) ফিরে যাওয়া এবং এটিতে আরও কয়েকটি বাধা রাখা ভাল is

এখন আমি যা করবো তা হল ব্যবহারকারীদের একটি লিঙ্ক যুক্ত করার সাথে বিকল্প 4 (ইডিআইটি):

general_data_table
id
...


udfs_linked_table
id
general_data_id
udf_id


udfs_table
id
name
type
owner_id --> Use this to filter for the current user and limit their UDFs
string_link_id --> link table for string fields
int_link_id
type_link_id

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

— ওয়াটার সাইমনস
সূত্র

0

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

SELECT *
FROM FieldValues_Text
WHERE fieldId IN (
    SELECT fieldId FROM Fields WHERE userId=@userId
)
AND value LIKE '%' + @search + '%'

এটি আমার মতে ব্যবহারকারী-সংজ্ঞায়িত প্রকারের পক্ষে সেরা সম্ভাব্য পারফরম্যান্স নিশ্চিত করবে।

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

প্রতিবেদনের জন্য, আপনি PIVOTআপনার ক্ষেত্রের টেবিল লেবেল মানগুলিকে কলামের নামগুলিতে রূপান্তর করতে ব্যবহার করতে পারেন , তারপরে প্রতিটি ডেটা টাইপ টেবিল থেকে আপনার ক্যোয়ারির ফলাফলগুলিকে সেই পাইভোটেড কলামগুলিতে পিভট করুন।

— মার্ক এন্টিং
সূত্র