MySQL के साथ संस्करण प्रणाली लागू करना

Question

मुझे पता है कि यह यहाँ और यहाँ पूछा गया है , लेकिन मुझे एक अलग संभव कार्यान्वयन के साथ एक ही विचार है और मुझे कुछ मदद चाहिए।

प्रारंभ में 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;
  }
}

कोड हैक में लिखा गया है , और मूल रूप से उनके जवाब में @Scott द्वारा PHP में लिखा गया था ।

क्षेत्र author_idऔर अलग editor_id हो सकते हैं , क्योंकि किसी की कहानियों को संपादित करने के लिए पर्याप्त अनुमतियों वाले उपयोगकर्ता हैं।

Answer 1

परिदृश्य का विश्लेषण करना-जो अस्थायी डेटाबेस के रूप में ज्ञात विषय से जुड़ी विशेषताओं को प्रस्तुत करता है - एक वैचारिक दृष्टिकोण से, यह निर्धारित कर सकता है कि: (ए) "वर्तमान" ब्लॉग स्टोरी संस्करण और (बी) "अतीत" ब्लॉग स्टोरी संस्करण , हालांकि बहुत सदृश, विभिन्न प्रकार के निकाय हैं।

इसके अलावा, जब अमूर्त के तार्किक स्तर पर काम करते हैं, तो अलग-अलग तालिकाओं में तथ्यों (पंक्तियों द्वारा दर्शाए गए) को अलग-अलग तालिकाओं में बनाए रखा जाना चाहिए। विचाराधीन मामले में, तब भी जब काफी समान (i) "वर्तमान" संस्करणों के बारे में तथ्य "अतीत" संस्करणों के बारे में (ii) तथ्यों से भिन्न हैं ।

इसलिए मैं दो तालिकाओं के माध्यम से स्थिति का प्रबंधन करने की सलाह देता हूं:

• ब्लॉग स्टोरीज़ के "वर्तमान" या "वर्तमान" संस्करणों के लिए विशेष रूप से समर्पित एक , और

• एक जो अलग है, लेकिन दूसरे के साथ भी जुड़ा हुआ है, सभी "पिछले" या "पिछले" संस्करणों के लिए ;

प्रत्येक (1) स्तंभों की थोड़ी अलग संख्या और (2) बाधाओं का एक अलग समूह।

वैचारिक परत पर वापस, मैं मानता हूं कि आपके व्यवसाय के माहौल में - लेखक और संपादक ऐसी धारणाएं हैं जिन्हें रोल्स के रूप में चित्रित किया जा सकता है जो एक उपयोगकर्ता द्वारा खेला जा सकता है , और ये महत्वपूर्ण पहलू डेटा व्युत्पत्ति (तार्किक-स्तरीय हेरफेर संचालन के माध्यम से) पर निर्भर करते हैं और कम्प्यूटरीकृत सूचना प्रणाली के बाहरी स्तर पर (एक या अधिक एप्लिकेशन प्रोग्राम की सहायता से, ब्लॉग स्टोरीज़ पाठकों और लेखकों द्वारा व्याख्या की गई )।

मैं इन सभी कारकों और अन्य प्रासंगिक बिंदुओं का विवरण निम्नानुसार दूंगा।

व्यापार नियम

आपकी आवश्यकताओं के बारे में मेरी समझ के अनुसार, निम्नलिखित व्यवसाय नियम योगों (संबंधित इकाई प्रकारों और उनके प्रकार के अंतर्संबंधों के संदर्भ में एक साथ रखे गए) संबंधित वैचारिक स्कीमा को स्थापित करने में विशेष रूप से सहायक होते हैं :

• एक उपयोगकर्ता शून्य-एक या कई BlogStories लिखता है
• एक BlogStory शून्य-एक-या कई BlogStoryVersions रखती है
• एक उपयोगकर्ता ने शून्य-एक-या कई BlogStoryVersions लिखा

एक्सपोजिटरी IDEF1X आरेख

नतीजतन, एक ग्राफिकल डिवाइस के आधार पर अपने सुझाव को उजागर करने के लिए, मैंने एक नमूना IDEF1X ^एक आरेख बनाया है जो ऊपर दिए गए व्यवसाय नियमों से बना है और अन्य विशेषताएं जो उचित लगती हैं। यह चित्र 1 में दिखाया गया है :

BlogStory और BlogStoryVersion को दो अलग-अलग इकाई प्रकारों के रूप में क्यों माना जाता है?

इसलिये:

