डेटा को कैसे स्टोर करें जिसका प्रकार mysql में संख्यात्मक, दिनांक या स्ट्रिंग हो सकता है

मैंने औपचारिक अध्ययन नहीं किया है, लेकिन मेरे अपने अनुभव से मुझे लगता है कि 80% से अधिक डेटाबेस डिज़ाइन त्रुटियां सबसे महत्वपूर्ण (यदि न केवल) विचार के रूप में प्रदर्शन के साथ डिजाइनिंग से उत्पन्न होती हैं।

यदि एक अच्छा डिज़ाइन एकाधिक तालिकाओं के लिए कहता है, तो एकाधिक तालिकाएँ बनाएँ। स्वचालित रूप से यह न मानें कि जुड़ने से बचना चाहिए। वे शायद ही कभी प्रदर्शन समस्याओं का असली कारण होते हैं।

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

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

यह एक मानक "प्रकार/उपप्रकार" पैटर्न में फिट प्रतीत होता है, जिसमें "अवलोकन" प्रविष्टि प्रकार होती है और प्रत्येक प्रकार या प्रकार का अवलोकन उपप्रकार होता है, और कुछ प्रकार के संकेतक फ़ील्ड का सुझाव देता है जैसे:

create table Observations(
   ...,
   ObservationKind  char( 1 ) check( ObservationKind in( 'M', 'E', 'S' )),
   ...
);

लेकिन चेक बाधा में इस तरह की सूची को हार्डकोड करना बहुत कम रखरखाव स्तर है। यह स्कीमा का हिस्सा बन जाता है और इसे केवल डीडीएल स्टेटमेंट के साथ बदला जा सकता है। ऐसा कुछ नहीं है जिसे आपका डीबीए आगे देख रहा है।

तो अवलोकनों के प्रकार उनकी अपनी लुकअप तालिका में रखें:

ID  Name         Meaning
==  ===========  =======
M   Measurement  The value of some system metric (CPU_Usage).
E   Event        An event has been detected.
S   Status       A change in a status has been detected.

(चार फ़ील्ड इंट या स्मालिंट भी हो सकता है। मैं चित्रण के लिए यहां चार का उपयोग करता हूं।)

फिर अवलोकन तालिका को एक PK और उन विशेषताओं से भरें जो सभी अवलोकनों के लिए समान होंगी।

create table Observations(
   ID               int identity primary key,
   ObservationKind  char( 1 ) not null,
   DateEntered      date not null,
   ...,
   constraint FK_ObservationKind foreign key( ObservationKind )
      references ObservationKinds( ID ),
   constraint UQ_ObservationIDKind( ID, ObservationKind )
);

किंड फील्ड और पीके के संयोजन पर एक अद्वितीय इंडेक्स बनाना अजीब लग सकता है, जो अपने आप में अद्वितीय है, लेकिन मेरे साथ एक पल के लिए सहन करें।

अब प्रत्येक प्रकार या उपप्रकार को अपनी तालिका मिलती है। ध्यान दें कि प्रत्येक प्रकार के अवलोकन को एक तालिका मिलती है, न कि डेटा प्रकार।

create table Measurements(
    ID                   int not null,
    ObservationKind      char( 1 ) check( ObservationKind = 'M' ),
    Name                 varchar( 32 ) not null, -- Such as "CPU Usage"
    Value                double not null, -- such as 55.00
    ...,  -- other attributes of Measurement observations
    constraint PK_Measurements primary key( ID, ObservationKind ),
    constraint FK_Measurements_Observations foreign key( ID, ObservationKind )
        references Observations( ID, ObservationKind )
);

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

आइए एक उदाहरण टपल की जांच करें जो माप तालिका में मौजूद हो सकता है:

ID    ObservationKind  Name       Value  ...
====  ===============  =========  =====
1001  M                CPU Usage  55.0   ...

इस तालिका में इस टपल के अस्तित्व के लिए, एक मिलान प्रविष्टि पहले अवलोकन तालिका में 1001 के आईडी मान और 'एम' के अवलोकन प्रकार मान के साथ मौजूद होनी चाहिए। 1001 के आईडी मान के साथ कोई अन्य प्रविष्टि या तो अवलोकन तालिका या माप तालिका में मौजूद नहीं हो सकती है और किसी भी अन्य "प्रकार" तालिका (ईवेंट, स्थिति) में मौजूद नहीं हो सकती है। यह सभी प्रकार की तालिकाओं के लिए समान रूप से कार्य करता है।

मैं आगे प्रत्येक प्रकार के अवलोकन के लिए एक दृश्य बनाने की अनुशंसा करता हूं जो मुख्य अवलोकन तालिका के साथ प्रत्येक प्रकार का जुड़ाव प्रदान करेगा:

create view MeasurementObservations as
    select ...
    from   Observations o
    join   Measurements m
        on m.ID = o.ID;

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

अब एक अन्य प्रकार के अवलोकन के निर्माण, जैसे "त्रुटि", में ऑब्जर्वेशनकिंड्स तालिका में एक सरल सम्मिलित कथन शामिल है:

F   Fault        A fault or error has been detected.

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