মাল্টি-টেন্যান্ট ডেটাবেস আর্কিটেকচারে টেন্যান্টের ক্রমবর্ধমান সংখ্যা পরিচালনা করা


26

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

তবে সমস্যাটি হ'ল এই অ্যাপ্লিকেশনটিতে প্রচুর সংখ্যক ভাড়াটে (5,000-10,000) জন একক ভাড়াটিয়ারের জন্য সম্ভবত 2000,000 ব্যবহারকারী থাকবে। আমাদের প্রতি সপ্তাহে বেশ কয়েকজন ভাড়াটে দ্বারা সিস্টেমটি বর্ধমানকে সমর্থন করতে হবে।

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

  • কীভাবে নিবন্ধকরণ এবং ডাটাবেস তৈরির প্রক্রিয়াটি দৃ rob়ভাবে স্বয়ংক্রিয়ভাবে পরিচালিত হতে পারে?

  • সিস্টেমে ভাড়াটেদের ডাটাবেস তৈরি ও নিবন্ধকরণের প্রক্রিয়াটি কার্য সম্পাদন বা লক করার সমস্যার কারণ হতে পারে। আপনি যদি ভাবেন যে এটি কোনও সমস্যা হতে পারে তবে কেউ কি এটিকে প্রশমিত করার উপায়গুলি বলতে পারেন?

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

  • যদি একাধিক ডাটাবেস সার্ভার যুক্ত করে যদি আমার 'স্কেল আউট' করা দরকার হয়, তবে কেউ কি সার্ভারের (নকল ইত্যাদি) ব্যবহারকারীর পরিচয়গুলি পরিচালনা করতে এবং এই সমস্যাগুলি প্রশমিত করার কোনও উপায় নিয়ে আমার কী সমস্যাগুলি সমাধান করতে পারে তার পরামর্শ দিতে পারে?


1
আমার এইরকম পরিস্থিতি মোকাবেলা করতে হয়নি, তবে আমার অন্তর্নিহিততা হ'ল ভাড়াটিয়া রোলআউট হ'ল যতটা ভাড়াটিয়া ডাটাবেসগুলি আপনি পরিচালনা করতে পারবেন সেগুলি পূর্বে কনফিগার করে সার্ভারগুলি পরিচালনা করতে হবে এবং তারপরে কেবল পূর্ব-নির্মিত ভাড়াটে ডাটাবেসগুলিকে নতুন ভাড়াটে হিসাবে নির্ধারণ করবে my নিবন্ধন করুন. কমপক্ষে ভাড়াটে DBs মোতায়েন করার সময় আপনাকে রিসোর্স কনটেন্ট সম্পর্কে চিন্তা করতে হবে না।
জোয়েল ব্রাউন

1
আপনি কি 5,000-10,000 ভাড়াটে কাছাকাছি যে কোনও জায়গায় পাবেন তা নিশ্চিত? এবং যে আপনার সমস্ত ভাড়াটিয়া 2,000 ব্যবহারকারীর মধ্যে থাকবে? আমার সিস্টেমে আমি মনে করি আমাদের একক ভাড়াটিয়াদের জন্য আবেদনের সর্বাধিক সংখ্যক ব্যবহারকারী প্রায় 100 ছিল And এবং কেবলমাত্র 20 বা ততোধিকের মধ্যে ধারাবাহিকভাবে সক্রিয় ছিলেন। আমি জিজ্ঞাসা করতে পারি শিল্প / অ্যাপ্লিকেশন কী?
হারুন বারট্রান্ড

@ অ্যারনবার্ট্র্যান্ড এটি একটি লার্নিং ম্যানেজমেন্ট সিস্টেম যেখানে পরিষেবাগুলি আংশিক বিনামূল্যে এবং আংশিকভাবে প্রদান করা হবে।
কোডেডি

উত্তর:


25

নিম্ন প্রান্তে (500 ভাড়াটে / 10000 ব্যবহারকারী) আমি এটি এটি করেছিলাম। প্রথমত, আপনার কাছে একটি "নিয়ন্ত্রণ" ডাটাবেস রয়েছে যা বৈশ্বিক, কেন্দ্রীয় এবং ভাড়াটে এবং ব্যবহারকারীদের সম্পর্কে সমস্ত তথ্য ধারণ করে (আমি সত্যই মনে করি না যে আপনি এগুলি এসকিউএল লেখার লগইন হিসাবে পরিচালনা করতে চান)। সুতরাং নিম্নলিখিত সারণীগুলির সাথে "নিয়ন্ত্রণ" নামে একটি ডেটাবেস কল্পনা করুন:

CREATE TABLE dbo.Instances
(
  InstanceID INT PRIMARY KEY,
  Connection VARCHAR(255)
  --, ...
);

INSERT dbo.Instances SELECT 1, 'PROD1\Instance1';
INSERT dbo.Instances SELECT 1, 'PROD2\Instance1';
-- ...

