আপনি কীভাবে কাস্টম ক্ষেত্রগুলির সাথে কোনও ব্যবহারকারী ডেটাবেস ডিজাইন করবেন

Question

এই প্রশ্নটি সম্পর্কে আমি কীভাবে একটি ডেটাবেস ডিজাইন করব, এটি আরও ভাল সমাধান কী হবে তার উপর নির্ভর করে এটি রিলেশনাল / নোসকিএল ডাটাবেসগুলি হতে পারে

---

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

• একজন ব্যবহারকারী কেবল একটি সংস্থার অন্তর্ভুক্ত থাকতে পারে
• একটি সংস্থার অনেক ব্যবহারকারী থাকতে পারে

"সংস্থা" টেবিলের জন্য নকশাটি বেশ সোজা। সংস্থার নিম্নলিখিত বৈশিষ্ট্য / কলাম থাকবে: (আসুন এটি সহজ রাখি)

ID, COMPANY_NAME, CREATED_ON

প্রথম দৃশ্য

সরল এবং সোজা এগিয়ে, ব্যবহারকারীর সবার একই বৈশিষ্ট্য রয়েছে, তাই এটি সহজেই সম্পর্কিত শৈলীতে, ব্যবহারকারীর সারণিতে করা যেতে পারে:

ID, COMPANY_ID, FIRST_NAME, LAST_NAME, EMAIL, CREATED_ON

দ্বিতীয় দৃশ্য

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

উদাহরণ স্বরূপ:

• সংস্থা এ সংরক্ষণ করতে চায়: LIKE_MOVIE (বুলিয়ান), LIKE_MUSIC (বুলিয়ান)
• সংস্থা বি সঞ্চয় করতে চায়: FAV_CUISINE (স্ট্রিং)
• সংস্থা সি সঞ্চয় করতে চায়: OWN_DOG (বুলিয়ান), ডিওজি_এন্ট (ইনট)

পদ্ধতির ঘ

নিষ্ঠুর বলের উপায় হ'ল ব্যবহারকারীর জন্য একটি একক স্কিমা থাকা এবং তারা যখন কোম্পানির অন্তর্ভুক্ত না তখন তাদের নালাগুলি দেওয়া উচিত:

ID, COMPANY_ID, FIRST_NAME, LAST_NAME, EMAIL, LIKE_MOVIE, LIKE_MUSIC, FAV_CUISINE, OWN_DOG, DOG_COUNT, CREATED_ON

কোনটা কদর্যজনক কারণ আপনার প্রচুর NULLS এবং ব্যবহারকারীর সারি সমাপ্ত হবে যার কলামগুলি তাদের সাথে অপ্রাসঙ্গিক (যেমন Company সংস্থা এ-এর সাথে সম্পর্কিত সমস্ত ব্যবহারকারীদের FAV_CUISINE, OWN_DOG, DOG_COUNT) এর জন্য নাল মান রয়েছে)

পদ্ধতির ঘ

একটি দ্বিতীয় পদ্ধতির, "ফর্ম ফর্ম ক্ষেত্র" থাকা:

ID, COMPANY_ID, FIRST_NAME, LAST_NAME, EMAIL, CUSTOM_1, CUSTOM_2, CUSTOM_3, CREATED_ON

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

পদ্ধতির ঘ

আমি পোস্টগ্রাইএসকিউএল জেএসওএন ক্ষেত্রে দেখেছি, এক্ষেত্রে আপনার কী হবে:

ID, COMPANY_ID, FIRST_NAME, LAST_NAME, EMAIL, CUSTOM_PROFILE_JSON, CREATED_ON

এই ক্ষেত্রে আপনি কীভাবে কোনও ব্যবহারকারীর জন্য বিভিন্ন স্কিমার প্রয়োগ করতে সক্ষম হবেন? সংস্থা এ এর ​​সাথে থাকা কোনও ব্যবহারকারীর মতো স্কিমা থাকবে

 {"LIKE_MOVIE":"boolean", "LIKE_MUSIC": "boolean"}

যদিও সি সি ব্যবহারকারীর একটি আলাদা স্কিমা থাকবে:

 {"OWN_DOG ":"boolean", "DOG_COUNT": "int"}

---

আমি এই সমস্যাটি কীভাবে সমাধান করব? তাদের (কোম্পানির) সম্পর্কের ভিত্তিতে একটি একক "অবজেক্ট" (ব্যবহারকারীর) জন্য এই নমনীয় স্কিমার অনুমতি দেওয়ার জন্য আমি কীভাবে ডাটাবেসটিকে সঠিকভাবে ডিজাইন করতে পারি?

সম্পর্কের সমাধান? nosql সমাধান?

---