• एक BlogStoryVersion उदाहरण (यानी, एक "अतीत" एक) हमेशा एक UpdatedDateTime संपत्ति के लिए एक मूल्य रखता है , जबकि एक BlogStory घटना (यानी, एक "वर्तमान" एक) कभी नहीं रखती है।

• इसके अलावा, उन प्रकारों की संस्थाओं को विशिष्ट रूप से दो अलग-अलग गुणों के मूल्यों द्वारा पहचाना जाता है: BlogStoryNumber ( BlogStory घटनाओं के मामले में ), और BlogStoryNumber प्लस CreatedDateTime ( BlogStoryVersion उदाहरणों के मामले में )।

---

_{सूचना मॉडलिंग ( आईडीईएफ 1 एक्स ) के लिए ^एक एकीकरण परिभाषा एक उच्च अनुशंसित डेटा मॉडलिंग तकनीक है जिसेदिसंबर 1993 में यूनाइटेड स्टेट्स नेशनल इंस्टीट्यूट ऑफ स्टैंडर्ड एंड टेक्नोलॉजी (एनआईएसटी)द्वारा मानक के रूप में स्थापित किया गया था। यह जल्दी सैद्धांतिक सामग्री पर आधारित है द्वारा लेखक एकमात्र प्रवर्तक की संबंधपरक मॉडल , यानी, डॉ एफई कॉड ; डॉ। पीपी चेन द्वारा विकसित डेटाके इकाई-संबंध दृश्य पर; और रॉबर्ट जी ब्राउन द्वारा बनाई गई लॉजिकल डेटाबेस डिजाइन तकनीक पर भी।}

---

इलस्ट्रेटिव लॉजिकल एसक्यूएल-डीडीएल लेआउट

फिर, पहले प्रस्तुत किए गए वैचारिक विश्लेषण के आधार पर, मैंने नीचे दिए गए तार्किक स्तर के डिजाइन की घोषणा की:

-- 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.
);

MySQL 5.6 पर चलने वाले इस SQL ​​फिडेल में परीक्षण किया गया।

BlogStoryतालिका

जैसा कि आप डेमो डिज़ाइन में देख सकते हैं, मैंने BlogStoryINT डेटाटाइप के साथ PRIMARY KEY (संक्षिप्तता के लिए PK) कॉलम को परिभाषित किया है । इस संबंध में, आप एक अंतर्निहित स्वचालित प्रक्रिया को ठीक करना पसंद कर सकते हैं जो प्रत्येक स्तंभ प्रविष्टि में ऐसे स्तंभ के लिए एक संख्यात्मक मान उत्पन्न और असाइन करता है। यदि आपको मानों के इस सेट में कभी-कभी अंतराल छोड़ने का मन नहीं है, तो आप AUTO_INCREMENT विशेषता को नियोजित कर सकते हैं , जिसका उपयोग आमतौर पर MySQL वातावरण में किया जाता है।

अपने सभी व्यक्तिगत BlogStory.CreatedDateTimeडेटा बिंदुओं को दर्ज करते समय , आप अब () फ़ंक्शन का उपयोग कर सकते हैं , जो डेटाबेस सर्वर में मौजूद दिनांक और समय मानों को सटीक INSERT ऑपरेशन इंस्टेंट पर लौटाता है । मेरे लिए, बाहरी दिनचर्या के उपयोग की तुलना में यह प्रथा निश्चित रूप से अधिक उपयुक्त और त्रुटियों से ग्रस्त है।

बशर्ते, जैसा कि (अब हटाए गए) टिप्पणियों में चर्चा की गई हो, आप BlogStory.Titleडुप्लिकेट मान बनाए रखने की संभावना से बचना चाहते हैं, आपको इस कॉलम के लिए एक UNIQUE बाधा स्थापित करनी होगी । इस तथ्य के कारण कि किसी दिए गए शीर्षक को कई (या यहां तक ​​कि सभी) "पिछले" BlogStoryVersions द्वारा साझा किया जा सकता है , तो कॉलम के लिए एक UNIQUE बाधा स्थापित नहीं की जानी चाहिए BlogStoryVersion.Title।

यदि आपको "सॉफ्ट" या "तार्किक" DELETE कार्यक्षमता प्रदान करने की आवश्यकता है, तो मैंने BlogStory.IsActiveटाइप BIT (1) (हालांकि एक टिनिट का उपयोग किया जा सकता है) के कॉलम को शामिल किया।

BlogStoryVersionतालिका के बारे में विवरण