CREATE TABLE dbo.Tenants
(
  TenantID INT PRIMARY KEY,
  Name NVARCHAR(255) NOT NULL UNIQUE,
  InstanceID INT -- Foreign key tells which instance this tenant's DB is on
  --, ...
);

INSERT dbo.Tenants SELECT 1, 'MyTenant', 1;
-- ...

CREATE TABLE dbo.Users
(
  UserID INT PRIMARY KEY,
  Username VARCHAR(320) NOT NULL UNIQUE,
  PasswordHash VARBINARY(64), -- because you never store plain text, right?
  TenantID INT -- foreign key
  --, ...
);

INSERT dbo.Users SELECT 1, 'foo@bar.com', 0x43..., 1;

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

ডেটাবেস নাম যোজনা দিয়ে তৈরি করা হয়েছিল Tenant000000xxযেখানে xxপ্রতিনিধিত্ব Tenants.TenantID। এই, রক্ষণাবেক্ষণ কাজ করেছেন পরিবর্তে নামে ডাটাবেস সব ধরণের থাকার বেশ সহজ BurgerKing, McDonalds, KFCযে একটি উদাহরণ হিসাবে শুধু ব্যবহার ইত্যাদি আমরা যে ফাস্ট ফুড ছিল।

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

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

  1. আমাদের পরামর্শদাতারা ছিল যা আমাদের একাধিক ক্লায়েন্টের জন্য কাজ করেছিল এবং একাধিকটিতে অ্যাক্সেসের প্রয়োজন ছিল
  2. আমাদের ভাড়াটে ছিল যারা নিজেরাই আসলে একাধিক ভাড়াটে ছিল of

সুতরাং, আমরা একটি TenantUsersটেবিল দিয়ে শেষ করেছি যা এক ব্যবহারকারীকে একাধিক ভাড়াটেদের সাথে যুক্ত থাকতে দেয়।

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

SELECT i.Connection
  FROM dbo.Instances AS i
  INNER JOIN dbo.Tenants AS t
  ON i.InstanceID = t.InstanceID
  INNER JOIN dbo.TenantUsers AS u
  ON i.TenantID = u.TenantID
  WHERE u.UserID = @UserID;

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

যদি আপনি প্রস্তাবিত এই 10 মিমি ব্যবহারকারী অঞ্চলে প্রবেশ করেন তবে অবশ্যই আরও ভাল ভারসাম্য বজায় রাখতে আপনার এটি দরকার need আপনি অ্যাপ্লিকেশনটিকে সংঘবদ্ধ করতে চাইতে পারেন যাতে তাদের বিভিন্ন কন্ট্রোল ডাটাবেসের সাথে সংযোগের বিভিন্ন পয়েন্ট থাকতে পারে। আপনি যদি প্রতিটি ভাড়াটিয়াকে সাবডোমেন দেন (যেমন টেন্যান্টনাম.ইউর অ্যাপ্লিকেশনডোমাইন ডট কম) তবে আপনি যখন আরও স্কেল করার প্রয়োজন হবে তখন আপনি ডিএনএস / রাউটিং সহ দৃশ্যের পিছনে এটি করতে পারেন।

এর আরও অনেক কিছুই রয়েছে - @ ডারিনের মতো আমি কেবল এখানে পৃষ্ঠতলের স্ক্র্যাচ করছি। আপনার যদি নিখরচায় পরামর্শের প্রয়োজন হয় তবে আমাকে জানান। :-)


আপনার অভিজ্ঞতা ভাগ করে নেওয়ার জন্য ধন্যবাদ। এর আলোকিত আমাকে দিন me এ সম্পর্কে আরও খুঁজছেন। তবে আপনি ইতিমধ্যে নিখরচায় লিখেছেন। :(
কোডেদে

1
আমার বক্তব্যটি ছিল যে আমার কাছে কেবল বিনামূল্যে পরামর্শের জন্য বরাদ্দ করার জন্য এত সময় রয়েছে। :-)
হারুন বারট্রান্ড

+1 - আমি ঠিক আগের মতো একই পদ্ধতি ব্যবহার করেছি approach ~ একই সংখ্যক ভাড়াটিয়াও সত্যই ভাল কাজ করেছে।
অ্যাডাএদেভ

মাস্টার ডাটাবেস এবং ভাড়াটে ডাটাবেসের মধ্যে সম্পর্ক কীভাবে পরিচালনা করবেন? (ট্রিগার ইত্যাদির ব্যবহার ছাড়াই)
জিতেন্দ্র পাঁচোলি

@ জিতেন্দ্র সত্যিই অনেকগুলি বিকল্প নয় - কোনও ভাড়াটে ডাটাবেসে আপনার সত্যিকারের কতটা ডেটা থাকে যা মাস্টার ডাটাবেসের ডেটা সম্পর্কিত হতে পারে? আমিও নিশ্চিত নই যে আমি ট্রিগারগুলির জনপ্রিয় ভয়টি বুঝতে পেরেছি - সঠিকভাবে লিখিত ট্রিগার ভয় পাওয়ার কিছু নয় ...
অ্যারন বারট্রান্ড

