গত 20 বছরে আমি কয়েকটি বড় মডিউলার ডাটাবেস ডিজাইন দেখেছি এবং আমি ডেভিডের প্রস্তাবিত দৃশ্যটি বেশ কয়েকবার দেখেছি যেখানে অ্যাপ্লিকেশনগুলির নিজস্ব স্কিমা / টেবিলের সেটটিতে লেখার অ্যাক্সেস রয়েছে এবং অন্য স্কিমা / এ অ্যাক্সেস পড়তে পারে / টেবিলের সেট। কোনও অ্যাপ্লিকেশন / মডিউলটিতে কেবলমাত্র পঠনযোগ্য অ্যাক্সেস পাওয়া যায় এমন এই ডেটাটিকে "মাস্টার ডেটা" হিসাবে বর্ণনা করা যেতে পারে ।
সেই সময়ে আমি যে সমস্যাগুলি দেখিনি যে পূর্বের উত্তরগুলি আমার দেখা উচিত ছিল বলে সুপারিশ করে তাই আমি মনে করি পূর্বের উত্তরে উত্থাপিত পয়েন্টগুলি আরও বিশদে বিশদভাবে দেখার জন্য এটি উপযুক্ত is
দৃশ্য: আপনি একটি আরডিবিএমএসের সাথে সরাসরি কয়েকটি উপাদান বেঁধে রাখেন এবং আপনি দেখেন যে একটি নির্দিষ্ট উপাদান পারফরম্যান্সের বোতল-ঘাড়ে পরিণত হচ্ছে
আমি এই মন্তব্যে একমত নই এই ছাড়াও মাইক্রোসার্চিস পড়ার জন্য স্থানীয়ভাবে ডেটার একটি অনুলিপি থাকার পক্ষে যুক্তি। এটি হ'ল, বেশিরভাগ পরিপক্ক ডেটাবেসগুলি অনুলিপি সমর্থন করে এবং তাই কোনও বিকাশকারী প্রচেষ্টা ছাড়াই "মাস্টার ডেটা" শারীরিকভাবে মাইক্রো সার্ভিস ডাটাবেজে অনুলিপি করা যায় যদি এটি প্রয়োজন হয় বা প্রয়োজন হয়।
কিছু পুরানো ছদ্মবেশে এটি "বিভাগীয় ডাটাবেস" -র মূল টেবিলগুলি প্রতিলিপি করে এমন একটি "এন্টারপ্রাইজ ডাটাবেস" হিসাবে স্বীকৃত হতে পারে। এখানে একটি বক্তব্যটি হ'ল সাধারণত এটি ভাল হয় যদি কোনও ডাটাবেস পরিবর্তিত তথ্যের প্রতিলিপি তৈরির জন্য আমাদের জন্য এটি করে (কেবল বেল্টারি আকারে এবং উত্স ডাটাবেসের সর্বনিম্ন ব্যয়ে ডেল্টাস)।
বিপরীতভাবে, যখন আমাদের ডাটাবেস পছন্দগুলি এই 'তাক থেকে বন্ধ' প্রতিরূপ সমর্থন করতে দেয় না তখন আমরা এমন পরিস্থিতিতে পড়তে পারি যেখানে আমরা "মাস্টার ডেটা" কে মাইক্রোসার্চী ডাটাবেসে ঠেলাঠেলি করতে চাই এবং এর ফলে ডেভেলপারের প্রচেষ্টার একটি উল্লেখযোগ্য পরিমাণ এবং এছাড়াও একটি যথেষ্ট কম দক্ষ পদ্ধতি।
ডাটাবেসটিকে অস্বীকৃতি জানাতে পারে, তবে আপনি পারবেন না কারণ অন্যান্য সমস্ত উপাদান প্রভাবিত হবে
আমার কাছে এই বক্তব্যটি সঠিক নয়। ডেনরমালাইজেশন একটি "অ্যাডিটিভ" পরিবর্তন এবং একটি "ব্রেকিং চেঞ্জ" নয় এবং ডেনোরালাইজেশনের কারণে কোনও অ্যাপ্লিকেশন ভঙ্গ করা উচিত নয়।
এই অ্যাপ্লিকেশনটির বিরতি একমাত্র উপায় যেখানে অ্যাপ্লিকেশন কোডটি "নির্বাচন করুন * ..." এর মতো কিছু ব্যবহার করে এবং কোনও অতিরিক্ত কলাম পরিচালনা করে না। আমার কাছে যে অ্যাপ্লিকেশনটিতে একটি বাগ হবে?
কীভাবে ড্যানোরালাইমেশন একটি অ্যাপ্লিকেশন ভাঙ্গতে পারে? আমার কাছে এফইউডি লাগছে।
স্কিমার নির্ভরতা:
হ্যাঁ, এখন অ্যাপ্লিকেশনটির ডেটাবেস স্কিমার উপর নির্ভরতা রয়েছে এবং এর অর্থ হ'ল এটি একটি বড় সমস্যা হওয়া উচিত। কোনও অতিরিক্ত নির্ভরতা যুক্ত করার সময় স্পষ্টতই আদর্শ নয় আমার অভিজ্ঞতাই হ'ল ডাটাবেস স্কিমার উপর নির্ভরতা কোনও সমস্যা হয় নি তাই কেন এমনটি হতে পারে? আমি কি ভাগ্যবান হয়েছি?
মূল তথ্য
আমরা সাধারণত যে মাইক্রোসার্ফিসের কেবলমাত্র পঠনযোগ্য অ্যাক্সেস পেতে চাই সেই স্কিমাটি সাধারণত এন্টারপ্রাইজের জন্য " মাস্টার ডেটা " হিসাবে বর্ণনা করি । এটিতে মূল তথ্য রয়েছে যা এন্টারপ্রাইজের জন্য প্রয়োজনীয়।
.তিহাসিকভাবে এর অর্থ হ'ল আমরা যে স্কিমাটির উপর নির্ভরতা যুক্ত করব তা হ'ল পরিপক্ক এবং স্থিতিশীল (এন্টারপ্রাইজটির কিছুটা মৌলিক এবং অপরিবর্তনীয়)।
নিয়মমাফিককরণ
যদি 3 টি ডাটাবেস ডিজাইনাররা যান এবং একটি সাধারণ ডিবি স্কিমা ডিজাইন করেন তবে তারা একই নকশায় শেষ হবে। ঠিক আছে, কিছু 4NF / 5NF প্রকরণ থাকতে পারে তবে খুব বেশি নয়। আরও কী রয়েছে যে একাধিক প্রশ্ন রয়েছে যা ডিজাইনার মডেলটি যাচাই করতে চাইতে পারে যাতে ডিজাইনার আত্মবিশ্বাসী হতে পারে যে তারা 4 এনএফ-তে পৌঁছেছে (আমি কি খুব আশাবাদী? লোকেরা কি 4NF এ যাওয়ার চেষ্টা করছেন?)।
আপডেট: এখানে 4NF দ্বারা আমি বলতে চাইছি স্কিমার সমস্ত টেবিলগুলি 4NF পর্যন্ত তাদের সর্বোচ্চ স্বাভাবিক ফর্মটিতে পৌঁছেছে (সমস্ত টেবিলগুলি 4NF পর্যন্ত যথাযথভাবে স্বাভাবিক করা হয়েছে)।
আমি বিশ্বাস করি যে নরমালাইজেশন ডিজাইন প্রক্রিয়া হ'ল ডাটাবেস ডিজাইনাররা একটি সাধারণীকৃত ডেটাবেস স্কিমার উপর নির্ভর করে ধারণাটি নিয়ে সাধারণত স্বাচ্ছন্দ্য বোধ করেন।
নরমালাইজেশন প্রক্রিয়া একটি পরিচিত "সঠিক" নকশায় ডিবি ডিজাইন পায় এবং সেখান থেকে পরিবর্তিত হওয়াগুলি পারফরম্যান্সের জন্য অস্বীকৃত হওয়া উচিত।
- সমর্থিত ডিবি প্রকারের ভিত্তিতে বিভিন্নতা থাকতে পারে (জেএসএন, আরএআরএ, জিও টাইপ সমর্থন ইত্যাদি)
- কেউ কেউ 4NF / 5NF এর উপর ভিত্তি করে পরিবর্তনের পক্ষে তর্ক করতে পারে
- আমরা শারীরিক প্রকরণকে বাদ দিই (কারণ এটি কোনও ব্যাপার নয়)
- আমরা এটি ওয়ালটিপি ডিজাইনের মধ্যে সীমাবদ্ধ রাখি, ডিডাব্লু ডিজাইন নয় কারণ এগুলি সেই স্কীমা যা আমরা কেবলমাত্র পঠনযোগ্য অ্যাক্সেসকে দিতে চাই
যদি 3 প্রোগ্রামার যেখানে প্রয়োগ করার জন্য নকশাকে দেওয়া হয় (কোড হিসাবে) তখন প্রত্যাশাটি 3 টি বিভিন্ন বাস্তবায়নের (সম্ভাব্যভাবে খুব আলাদা) হয়ে থাকে।
আমার কাছে সম্ভবত "স্বাভাবিকায়নের বিশ্বাস" নিয়ে প্রশ্ন রয়েছে।
ব্রেকিং স্কিমা পরিবর্তন?
অস্বীকৃতি, কলাম যুক্ত করা, বড় স্টোরেজের জন্য কলাম পরিবর্তন করা, নতুন টেবিলের সাহায্যে নকশাকে প্রসারিত করা ইত্যাদি সমস্ত নন-ব্রেকিং পরিবর্তন এবং ডিবি ডিজাইনার যারা 4 র্থ সাধারণ ফর্ম পেয়েছেন সে বিষয়ে আত্মবিশ্বাসী হবে।
কলাম / সারণী বাদ দিয়ে বা ব্রেকিং টাইপ পরিবর্তন করে ব্রেকিং পরিবর্তনগুলি সম্ভবত সম্ভব। সম্ভাব্য হ্যাঁ, তবে ব্যবহারিক দিক দিয়ে আমি এখানে কোনও সমস্যাই অনুভব করি না। সম্ভবত কারণ বোঝা যাচ্ছে যে ব্রেকিং পরিবর্তনগুলি কী এবং এগুলি ভালভাবে পরিচালনা করা হয়েছে?
আমি কেবলমাত্র ভাগ-পঠনযোগ্য স্কিমার প্রসঙ্গে স্কিমা পরিবর্তনগুলি ভাঙার ক্ষেত্রে শুনতে আগ্রহী
কোনও মাইক্রোসারওয়াইস সম্পর্কে আরও গুরুত্বপূর্ণ এবং তাৎপর্যপূর্ণ কী: এর এপিআই বা এর ডাটাবেস স্কিমা? এপিআই, কারণ এটি বিশ্বের অন্যান্য অংশের সাথে চুক্তি।
আমি এই বিবৃতিটির সাথে একমত হওয়ার পরেও আমি মনে করি একটি গুরুত্বপূর্ণ সতর্কতা রয়েছে যা আমরা কোনও এন্টারপ্রাইজ আর্কিটেক্টের কাছ থেকে শুনতে পাই যা "ডেটা চিরকাল বেঁচে থাকে" । এটি হ'ল, যদিও এপিআই সর্বাধিক গুরুত্বপূর্ণ বিষয় হতে পারে সামগ্রিকভাবে ডেটা এন্টারপ্রাইজের পক্ষেও গুরুত্বপূর্ণ এবং এটি খুব দীর্ঘ সময়ের জন্য গুরুত্বপূর্ণ।
উদাহরণস্বরূপ, একবার ব্যবসায়ের বুদ্ধিমত্তার জন্য ডেটা ওয়্যারহাউস পপুলেশন করার প্রয়োজন পরে এপিআই নির্বিশেষে ব্যবসায়ের প্রতিবেদনের দৃষ্টিভঙ্গি থেকে স্কিমা এবং সিডিসি সমর্থন গুরুত্বপূর্ণ হয়ে ওঠে।
এপিআই এর সমস্যাগুলি?
এখন যদি API এরগুলি নিখুঁত এবং সহজ হয় তবে সমস্ত পয়েন্টগুলি মোট হ'ল কারণ আমরা সর্বদা স্থানীয় পঠনযোগ্য অ্যাক্সেসের পরিবর্তে সর্বদা একটি API পছন্দ করি। সুতরাং কেবল স্থানীয় পঠনযোগ্য অ্যাক্সেস বিবেচনা করার প্রেরণা হ'ল এপিআই ব্যবহার করে কিছু সমস্যা হতে পারে যা স্থানীয় অ্যাক্সেস এড়ানো হয়।
What motivates people to desire local read-only access?
এপিআই অপ্টিমাইজেশন:
লিঙ্কডইনগুলিতে তাদের এপিআই অনুকূলকরণের বিষয়টি এবং তাদের স্কেলটিতে কেন এটি গুরুত্বপূর্ণ তা নিয়ে একটি আকর্ষণীয় উপস্থাপনা রয়েছে (২০০৯ থেকে) 2009 http://www.slideshare.net/linkedin/building-consistent-restful-apis-in-a-highperformance-environment
সংক্ষেপে, একবার যদি কোনও এআইপিএলকে অনেকগুলি বিভিন্ন ব্যবহারের ক্ষেত্রে সমর্থন করতে হয় তবে এটি সহজেই এমন পরিস্থিতিতে যেতে পারে যেখানে এটি একটি ব্যবহারের ক্ষেত্রে সর্বোত্তমভাবে সমর্থন করে এবং বাকীটি নেটওয়ার্ক দৃষ্টিকোণ এবং ডাটাবেস দৃষ্টিকোণ থেকে বরং খারাপভাবেই সমর্থন করে।
যদি লিঙ্কডইন-এর মতো পরিশীলিত API তে না থাকে তবে আপনি খুব সহজেই এমন পরিস্থিতিতে দেখতে পারবেন যেখানে:
- আপনার দরকারের তুলনায় এপিআই অনেক বেশি ডেটা নিয়ে আসে (অপব্যয়)
- চ্যাটি এপিআই যেখানে আপনাকে অনেকবার এপিআই কল করতে হবে
হ্যাঁ, আমরা অবশ্যই এপিআই-তে ক্যাচিং যুক্ত করতে পারি তবে শেষ পর্যন্ত এপিআই কলটি একটি রিমোট কল এবং ডেটা স্থানীয় থাকাকালীন বিকাশকারীদের জন্য একটি ধারাবাহিক অপটিমাইজেশন রয়েছে।
আমার সন্দেহ আছে যে সেখানে একটি সংখ্যক লোক রয়েছে যারা এটি এটিকে যুক্ত করতে পারে:
- মাইক্রো সার্ভিস ডাটাবেসে মাস্টার ডেটার কম খরচের প্রতিলিপি (কোনও উন্নয়ন ব্যয় এবং প্রযুক্তিগতভাবে দক্ষ নয়)
- সাধারণকরণে বিশ্বাস এবং স্কিমা পরিবর্তনের ক্ষেত্রে অ্যাপ্লিকেশনগুলির স্থিতিস্থাপকতা
- প্রতিটি ব্যবহারের ক্ষেত্রে সহজেই অনুকূলিতকরণ এবং সম্ভাব্যভাবে চ্যাটি / অপব্যয়কারী / অকার্যকর দূরবর্তী এপিআই কলগুলি এড়াতে সক্ষমতা
- সীমাবদ্ধতা এবং সুসংগত নকশার ক্ষেত্রে প্লাস কিছু অন্যান্য সুবিধা
এই উত্তরটি অনেক দীর্ঘ হয়েছে। দুঃক্ষিত !!