সম্পাদনা: আমি একটি "CUSTOM_PROFILE" টেবিলের কথাও ভেবেছিলাম যা কলামগুলির চেয়ে সারিগুলিতে ব্যবহারকারী বৈশিষ্ট্যগুলি মূলত সংরক্ষণ করবে।

এই পদ্ধতির সাথে 2 টি সমস্যা রয়েছে:

1) প্রতিটি ব্যবহারকারী ডেটা কলামের পরিবর্তে সারি হিসাবে বৃদ্ধি পায় - এবং এর অর্থ ব্যবহারকারীর একটি সম্পূর্ণ চিত্র পেতে, অনেকগুলি যোগদানের প্রয়োজন, বিভিন্ন কাস্টম বৈশিষ্ট্যের "কাস্টম প্রোফাইল" টেবিলের সাথে একাধিক যোগদান

২) ডেটা মানটি সর্বদা জেনেরিক হওয়ার জন্য VARCHAR হিসাবে সংরক্ষণ করা হয়, এমনকি যদি আমরা জানি যে ডেটাটি পূর্ণসংখ্যা বা বুলিয়ান ইত্যাদি হতে পারে know

Comments

যদি প্রতিটি সংস্থায় বিভিন্ন সংস্থার আলাদা আলাদা, বহু-মূল্যবান ডেটা সেট থাকে তবে আপনার একেবারে একটি COMPANY_CUSTOMER লিঙ্কিং টেবিলের প্রয়োজন। অন্য সমস্ত কিছু খুব শীঘ্রই আপনাকে প্রচন্ড ব্যথা ঘটাবে।

— কিলিয়ান ফট

লিঙ্কিং টেবিলটি কীভাবে কাস্টম ডেটার সাহায্য করবে? কলামগুলি এখনও আলাদা হতে হবে

— noobcser

আপনাকে "IKEA এর জন্য কিলিয়ান পাসওয়ার্ড হ'ল" বিড়ালছানা "" এর প্রতিনিধিত্ব করতে হবে যেমন "কম্পিউটার: IKEA, গ্রাহক: কিলিয়ান, অ্যাট্রিবিউট: পাসওয়ার্ড, মান: বিড়ালছানা" " সহজ কিছু কাজ করবে না।

— কিলিয়ান ফট

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

— ম্যাসন হুইলারের

Answer 1

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

প্রথমে আপনার সংস্থাগুলি স্কিমা ব্যবহার করা যাক।

[Companies] ComnpanyId, COMPANY_NAME, CREATED_ON

পরবর্তী আমরা শীর্ষস্থানীয় প্রয়োজনীয় বৈশিষ্ট্যগুলির জন্য আপনার ব্যবহারকারীদের স্কিমা ব্যবহার করব যা সমস্ত সংস্থার দ্বারা ব্যবহৃত / ভাগ করা হবে।

[Users] UserId, COMPANY_ID, FIRST_NAME, LAST_NAME, EMAIL, CREATED_ON

এরপরে আমরা একটি টেবিল তৈরি করব যেখানে আমরা আমাদের গতিশীল বৈশিষ্ট্যগুলি সংজ্ঞায়িত করব যা প্রতিটি সংস্থার কাস্টম ব্যবহারকারীর বৈশিষ্ট্যের সাথে নির্দিষ্ট। সুতরাং এখানে অ্যাট্রিবিউট কলামের একটি উদাহরণ মান হবে "লাইক মিউজিক":

[UserAttributeDefinition] UserAttributeDefinitionId, CompanyId, Attribute

এরপরে আমরা একটি ব্যবহারকারীঅ্যাট্রিবিউট টেবিলটি সংজ্ঞায়িত করি যা ব্যবহারকারীর বৈশিষ্ট্য মানকে ধরে রাখবে

[UserAttributes] UserAttributeDefinitionId, UserId, Value

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

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

Comments

ধন্যবাদ - আমি যদিও এই জাতীয় পদ্ধতির বিষয়ে - দয়া করে সম্পাদনা দেখুন। 2 সমস্যা: 1) ডেটা সারি হিসাবে বৃদ্ধি পায় যার অর্থ কোনও ব্যবহারকারীর পূর্ণ চিত্র পাওয়া যায়, আপনাকে অনেকগুলি যোগদান করতে হবে। 2) "মান" সর্বদা জেনেরিক হওয়ার জন্য VARCHAR হিসাবে সংরক্ষণ করা হবে, মানটি আসলে ইনট বা বুলিয়ান ইত্যাদি

— হলেও

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

— পি। রো

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

— কোস

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

— স্কেবলযোগ্য

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

— পি। রো

Answer 2

