15

আমি জানি এটি এখানে এবং এখানে জিজ্ঞাসা করা হয়েছিল , তবে ভিন্ন সম্ভাব্য প্রয়োগের সাথে আমার একই ধারণা রয়েছে এবং আমার কিছু সহায়তা প্রয়োজন।

প্রাথমিকভাবে আমার blogstoriesএই কাঠামোর সাথে আমার টেবিলটি ছিল :

| Column    | Type        | Description                                    |
|-----------|-------------|------------------------------------------------|
| uid       | varchar(15) | 15 characters unique generated id              |
| title     | varchar(60) | story title                                    |
| content   | longtext    | story content                                  |
| author    | varchar(10) | id of the user that originally wrote the story |
| timestamp | int         | integer generated with microtime()             |

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

| Column        | Type          | Description                                       |
|------------   |-------------  |------------------------------------------------   |
| story_id      | varchar(15)   | 15 characters unique generated id                 |
| version_id    | varchar(5)    | 5 characters unique generated id                  |
| editor_id     | varchar(10)   | id of the user that commited                      |
| author_id     | varchar(10)   | id of the user that originally wrote the story    |
| timestamp     | int           | integer generated with microtime()                |
| title         | varchar(60)   | current story title                               |
| content       | longtext      | current story text                                |
| coverimg      | varchar(20)   | cover image name                                  |

আমি এখানে আসার কারণগুলি:

uidপ্রাথমিক টেবিলের ক্ষেত্র টেবিল অনন্য ছিল। এখনstory_id আর অনন্য নয়। আমি কিভাবে এটি মোকাবেলা করা উচিত? (আমি ভেবেছিলাম আমি সম্বোধন করতে পারব story_id = xএবং তারপরে সর্বশেষতম সংস্করণটি খুঁজে পাব, তবে এটি খুব সম্পদ ব্যয়বহুল বলে মনে হচ্ছে, তাই দয়া করে আপনার পরামর্শ দিন)
author_idক্ষেত্রের মানটি সারণীর প্রতিটি সারিতে পুনরাবৃত্তি করছে। আমি কোথায় এবং কিভাবে এটি রাখা উচিত?

সম্পাদন করা

অনন্য কোড তৈরির প্রক্রিয়াটি এই CreateUniqueCodeকার্যক্রমে রয়েছে:

trait UIDFactory {
  public function CryptoRand(int $min, int $max): int {
    $range = $max - $min;
    if ($range < 1) return $min;
    $log = ceil(log($range, 2));
    $bytes = (int) ($log / 8) + 1;
    $bits = (int) $log + 1;
    $filter = (int) (1 << $bits) - 1;
    do {
        $rnd = hexdec(bin2hex(openssl_random_pseudo_bytes($bytes)));
        $rnd = $rnd & $filter;
    } while ($rnd >= $range);
    return $min + $rnd;
  }
  public function CreateUID(int $length): string {
    $token = "";
    $codeAlphabet = "ABCDEFGHIJKLMNOPQRSTUVWXYZ";
    $codeAlphabet.= "abcdefghijklmnopqrstuvwxyz";
    $codeAlphabet.= "0123456789";
    $max = strlen($codeAlphabet) - 1;
    for ($i=0; $i < $length; $i++) {
        $token .= $codeAlphabet[$this->CryptoRand(0, $max)];
    }
    return $token;
  }
}

কোডটি হ্যাক- এ লেখা হয়েছে , এবং মূলত তার উত্তরে @ স্কট লিখেছিলেন পিএইচপি- তে ।

ক্ষেত্রগুলি author_idএবং আলাদা editor_id হতে পারে , কারণ যে কারওর গল্পগুলি সম্পাদনা করার জন্য পর্যাপ্ত অনুমতি সহ ব্যবহারকারী রয়েছে।

mysql database-design

— বিজেতা
সূত্র

23

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

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