10

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

সবচেয়ে খারাপ পরিস্থিতি অবকাঠামো-ভিত্তিক (যা প্রকৃতপক্ষে সর্বোত্তম কেস দৃশ্যাবলী, ব্যবসায়-ভিত্তিক), আপনার 2k ব্যবহারকারীদের 10K ডাটাবেস প্রয়োজন। এটি 20,000,000 ব্যবহারকারী। আপনি 20 এম এসকিউএল সার্ভার লগইন পরিচালনা করার চেষ্টা করে সফল হতে যাচ্ছেন না। আইএমও। তাদের মধ্যে কেবল নিছক সংখ্যা, তাদের সার্ভার থেকে সার্ভারে সরিয়ে নিয়ে যাওয়ার, আইডি সংঘর্ষে এবং মেলানো আইডির জন্য নজর রাখার পাশাপাশি আমি নিশ্চিত নই যে এসকিউএল সার্ভার sys.server_prصولগুলিতে 20 এম সারিগুলির সাথে কেমন আচরণ করবে। অতিরিক্তভাবে, আপনার ওয়েব অ্যাপ্লিকেশন সম্ভবত একক, বা খুব কম সংখ্যক ব্যবহারকারী হিসাবে সংযোগ করতে চাইবে। ডিআইএসএন স্ট্রিংগুলি অভিন্ন না হলে আইআইএস সংযোগগুলি পুল করতে পারে না। ডিএসএন স্ট্রিংয়ের অন্যতম বৈশিষ্ট্য হল ব্যবহারকারী নাম। বিভিন্ন ব্যবহারকারী মানে কোনও পুলিং নেই।

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

তাত্ক্ষণিক প্রশ্ন: দুটি পৃথক ব্যবহারকারী, যারা দুটি ভিন্ন ভাড়াটে অন্তর্ভুক্ত, তাদের একই ব্যবহারকারীর নাম থাকার অনুমতি দেওয়া উচিত?

আরেকটি তাত্ক্ষণিক প্রশ্ন: যদি আমি আপনাকে বলি যে আমি ফুবার, ইনক। এর জন্য কাজ করি, আপনি কীভাবে তা জানবেন? ফুবার কি আপনাকে ব্যবহারকারীর একটি তালিকা দেবে এবং আপনি তাদের ব্যবহারকারীর নামের একটি তালিকা ফিরিয়ে দিবেন, বা তারা স্ব-বিধানে চলেছেন?

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

এমনকি যদি আপনার অনেক ভাড়াটে শুরু না হয় তবে আপনার ভবিষ্যত এবং অটোমেশন সম্পর্কে চিন্তাভাবনা শুরু করা উচিত কারণ আপনি যখন দেখেন যে আপনার সার্ভারটি শুরু হয়েছে এবং অনলাইনে আনার জন্য 10 জন নতুন ভাড়াটে রয়েছে, তখন অনেক দেরি হয়ে গেছে এবং আপনার পরিষেবাও (এবং আপনার ক্লায়েন্টগুলি এবং আপনার শীঘ্রই প্রাক্তন ক্লায়েন্টগুলি যতক্ষণ না সমস্যা সমাধানের উপায়টি লিখবে ততক্ষণ আপনার ক্ষতি হবে will

আপনার ওভারলোড হওয়া সার্ভারগুলি থেকে হালকা লোড হওয়া (বা নতুন) সার্ভারগুলিতে ডেটাবেসগুলি চারপাশে সরিয়ে নেওয়ার একটি উপায় প্রয়োজন। আপনি ডাউনটাইমের উইন্ডো পেতে পারেন কিনা তা আপনার এসএলএর উপর নির্ভর করবে।

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

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

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

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

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

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


মন্তব্যের জন্য ধন্যবাদ। প্রকল্পটি আকর্ষণীয় eed শব্দ সীমাবদ্ধতার কারণে আমি মন্তব্যটি খুব নির্ভুলভাবে রাখছি। এটি একটি লার্নিং ম্যানেজমেন্ট সিস্টেম যেখানে প্রতিটি ভাড়াটে প্রায় 120-150 টেবিল পাবেন। কোনও ভাড়াটেই হোক না কেন ব্যবহারকারীর একই ব্যবহারকারীর নাম থাকবে। আরও জটিলতা হ্রাস করার জন্য ডিএনএস সিএনএম ম্যাপিং উদাহরণস্বরূপ ব্যবহৃত হবে ট্যান্যান্ট ১.এবসি.কম। এখন ফুটন্ত পয়েন্টটি হ'ল - এটি সঠিক পদ্ধতিতে ডিজাইন করা যাতে এটি আপনার ভাগ করা সমস্ত পরামর্শ পূরণ করবে এবং আমি উদ্বিগ্ন। হোয়াইটপেপার পাওয়া প্রশংসনীয় হবে তবে এটি সহজ নয়, সম্ভবত আপনি যদি পারেন তবে আরও ইনপুট লাগছেন। !!!!
কোডেডি
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.