একটি NoSQL ডাটাবেস ব্যবহার করুন। সেখানে সংস্থা এবং ব্যবহারকারীর নথি থাকবে। ব্যবহারকারীর টেম্পলেট (সেই সংস্থার ক্ষেত্র / প্রকারের ইঙ্গিত করার জন্য পাঠ্য) এর উপর ভিত্তি করে ব্যবহারকারীরা তাদের স্কিমাটির একটি অংশ গতিশীলভাবে তৈরি করবে।

\Company\<uniqueidentifier>
    - Name: <Name>
    - CreatedOn: <datetime>
    - UserTemplate: <Text>

\User\<uniqueidentifier>
    - COMPANY_ID: <ID>
    - FIRST_NAME: <Text>
    - LAST_NAME: <Text>
    - EMAIL: <Text>
    - CREATED_ON: <datetime>
    - * Dynamically created fields per company

ফায়ারবেস ডটকমের মতো এটির মতো দেখতে এটি কীভাবে হতে পারে আপনি যা পছন্দ করেন না কেন এটি কীভাবে করবেন তা শিখতে হবে।

Comments

এটি আমি যা জেএসএন কলাম সম্পর্কে ভাবছি। পিআরও প্রস্তাবিত সমাধানের তুলনায় ক্যোয়ারিং, ফিল্টারিং প্রতিবেদনে পারফরম্যান্স কেমন হয়।

— কোস

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

— পি। রো

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

— স্কেবলযোগ্য

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

— জেফও

Answer 3

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

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

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

Comments

ধন্যবাদ - আমি যদিও এই জাতীয় পদ্ধতির বিষয়ে - দয়া করে সম্পাদনা দেখুন। 2 সমস্যা: 1) ডেটা সারি হিসাবে বৃদ্ধি পায় যার অর্থ কোনও ব্যবহারকারীর পূর্ণ চিত্র পাওয়া যায়, আপনাকে অনেকগুলি যোগদান করতে হবে। 2) "মান" সর্বদা জেনেরিক হওয়ার জন্য VARCHAR হিসাবে সংরক্ষণ করা হবে, মানটি আসলে ইনট বা বুলিয়ান ইত্যাদি

— হলেও

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

— অ্যান্ডি

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

— অ্যান্ডি

Answer 4

অন্যান্য উত্তরের বিকল্পের মধ্যে রয়েছে প্রোফাইল_ট্রিবিব নামে একটি টেবিল থাকা বা স্কিমিটি আপনার অ্যাপ্লিকেশন দ্বারা সম্পূর্ণরূপে পরিচালিত similar

কাস্টম বৈশিষ্ট্যাবলী যুক্ত হওয়ার সাথে সাথে আপনি ALTER TABLE profile_attrib ADD COLUMN like_movie TINYINT(1)এগুলি মুছতে নিষেধ করতে পারেন। এটি এখনও আপনার নমনীয়তা প্রদান করার সময় আপনার যোগদানকে হ্রাস করবে।

আমার ধারণা বিট ট্রেড-অফ হ'ল অ্যাপ্লিকেশনটির এখন ডাটাবেসে পরিবর্তনের টেবিলের সুবিধাগুলি প্রয়োজন এবং কলামের নাম স্যানিটাইজিং সম্পর্কে আপনার চালাক হতে হবে।

Comments

নিয়মিত প্রকাশটি [^\w-]+খুব ভালভাবে করা উচিত, এমন কোনও কিছুর অনুমতি না দেয় - 0-9A-Za-z_-তবে হ্যাঁ, দূষিততা বা বোকামি থেকে রক্ষা পেতে এখানে স্যানিটাইজাইজিং করা আবশ্যক।

— নিয়মিত জো

Answer 5

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

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

আরও তথ্যের জন্য:

https://msdn.microsoft.com/en-us/library/hh403385.aspx

@ ওয়াল্টারমিটির উত্তরটিও বৈধ, যদিও উত্তরাধিকারের মডেল অনুসরণ করে যদি কারও অনেকগুলি আলাদা আলাদা বৈশিষ্ট্যযুক্ত গ্রাহক থাকে তবে অনেকগুলি টেবিলের সাথে শেষ হতে পারে। এটি নির্ভর করে কতগুলি কাস্টম বৈশিষ্ট্য গ্রাহকদের মধ্যে ভাগ করা হয়।

Comments

এটি পাশাপাশি কাজ করতে পারে তবে এক্সএমএল / জেএসওএন ক্ষেত্রে সঞ্চিত ডেটাগুলির বিরুদ্ধে আপনার কিছু করার দরকার পরে আমি সীমাবদ্ধ হয়ে উঠি feel

— অ্যান্ডি

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

— জন রায়নোর

টি-এসকিউএল এ এক্সএমএল / জেএসওএন কলামে লিখিত বিষয়বস্তুকে একটি নেমস্পেসের বিপরীতে এবং কাস্টম ডেটাতে থাকা উপাদানগুলির বিরুদ্ধে ক্যোয়ারী সংজ্ঞা দেওয়া সম্ভব। এটি কঠিন নয়