অতএব আমি দুটি টেবিলের মাধ্যমে পরিস্থিতি পরিচালনার পরামর্শ দিচ্ছি:

এক "বর্তমান" বা "বর্তমান" জন্য একচেটিয়াভাবে নিবেদিত সংস্করণ এর ব্লগ খবর , এবং
একটি পৃথক, তবে অন্যটির সাথে যুক্ত, সমস্ত "পূর্ববর্তী" বা "অতীত" সংস্করণগুলির জন্য ;

প্রতিটি (1) কলামের একটি স্বতন্ত্র সংখ্যা এবং (2) সীমাবদ্ধতার একটি পৃথক গ্রুপ each

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

আমি নিম্নলিখিত হিসাবে এই সমস্ত কারণ এবং অন্যান্য প্রাসঙ্গিক পয়েন্টগুলি বিস্তারিত জানাব।

ব্যবসার নীতি

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

একজন ব্যবহারকারী শূন্য-এক বা একাধিক ব্লগস্টোরি লিখেছেন
একটি ব্লগস্টিরির শূন্যে এক বা একাধিক ব্লগস্টিরিওশন রয়েছে
একজন ব্যবহারকারী শূন্য-এক-বা একাধিক ব্লগস্টেরি ভার্সন লিখেছেন

এক্সপোসিটোরি IDEF1X ডায়াগ্রাম

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

চিত্র 1 - ব্লগ স্টোরি সংস্করণগুলি IDEF1X ডায়াগ্রাম

কেন ব্লগস্টিরি এবং ব্লগস্টিটি ভার্সন দুটি পৃথক সত্তার প্রকার হিসাবে ধারণা করা হয়েছে?

কারণ:

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

_{^একটি তথ্য মডেলিং জন্য ইন্টিগ্রেশন সংজ্ঞা ( IDEF1X ) একটি অত্যন্ত সুপারিশের ডেটা মডেলিং পন্থা যা একটি প্রতিষ্ঠিত হয়েছিল মান যুক্তরাষ্ট্র ডিসেম্বর 1993 সালে স্ট্যান্ডার্ড ন্যাশনাল ইন্সটিটিউট অফ ও প্রযুক্তি (, NIST)। তখন ভোর তাত্ত্বিক উপাদানের উপর ভিত্তি করে তৈরি দ্বারা রচনা একমাত্র জন্মদাতা এর রিলেশনাল মডেল , অর্থাত্, ডাঃ মতিন Codd ; উপর সত্তা-সম্পর্ক ডেটা, দ্বারা উন্নত দৃশ্যে ডঃ পিপি চেন ; এবং রবার্ট জি ব্রাউন দ্বারা নির্মিত লজিকাল ডেটাবেস ডিজাইন প্রযুক্তিতেও।}

চিত্রণমূলক লজিকাল এসকিউএল-ডিডিএল লেআউট

তারপরে, পূর্বে উপস্থাপিত ধারণাগত বিশ্লেষণের ভিত্তিতে, আমি নীচে যৌক্তিক-স্তরের নকশা ঘোষণা করেছি:

-- You should determine which are the most fitting 
-- data types and sizes for all your table columns 
-- depending on your business context characteristics.

-- Also you should make accurate tests to define the most
-- convenient index strategies at the physical level.

-- As one would expect, you are free to make use of 
-- your preferred (or required) naming conventions.    

CREATE TABLE UserProfile (
    UserId          INT      NOT NULL,
    FirstName       CHAR(30) NOT NULL,
    LastName        CHAR(30) NOT NULL,
    BirthDate       DATETIME NOT NULL,
    GenderCode      CHAR(3)  NOT NULL,
    UserName        CHAR(20) NOT NULL,
    CreatedDateTime DATETIME NOT NULL,
    --
    CONSTRAINT UserProfile_PK  PRIMARY KEY (UserId),
    CONSTRAINT UserProfile_AK1 UNIQUE ( -- Composite ALTERNATE KEY.
        FirstName,
        LastName,
        BirthDate,
        GenderCode
    ), 
    CONSTRAINT UserProfile_AK2 UNIQUE (UserName) -- ALTERNATE KEY.
);