दूसरी ओर, BlogStoryVersionतालिका का PK (a) BlogStoryNumberऔर (b) नाम के एक कॉलम से बना CreatedDateTimeहै, निश्चित रूप से, सटीक तात्कालिकता को चिह्नित करता है जिसमें एक BlogStoryपंक्ति INSERT से गुजरती है।

BlogStoryVersion.BlogStoryNumberइसके अलावा, पीके का हिस्सा होने के नाते, इसे एक विदेशी कुंजी (एफके) के रूप में भी विवश किया गया है जो संदर्भ BlogStory.BlogStoryNumber, एक कॉन्फ़िगरेशन है जो इन दो तालिकाओं की पंक्तियों के बीच संदर्भ अखंडता को लागू करता है । इस संबंध में, एक स्वचालित पीढ़ी को लागू करना BlogStoryVersion.BlogStoryNumberआवश्यक नहीं है क्योंकि, एफके के रूप में सेट होने पर, इस कॉलम में शामिल मानों को पहले से संबंधित BlogStory.BlogStoryNumberकाउंटर में संलग्न लोगों से "तैयार" किया जाना चाहिए ।

BlogStoryVersion.UpdatedDateTimeस्तंभ से संपर्क करना चाहिए, के रूप में उम्मीद, कुछ ही समय में बिंदु जब एक BlogStoryपंक्ति संशोधित किया गया था और इसके परिणाम के रूप में, करने के लिए जोड़ा BlogStoryVersionतालिका। इसलिए, आप इस स्थिति में भी अब () फ़ंक्शन का उपयोग कर सकते हैं।

इंटरवल के बीच समझा BlogStoryVersion.CreatedDateTimeऔर BlogStoryVersion.UpdatedDateTimeपूरे व्यक्त करता है अवधि जिसके दौरान एक BlogStoryपंक्ति "वर्तमान" या "वर्तमान" था।

एक Versionकॉलम के लिए विचार

यह BlogStoryVersion.CreatedDateTimeउस स्तंभ के रूप में सोचने के लिए उपयोगी हो सकता है जो एक BlogStory के विशेष "अतीत" संस्करण का प्रतिनिधित्व करने वाले मूल्य को रखता है । मैं इस से बहुत अधिक फायदेमंद है VersionIdया VersionCode, यह इस अर्थ में उपयोगकर्ता-मित्रता है कि लोग समय की अवधारणाओं से अधिक परिचित हैं। उदाहरण के लिए, ब्लॉग लेखक या पाठक BlogStoryVersion को निम्न प्रकार से फैशन में संदर्भित कर सकते हैं :

• "मैं उन विशिष्ट देखना चाहता हूँ संस्करण की BlogStory से पहचान संख्या 1750 है कि गया था बनाया गया पर 26 August 2015पर 9:30"।

लेखक और संपादक भूमिका: डाटा व्युत्पत्ति और व्याख्या

इस दृष्टिकोण के साथ, आप आसानी से पहचान सकते हैं कि कौन AuthorIdएक ठोस BlogStory के "मूल" को रखता है ताकि MIN () फ़ंक्शन को लागू करने के पुण्य से तालिका के कुछ निश्चित "शुरुआती" संस्करण का चयन किया जा सके ।BlogStoryIdBlogStoryVersionBlogStoryVersion.CreatedDateTime

इस तरह, प्रत्येक BlogStoryVersion.AuthorIdमूल्य में निहित सभी "बाद में" या "सफल" संस्करण पंक्तियों से संकेत मिलता है, स्वाभाविक रूप से, लेखक संबंधित के पहचानकर्ता संस्करण हाथ में है, लेकिन एक भी कह सकते हैं कि इस तरह के एक मूल्य के एक ही समय में, है, दर्शाने भूमिका शामिल द्वारा निभाई उपयोगकर्ता के रूप में संपादक "मूल" के संस्करण एक की BlogStory ।

हां, किसी दिए गए AuthorIdमूल्य को कई BlogStoryVersionपंक्तियों द्वारा साझा किया जा सकता है , लेकिन यह वास्तव में जानकारी का एक टुकड़ा है जो प्रत्येक संस्करण के बारे में बहुत महत्वपूर्ण बात बताता है , इसलिए कहा गया डेटा की पुनरावृत्ति कोई समस्या नहीं है।

DATETIME कॉलम का प्रारूप