— স্টিফেন ইয়র্ক

Answer 6

আপনার আপনার ডাটাবেসটিকে সাধারণীকরণ করা উচিত যাতে প্রতিটি পৃথক ধরণের কোম্পানির প্রোফাইলের জন্য আপনার কাছে 3 টি আলাদা টেবিল রয়েছে। আপনার উদাহরণ ব্যবহার করে আপনার কলামগুলির সাথে টেবিল থাকবে:

USER_ID, LIKE_MOVIE, LIKE_MUSIC

USER_ID, FAVORITE_CUISINE

USER_ID, OWN_DOG, DOG_COUNT

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

Answer 7

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

এই ক্ষেত্রে, আপনি প্রাকৃতিক এবং সঠিক সমাধানের সাথে লড়াই করার চেষ্টা করছেন। সংস্থা এ এর ​​ব্যবহারকারীরা বি বি এর ব্যবহারকারী নয়, এবং তাদের নিজস্ব ক্ষেত্রগুলির জন্য তাদের নিজস্ব টেবিল থাকা উচিত।

আপনার ডাটাবেস বিক্রেতা আপনাকে টেবিলের সাহায্যে চার্জ দেয় না, এবং দ্বিগুণ টেবিলের জন্য আপনার দ্বিগুণ ডিস্কস্পেসের প্রয়োজন হবে না (বাস্তবে, দুটি টেবিল থাকা আরও কার্যকর কারণ আপনি বি এর ব্যবহারকারীদের জন্য এ এর ​​বৈশিষ্ট্যগুলি সংরক্ষণ করেন না Even এমনকি কেবল এনএলএলএস সংরক্ষণ করেও স্থান নেয়)।

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

Comments

এবং আপনার যদি হাজার হাজার গ্রাহক থাকে তবে প্রতিটি প্রতি এক টেবিল দ্রুত অনিবার্য হয়ে উঠতে পারে, প্রতিটি গ্রাহকের কাস্টম ক্ষেত্রগুলির জন্য আপনার কাস্টম কোড প্রয়োজন হবে তা উল্লেখ না করে।

— অ্যান্ডি

@ অ্যান্ডি: অনুমান কি? এক হাজার টেবিলে এক হাজার বিভিন্ন স্কিম মিশ্রিত করা গেলে পরিস্থিতি আরও উদ্বেগজনক হবে! এবং হ্যাঁ, আপনার সম্ভবত কাস্টম ক্ষেত্রগুলির জন্য কাস্টম কোডের প্রয়োজন নেই। আবার এটি সহজ, আরও কঠিন নয়, যদি প্রতিটি গ্রাহকের একটি পরিষ্কার, পৃথক টেবিল থাকে। অন্য এক হাজারের কাছ থেকে কোম্পানির এক্সের ক্ষেত্রগুলি বেছে নেওয়ার চেষ্টা করা রক্তাক্ত জঞ্জাল।

— এমসাল্টার্স

আপনি কি আমার উত্তর বা গ্রাহকের টেবিলের উপরে অতিরিক্ত কলামগুলি টেক করার ওপিএস ধারণাটি উল্লেখ করছেন?

— অ্যান্ডি

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

— ts ওভারফ্লো

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

— দৃ hard়তা

Answer 8

আমার সমাধান ধরে নিয়েছে যে আপনি কোনও প্রোগ্রাম থেকে এই কোয়েরিটি কল করবেন এবং আপনার পোস্ট প্রসেসিং করতে সক্ষম হওয়া উচিত। আপনার নিম্নলিখিত কলাম থাকতে পারে:

ID, COMPANY_ID, FIRST_NAME, LAST_NAME, EMAIL, CUSTOM_VALUES

CUSTOM_VALUES টাইপ স্ট্রিং স্টোরেজ কী এবং মানগুলির জোড়ের হবে। কীটি কলামের নাম হবে এবং মানটি কলামের মান হবে

LIKE_MOVIE;yes;LIKE_MUSIC;no;FAV_CUISINE;rice

এই CUSTOM_VALUES এ আপনি কেবল যে তথ্য বিদ্যমান তা সংরক্ষণ করবেন exist আপনি যখন প্রোগ্রাম থেকে জিজ্ঞাসা করবেন আপনি এই স্ট্রিংটি বিভক্ত করতে পারেন এবং এটি ব্যবহার করতে পারেন।

আমি এই লজিকটি ব্যবহার করে আসছি এবং এটি সূক্ষ্মভাবে কাজ করে, এটি ঠিক যে আপনাকে কোডে ফিল্টারিং লজিক প্রয়োগ করতে হবে এবং কোয়েরিতে নয়।