CREATE TABLE BlogStory (
    BlogStoryNumber INT      NOT NULL,
    Title           CHAR(60) NOT NULL,
    Content         TEXT     NOT NULL,
    CoverImageName  CHAR(30) NOT NULL,
    IsActive        BIT(1)   NOT NULL,
    AuthorId        INT      NOT NULL,
    CreatedDateTime DATETIME NOT NULL,
    --
    CONSTRAINT BlogStory_PK              PRIMARY KEY (BlogStoryNumber),
    CONSTRAINT BlogStory_AK              UNIQUE      (Title), -- ALTERNATE KEY.
    CONSTRAINT BlogStoryToUserProfile_FK FOREIGN KEY (AuthorId)
        REFERENCES UserProfile (UserId)
);

CREATE TABLE BlogStoryVersion  (
    BlogStoryNumber INT      NOT NULL,
    CreatedDateTime DATETIME NOT NULL,
    Title           CHAR(60) NOT NULL,
    Content         TEXT     NOT NULL,
    CoverImageName  CHAR(30) NOT NULL,
    IsActive        BIT(1)   NOT NULL,
    AuthorId        INT      NOT NULL,
    UpdatedDateTime DATETIME NOT NULL,
    --
    CONSTRAINT BlogStoryVersion_PK              PRIMARY KEY (BlogStoryNumber, CreatedDateTime), -- Composite PK.
    CONSTRAINT BlogStoryVersionToBlogStory_FK   FOREIGN KEY (BlogStoryNumber)
        REFERENCES BlogStory (BlogStoryNumber),
    CONSTRAINT BlogStoryVersionToUserProfile_FK FOREIGN KEY (AuthorId)
        REFERENCES UserProfile (UserId),
    CONSTRAINT DatesSuccession_CK               CHECK       (UpdatedDateTime > CreatedDateTime) --Let us hope that MySQL will finally enforce CHECK constraints in a near future version.
);

এই এসকিউএল ফ্রিডলে পরীক্ষিত যা মাইএসকিউএল 5.6 এ চলে।

BlogStoryটেবিল

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

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

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

আমি বিআইটি (1)BlogStory.IsActive টাইপের কলামটি অন্তর্ভুক্ত করেছি (যদিও এ আপনাকে "নরম" বা "লজিক্যাল" ডিলেট কার্যকারিতা সরবরাহ করতে হবে এমন ক্ষেত্রে টিআইএনআইএনটিও ব্যবহার করা যেতে পারে) অন্তর্ভুক্ত করেছি।

সম্পর্কে বিশদ BlogStoryVersionটেবিল

অন্যদিকে, BlogStoryVersionটেবিলের পিকে (ক) BlogStoryNumberএবং (খ) নামের একটি কলাম গঠিত CreatedDateTimeযা অবশ্যই অবিকল তাত্ক্ষণিক চিহ্নকে চিহ্নিত করেBlogStory সারিতে একটি INSERT হয়েছে।

BlogStoryVersion.BlogStoryNumber, পিকে অংশ হওয়ার পাশাপাশি, একটি বিদেশী কী (এফকে) হিসাবেও উল্লেখ BlogStory.BlogStoryNumberকরা হয়েছে যা এই দুটি সারণীর সারিগুলির মধ্যে রেফারেন্সিয়াল অখণ্ডতা প্রয়োগ করে এমন একটি কনফিগারেশন । এই ক্ষেত্রে, এর একটি স্বয়ংক্রিয় প্রজন্ম বাস্তবায়ন করার BlogStoryVersion.BlogStoryNumberপ্রয়োজন হয় না কারণ এফকে হিসাবে সেট করা হওয়ার পরে, এই কলামটিতে সন্নিবেশিত মানগুলি অবশ্যই সংশ্লিষ্ট অংশের মধ্যে থাকা "থেকে" আঁকতে হবে BlogStory.BlogStoryNumber।