DATETIME डेटा प्रकार के लिए, हां, आप सही हैं, " MySQL पुनर्प्राप्त करता है और DATETIME मानों को ' YYYY-MM-DD HH:MM:SS' प्रारूप " में प्रदर्शित करता है , लेकिन आप आत्मविश्वास से इस तरीके से प्रासंगिक डेटा दर्ज कर सकते हैं, और जब आपको एक क्वेरी करनी होती है, तो आपको बस करना होगा अन्य बातों के अलावा, अंतर्निहित DATE और TIME फ़ंक्शंस का उपयोग अपने उपयोगकर्ताओं के लिए उपयुक्त प्रारूप में संबंधित मान दिखाते हैं। या आप निश्चित रूप से अपने एप्लिकेशन प्रोग्राम्स (कोडों) के माध्यम से इस तरह के डेटा फॉर्मेटिंग को अंजाम दे सकते हैं।

BlogStoryअद्यतन संचालन के निहितार्थ

हर बार जब कोई BlogStoryपंक्ति एक अद्यतन करता है, तो आपको यह सुनिश्चित करना होगा कि जब तक संशोधन नहीं हुआ था तब तक संबंधित मूल्य "मौजूद" थे और तब BlogStoryVersionतालिका में सम्मिलित किया गया था । इस प्रकार, मैं अत्यधिक एक एकल ACID परिवहन के भीतर इन कार्यों को पूरा करने का सुझाव देता हूं कि उन्हें कार्य की एक इकाई के रूप में माना जाता है। आप TRIGGERS को भी रोजगार दे सकते हैं, लेकिन वे चीजों को बेकार कर देते हैं, इसलिए बोलने के लिए।

एक कॉलम VersionIdया परिचयVersionCode

यदि आप BlogStoryVersions को अलग करने के लिए BlogStory.VersionIdया BlogStory.VersionCodeकॉलम को शामिल करने के लिए (व्यावसायिक परिस्थितियों या व्यक्तिगत प्राथमिकता के कारण) चुनते हैं , तो आपको निम्नलिखित संभावनाओं को इंगित करना चाहिए:

1. एक VersionCode(i) पूरे में अद्वितीय होना आवश्यक किया जा सकता है BlogStoryऔर मेज भी (ii) BlogStoryVersion।

   इसलिए, आपको प्रत्येक मान उत्पन्न करने और असाइन करने के लिए एक सावधानीपूर्वक परीक्षण और पूरी तरह से विश्वसनीय विधि को लागू करना होगा Code।

2. हो सकता है, VersionCodeमूल्यों को अलग-अलग BlogStoryपंक्तियों में दोहराया जा सकता है , लेकिन कभी भी एक साथ नकल नहीं की जाती है BlogStoryNumber। जैसे, आप कर सकते हैं:

   • एक BlogStoryNumber 3- संस्करण83o7c5c और, एक साथ,
   • एक BlogStoryNumber 86- संस्करण83o7c5c और
   • एक BlogStoryNumber 958- संस्करण83o7c5c ।

बाद की संभावना एक और विकल्प खोलती है:

3. एक के VersionNumberलिए रखते हुए BlogStories, तो वहाँ हो सकता है:

   • BlogStoryNumber 23- संस्करण1, 2, 3… ;
   • BlogStoryNumber 650- संस्करण1, 2, 3… ;
   • BlogStoryNumber 2254- संस्करण1, 2, 3… ;
   • आदि।

एक ही तालिका में "मूल" और "बाद के" संस्करण पकड़े

यद्यपि एक ही व्यक्तिगत आधार तालिका में सभी BlogStoryVersions को बनाए रखना संभव है, लेकिन मैं आपको ऐसा नहीं करने का सुझाव देता हूं क्योंकि आप दो अलग-अलग (वैचारिक) प्रकार के तथ्यों का मिश्रण कर रहे होंगे, जिनके इस प्रकार अवांछनीय दुष्प्रभाव हैं

• डेटा की कमी और हेरफेर (तार्किक स्तर पर), साथ में
• संबंधित प्रसंस्करण और भंडारण (भौतिक स्तर पर)।

लेकिन, जिस शर्त पर आप कार्रवाई के उस पाठ्यक्रम का पालन करना चाहते हैं, आप ऊपर दिए गए कई विचारों का लाभ उठा सकते हैं, जैसे:

• एक समग्र पीके जिसमें एक इंट कॉलम ( BlogStoryNumber) और एक डैट टाइम कॉलम ( CreatedDateTime) शामिल है;
• प्रासंगिक प्रक्रियाओं का अनुकूलन करने के लिए सर्वर कार्यों का उपयोग , और
• लेखक और संपादक व्युत्पत्ति भूमिकाओं ।

