ई-कॉमर्स के लिए पोस्टग्रेस्क्ल डेटाबेस डिज़ाइन

केवल जूतों को देखते हुए, आपके पास एक इकाई है:जूते। इसकी दो प्रत्यक्ष विशेषताएं हैं:आकार और रंग। इनमें से प्रत्येक विशेषता के डोमेन को कड़ाई से परिभाषित किया जाना चाहिए, जो उनके लिए लुकअप टेबल को इंगित करता है। दो अप्रत्यक्ष विशेषताएं हैं, कीमत और मात्रा, लेकिन ये जूते की तुलना में आकार/रंग के प्रत्येक संयोजन की अधिक विशेषताएं हैं।

यह एक इकाई तालिका का सुझाव देता है:जूते; दो लुकअप टेबल:आकार और रंग; और एक थ्री-वे इंटरसेक्शन टेबल:शू स्टाइल्स:

create table ShoeStyles(
    ShoeID   int       not null,
    SizeID   smallint  not null,
    ColorID  char( 1 ) not null,
    Price    currency,
    Qty      int       not null default 0,
    constraint FK_ShoeStyles_Shoe foreign key references Shoes( ID ),
    constraint FK_ShoeStyles_Size foreign key references Sizes( ID ),
    constraint FK_ShoeStyles_Color foreign key references Colors( ID ),
    constraint PK_ShoeStyles primary key( ShoeID, SizeID, ColorID )
);

इस प्रकार, उदाहरण के लिए, संयोजन ('पेनी लोफर', '10 1/2', 'टैन') के हाथ में एक विशेष कीमत और मात्रा होगी। आकार 11 टैन की अपनी कीमत और मात्रा 10 1/2 बरगंडी के रूप में होगी।

मैं एक ऐसे दृश्य की अनुशंसा करता हूं जो तालिकाओं से जुड़ता है और परिणामों को अधिक उपयोगी रूप में प्रस्तुत करता है जैसा कि ऊपर दिखाया गया है, कहें, (15, 4, 3, 45.00, 175)। दृश्य पर ट्रिगर दृश्य के माध्यम से एप्लिकेशन द्वारा सभी एक्सेस की अनुमति दे सकते हैं ताकि ऐप डेटा के भौतिक लेआउट से अनजान बना रहे। इस तरह के विचार एक अत्यंत शक्तिशाली उपकरण हैं जो अंतर्निहित डेटा और ऐप की मजबूती और रखरखाव के लिए महत्वपूर्ण रूप से जोड़ते हैं, लेकिन जिनका बहुत कम उपयोग किया जाता है।