BlogStoryVersion.UpdatedDateTimeকলাম বজায় রাখা উচিত, আশানুরূপ, সময় বিন্দু যখন একটি BlogStoryসারি পরিবর্তিত হয় এবং ফলত, যোগ করা BlogStoryVersionটেবিল। সুতরাং, আপনি এই পরিস্থিতিতে এখন () ফাংশনটি ব্যবহার করতে পারেন।

ব্যবধান মধ্যে ঢুকা BlogStoryVersion.CreatedDateTimeএবং BlogStoryVersion.UpdatedDateTimeসমগ্র প্রকাশ সময়কাল যা সময়BlogStory সারি "বর্তমান" বা "বর্তমান" ছিল।

একটি Versionকলামের জন্য বিবেচনা

এটি BlogStoryVersion.CreatedDateTimeকলাম হিসাবে ভাবতে কার্যকর হতে পারে যা একটি ব্লগস্টেরির একটি নির্দিষ্ট "অতীত" সংস্করণ উপস্থাপন করে এমন মানকে ধরে রাখে । আমি এটিকে একটি বা তার চেয়ে অনেক বেশি উপকারী বলে মনে করি , যেহেতু এটি ব্যবহারকারী-বান্ধব এই অর্থে যে মানুষ সময় ধারণার সাথে আরও পরিচিত হওয়ার ঝোঁক রাখে । উদাহরণস্বরূপ, ব্লগ লেখক বা পাঠক নীচের মত একটি ফ্যাশনে একটি BlogStoryVersion উল্লেখ করতে পারে :VersionIdVersionCode

"আমি নির্দিষ্ট দেখতে চাই সংস্করণ এর BlogStory দ্বারা চিহ্নিত সংখ্যা 1750 ছিল নির্মিত উপর 26 August 2015এ 9:30"।

লেখক এবং সম্পাদক ভূমিকা: ডেটা শিক্ষাদীক্ষা ও ব্যাখ্যার

এই পদ্ধতির সঙ্গে, আপনি সহজেই আলাদা করতে পারেন যারা "মূল" ঝুলিতে AuthorIdএকটি কংক্রিট এর BlogStory "নিকটতম" নির্বাচন সংস্করণ একটি নির্দিষ্ট এর BlogStoryIdথেকে BlogStoryVersionআবেদন শক্তি কর্মদক্ষতার দ্বারা টেবিল MIN এর () ফাংশন থেকে BlogStoryVersion.CreatedDateTime।

এইভাবে, সমস্ত "পরবর্তী" বা "উত্তরসূরি" সংস্করণ সারিগুলিতে BlogStoryVersion.AuthorIdথাকা প্রতিটি মান স্বাভাবিকভাবেই স্বতন্ত্র সংস্করণটির লেখক শনাক্তকারীকে নির্দেশ করে তবে একজন এটিও বলতে পারেন যে এই জাতীয় মান একই সাথে বোঝানো হচ্ছে ভূমিকা জড়িত চরিত্রে অভিনয় ব্যবহারকারী হিসাবে সম্পাদক "মূল" এর সংস্করণ একটি এর BlogStory ।

হ্যাঁ, প্রদত্ত AuthorIdমানটি একাধিক BlogStoryVersionসারি দ্বারা ভাগ করা যেতে পারে , তবে এটি আসলে তথ্যের একটি অংশ যা প্রতিটি সংস্করণ সম্পর্কে খুব উল্লেখযোগ্য কিছু বলে , তাই ড্যাটুমের পুনরাবৃত্তিটি নয় একটা সমস্যা।

DATETIME কলামগুলির বিন্যাস