यह देखते हुए कि इस तरह के दृष्टिकोण के साथ आगे बढ़ते हुए, "नए" संस्करण के रूप में जैसे ही एक BlogStoryNumberमूल्य डुप्लिकेट किया जाएगा , एक विकल्प है कि और आप मूल्यांकन कर सकते हैं (जो पिछले अनुभाग में उल्लिखित लोगों के लिए बहुत समान है) एक पीके स्थापित कर रहा है स्तंभों से बना और , इस तरीके से आप विशिष्ट रूप से एक BlogStory के प्रत्येक संस्करण की पहचान कर सकेंगे । और आप और भी के संयोजन के साथ कोशिश कर सकते हैं।BlogStoryBlogStoryNumberVersionCodeBlogStoryNumberVersionNumber

इसी तरह का परिदृश्य

आप मदद के इस सवाल का जवाब पा सकते हैं , क्योंकि मैं तुलनात्मक परिदृश्य से निपटने के लिए संबंधित डेटाबेस में अस्थायी क्षमताओं को सक्षम करने का प्रस्ताव देता हूं ।

Answer 2

एक विकल्प संस्करण सामान्य रूप (vnf) का उपयोग करना है। फायदे में शामिल हैं:

• वर्तमान डेटा और सभी पिछले डेटा एक ही तालिका में रहते हैं।
• उसी क्वेरी का उपयोग वर्तमान डेटा या डेटा को पुनः प्राप्त करने के लिए किया जाता है जो किसी विशेष तिथि के रूप में वर्तमान था।
• संस्करण किए गए डेटा के लिए विदेशी प्रमुख संदर्भ अनवर्सडेड डेटा के समान ही काम करते हैं।

आपके मामले में एक अतिरिक्त लाभ, जैसा कि संस्करणित डेटा को विशिष्ट दिनांक (दिनांक में परिवर्तन किया गया था) को कुंजी के भाग के रूप में विशिष्ट रूप से पहचाना जाता है, एक अलग संस्करण_ड फ़ील्ड की आवश्यकता नहीं है।

यहां एक बहुत ही समान इकाई के लिए एक स्पष्टीकरण दिया गया है।

अधिक विवरण यहां एक स्लाइड प्रस्तुति में और एक काफी-पूर्ण दस्तावेज यहां पाया जा सकता है

Answer 3

आपका रिश्ता

(story_id, version_id, editor_id, author_id, टाइमस्टैम्प, शीर्षक, सामग्री, कवरिमग)

तीसरे सामान्य रूप में नहीं है। आपकी कहानी के हर संस्करण के लिए author_id समान है। तो इससे उबरने के लिए आपको दो संबंधों की जरूरत है

(story_id, author_id)
(story_id, version_id, editor_id, टाइमस्टैम्प, शीर्षक, सामग्री, कवरिमग)

पहले संबंध story_idकी कुंजी है, दूसरे संबंध की कुंजी संयुक्त कुंजी है (story_id, version_id)। यदि आपको संयुक्त कुंजी पसंद नहीं है, तो आप केवल version_idकुंजी के रूप में उपयोग कर सकते हैं

Comments

यह मेरी समस्या को हल करने के लिए प्रतीत नहीं होता है, यह सिर्फ उन्हें जोर देता है

— विक्टर

तो यह भी जवाब नहीं है ' author_id तालिका के प्रत्येक पंक्ति में फ़ील्ड मान दोहरा रहा है। मुझे कहाँ और कैसे रखना चाहिए '?

— चमत्कार 173

मुझे वास्तव में समझ नहीं आ रहा है कि आपका उत्तर क्या है। यह हो सकता है क्योंकि मैं एक देशी अंग्रेजी वक्ता नहीं हूं, इसलिए क्या आप इसे और सरल और सरल शब्दों में समझाने की कोशिश कर सकते हैं, कृपया?

— विक्टर

इसका मतलब यह है कि आपको लेखक_आईडी नंबर की पुनरावृत्ति से बचना चाहिए (यदि कहानी_ शब्द दो पंक्तियों के बराबर है, तो उनका लेखक_ भी बराबर है) और अपनी तालिका को दो तालिकाओं में विभाजित करें जैसा कि मेरी पोस्ट में वर्णित है। तो आप author_id की पुनरावृत्ति से बच सकते हैं।

— चमत्कार 173