DATETIME ডেটা টাইপ হিসাবে, হ্যাঁ, আপনি ঠিক বলেছেন, " মাইএসকিউএল ' YYYY-MM-DD HH:MM:SS' ফর্ম্যাটে ডেটটাইম মানগুলি পুনরুদ্ধার করে এবং প্রদর্শন করে ", তবে আপনি আত্মবিশ্বাসের সাথে প্রাসঙ্গিক ডেটা এই পদ্ধতিতে প্রবেশ করতে পারেন, এবং যখন আপনাকে কোনও অনুসন্ধান করতে হবে তখন আপনাকে ঠিক করতে হবে অন্তর্নির্মিত DATE এবং TIME ফাংশনগুলি ব্যবহার করুন যাতে অন্যান্য জিনিসগুলির মধ্যে আপনার ব্যবহারকারীদের উপযুক্ত ফর্ম্যাটে সম্পর্কিত মানগুলি প্রদর্শিত হয়। অথবা আপনি অবশ্যই আপনার অ্যাপ্লিকেশন প্রোগ্রামগুলি (গুলি) কোডের মাধ্যমে এই জাতীয় ডেটা ফর্ম্যাটিং করতে পারবেন।

এর প্রভাব BlogStoryআপডেট অপারেশন

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

একটি `VersionId`বা `VersionCode`কলাম উপস্থাপন করা হচ্ছে

আপনি যদি ব্লগস্টেরি ভার্সনগুলি আলাদা করার জন্য কোনও কলাম BlogStory.VersionIdবা BlogStory.VersionCodeকলাম যুক্ত করতে (ব্যবসায়িক পরিস্থিতি বা ব্যক্তিগত পছন্দের কারণে) বেছে নেন , আপনার নিম্নলিখিত সম্ভাবনাগুলি বিবেচনা করতে হবে:

A এর VersionCodeজন্য অনন্য (i) পুরো BlogStoryটেবিলটিতে এবং (ii) মধ্যে অনন্য হতে পারে BlogStoryVersion।

অতএব, প্রতিটি মান উত্পন্ন করতে এবং নির্ধারিত করতে আপনাকে সাবধানতার সাথে পরীক্ষিত এবং সম্পূর্ণ নির্ভরযোগ্য পদ্ধতিটি প্রয়োগ করতে হবে Code।
হতে পারে, VersionCodeমানগুলি বিভিন্ন BlogStoryসারিতে পুনরাবৃত্তি হতে পারে তবে একই সাথে সদৃশ কখনও হয় নিBlogStoryNumber । উদাহরণস্বরূপ, আপনি থাকতে পারে:
- একটি BlogStoryNumber 3- সংস্করণ83o7c5c এবং, একসাথে,
- একটি BlogStoryNumber 86- সংস্করণ83o7c5c এবং
- একটি BlogStoryNumber 958- সংস্করণ83o7c5c ।

পরবর্তী সম্ভাবনা আরেকটি বিকল্প খোলে:

এর VersionNumberজন্য একটি রাখা BlogStories, যাতে থাকতে পারে:
- BlogStoryNumber 23- সংস্করণ1, 2, 3… ;
- BlogStoryNumber 650- সংস্করণ1, 2, 3… ;
- BlogStoryNumber 2254- সংস্করণ1, 2, 3… ;
- প্রভৃতি

একক টেবিলে "আসল" এবং "পরবর্তী" সংস্করণগুলি ধারণ করে

যদিও সব বজায় রাখার BlogStoryVersions মধ্যে একই ব্যক্তি বেস টেবিল সম্ভব, আমি এটা করতে না সুপারিশ কারণ আপনার দুটি স্বতন্ত্র (ধারণাগত) ঘটনা, এইভাবে উপর অবাঞ্ছিত পার্শ্ব প্রতিক্রিয়া রয়েছে ধরনের মিশ হবে

পাশাপাশি ডেটা সীমাবদ্ধতা এবং হেরফের (যৌক্তিক স্তরে)
সম্পর্কিত প্রক্রিয়াজাতকরণ এবং স্টোরেজ (শারীরিক স্তর)।

তবে, আপনি এই শর্তটি অনুসরণ করেছেন যে আপনি সেই ক্রিয়াটি অনুসরণ করছেন, আপনি এখনও উপরে বর্ণিত অনেকগুলি ধারণার সুবিধা নিতে পারেন, যেমন:

একটি যৌগিক কোন int কলাম (এর মধ্যে রয়েছে পি কে BlogStoryNumber) এবং একটি DATETIME এ কলাম (CreatedDateTime );
প্রাসঙ্গিক প্রক্রিয়াগুলি অনুকূলকরণের জন্য সার্ভার ফাংশনগুলির ব্যবহার এবং
লেখক এবং সম্পাদক derivable ভূমিকা ।

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

অনুরূপ দৃশ্য

আপনি সাহায্যের এই প্রশ্নের আমার উত্তরটি খুঁজে পেতে পারেন, যেহেতু আমি পাশাপাশি তুলনামূলক দৃশ্যের সাথে ডিল করার জন্য সম্পর্কিত ডেটাবেজে সাময়িক ক্ষমতা সক্ষম করার প্রস্তাব দিই ose

— MDCCL
সূত্র

2

একটি বিকল্প হ'ল সংস্করণ নরমাল ফর্ম (vnf) ব্যবহার করা। সুবিধার মধ্যে রয়েছে:

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

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

এখানে খুব একই ধরণের সত্তার জন্য ব্যাখ্যা রয়েছে is

আরও বিশদ এখানে স্লাইড উপস্থাপনা এবং একটি সম্পূর্ণ-সম্পূর্ণ-সম্পূর্ণ নথি এখানে পাওয়া যাবে

— TommCatt
সূত্র

1

আপনার সম্পর্ক

(গল্প_আইডি, সংস্করণ_আইডি, সম্পাদক_আইডি, লেখক_আইডি, টাইমস্ট্যাম্প, শিরোনাম, বিষয়বস্তু, কভারিমগ)

3 য় সাধারণ ফর্ম হয় না। আপনার গল্পের প্রতিটি সংস্করণের জন্য লেখক_আইডি সমান। সুতরাং এটি কাটিয়ে উঠতে আপনার দুটি সম্পর্ক দরকার

(গল্প_আইডি, লেখক_আইডি)
(গল্প_আইডি, সংস্করণ_আইডি, সম্পাদক_আইডি, টাইমস্ট্যাম্প, শিরোনাম, বিষয়বস্তু, কভারিমগ)

প্রথম সম্পর্কের story_idচাবিটি, দ্বিতীয় সম্পর্কের কীটি সম্মিলিত চাবি (story_id, version_id)। আপনি যদি সম্মিলিত কী পছন্দ করেন না তবে আপনি কেবল version_idকী হিসাবে ব্যবহার করতে পারেন

— miracle173
সূত্র

2

এটি আমার সমস্যার সমাধান বলে মনে হচ্ছে না, এটি কেবল তাদের জোর দেয়

— ভিক্টর

সুতরাং এটি এমনকি প্রশ্নের উত্তর দেয় না ' author_id ক্ষেত্রের মানটি টেবিলের প্রতিটি সারিতে পুনরাবৃত্তি করছে। আমি কোথায় এবং কীভাবে এটি রাখা উচিত ?

— चमत्कार 173

2

আপনার উত্তর কী বলে আমি তা সত্যই বুঝতে পারি না। এটি হতে পারে কারণ আমি স্থানীয় ইংরেজী স্পিকার নই, আপনি দয়া করে আরও এবং সাধারণ কথায় এটি ব্যাখ্যা করার চেষ্টা করতে পারেন?