डेटाबेस में "सहेजी गई खोज" को संग्रहीत करने का सबसे अच्छा अभ्यास क्या है

Question

मैं एक खोज पृष्ठ पर काम कर रहा हूं जो उपयोगकर्ताओं को बिक्री के लिए घरों की खोज करने की अनुमति देता है। विशिष्ट खोज मानदंडों में मूल्य/ज़िप कोड/# शयनकक्ष/आदि शामिल हैं।

मैं उपयोगकर्ता को इस मानदंड को डेटाबेस में सहेजने और दैनिक घरों को ईमेल करने की अनुमति देना चाहता हूं।

मैं कर सकता या तो:

1) एक स्ट्रिंग में एक "SavedSearch" वस्तु को क्रमानुसार और डेटाबेस के लिए कि बचाने के लिए, तो deserialize के रूप में की जरूरत है।

2) खोज मानदंडों के अनुरूप एक tblSavedSearch में कॉलम की एक सूची है - मूल्य/ज़िप/# बेडरूम/आदि।

मुझे चिंतित है कि यदि मैं विकल्प 1 चुनता हूं, तो मेरा सहेजा गया खोज मानदंड बदल जाएगा और डेटाबेस में खोजी गई वस्तुओं को अमान्य कर देगा, लेकिन विकल्प 2 इष्टतम समाधान की तरह महसूस नहीं करता है।

दूसरों ने इस समस्या को हल कैसे किया है?

Answer 1

मुझे लगता है कि परिणामों में नए जोड़ों को खोजने के लिए आपको दैनिक खोज को फिर से चलाने की आवश्यकता होगी। हो सकता है कि यह सुनिश्चित करना संभव हो कि आप खोज फ़ॉर्म को एक विधि प्राप्त करते हैं ताकि खोज मानदंड URL क्वेरी में क्वेरी स्ट्रिंग के रूप में जोड़ा गया हो और फिर डेटाबेस में संपूर्ण क्वेरीस्ट्रिंग को सहेजें।

तो यदि आपके पास खोज नामक एक खोज प्रोग्राम है।कार्रवाई आप खोज इस तरह का अनुरोध करेंगे:

search.action?price=20000&rooms=3 

आप कीमत = 20000 & कमरे = 3 डेटाबेस में हिस्सा बचा सकता है। इस खोज को पुनः प्राप्त करने के लिए बस क्वेरी स्ट्रिंग को यूआरएल पर संलग्न करें और फिर सेच पेज का अनुरोध करें।

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

Answer 2

यदि मैं सुझाव दे सकता हूं, तो खोज परिणामों के साथ एक HTML पृष्ठ है (यदि इसमें रिकॉर्ड की एक बड़ी संख्या है)। और, डीबी

में खोज मानदंड के साथ पथ को स्टोर करें, यह डीबी से पूछताछ से बचने से बच जाएगा।

संपादित करें: मुझे लगता है कि रिकॉर्ड अक्सर बदल नहीं पाएंगे। यदि ऐसा होता है, तो डेटाबेस में खोज मानदंडों को संग्रहीत करना और उपयोगकर्ता द्वारा पूछे जाने पर पूछताछ करना बेहतर होता है।

Answer 3

तालिका उपयोगकर्ता

तालिका मानदंड (= प्रदान की खोज मापदंड की सूची)

तालिका SavedSearch (उपयोगकर्ता के विस्तार)

तालिका SavedSearchCriteria, SavedSearch का विस्तार, मानदंड संदर्भित, स्तंभ SearchValue रखती है प्रत्येक मानदंड के लिए उपयोगकर्ता द्वारा दर्ज किया गया मान

Answer 4

मैं # 1 के साथ जाऊंगा। यदि आप मानदंड बदलते हुए वास्तव में चिंतित हैं, तो आप इसे "खोज संस्करण" विशेषता के साथ स्टोर कर सकते हैं और आवश्यक होने पर क्रमबद्ध प्रतिनिधित्व को मालिश कर सकते हैं।

# 2 किसी भी प्रकार की उपयोगिता के लिए स्केल नहीं करेगा। उदाहरण के लिए, यदि आप खोज मानदंडों के किसी भी प्रकार के बूलियन समूह को करना चाहते हैं, तो आपकी डीबी स्कीमा आग पर प्रकाश डाल रही है और जंगल में चिल्ला रही है।

मैं आमतौर पर डेटाबेस के अनुक्रमण/खोज से yanking द्वारा खोज समस्याओं को हल करता हूं। आप जो बात कर रहे हैं उसके लिए यह अधिक हो सकता है, लेकिन आरडीबीएमएस खोज के लिए बहुत अच्छा नहीं है।

Answer 5

आप डेटाबेस स्ट्रिंग के रूप में डेटाबेस में गतिशील SQL स्वयं को सहेज सकते हैं। तब आपको सहेजे गए कुंजी-मूल्य जोड़े से WHERE और IN और अन्य SQL को पुन: बनाने की सभी मशीनों को नहीं करना होगा।

आप सहेजे गए एसक्यूएल का उपयोग कर सकते हैं और जब आप ईमेल उत्पन्न करते हैं तो इसे चला सकते हैं।

यदि आपका डेटाबेस डिज़ाइन क्वेरी जानकारी सहेजने के लिए पर्याप्त स्थिर नहीं है, तो आपको खोज डिज़ाइन को तब तक स्थगित करने की आवश्यकता हो सकती है जब तक कि आपका डेटाबेस डिज़ाइन अधिक परिपक्व न हो।

Answer 6

मुझे लगता है कि दोनों दृष्टिकोण समझ में आते हैं, और सभी आवश्यकताओं (वर्तमान और संभावित) पर निर्भर करता है।

उदाहरण के लिए, खोजों की संख्या अधिक है, और यदि आप उन्हें विश्लेषण करने की जरूरत है (जैसे निम्न प्रश्नों के उत्तर "कितनी बार लोग बेडरूम में से प्रत्येक संख्या के लिए खोज करते हैं?"), खोजों और उनके मानदंडों के संचय करता है, तो संबंधपरक रूप में (आपका विकल्प # 2) उपयुक्त से अधिक होगा।

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

Answer 7

मैं भी समाधान के लिए डेटा दृश्यता जोड़ना होगा ... साथ ही टेबल उपयोगकर्ता - उपयोगकर्ताओं टेबल भूमिकाएँ होती हैं - एक उपयोगकर्ता एक सत्र में एक या अधिक भूमिकाओं हो सकता है - भूमिकाओं n db टेबल UserRoles शामिल तालिका मेटा कॉलम - डीबी तालिका नियंत्रक मेटा कॉलम में सभी कॉलम/विचारों के लिए मेटा जानकारी शामिल है - प्रति उपयोगकर्ता मेटा कॉलम प्रति दृश्यता, उपयोगकर्ताओं को हमेशा इस के माध्यम से वास्तविक डेटा तक पहुंचना होगा (INNER JOIN) तालिका तालिका दृश्य देखें - तालिका या पर सहेजने के लिए देखें तालिका सहेजे गए खोज - गुण नियंत्रक हैं मेटाकॉलम्स आईडी, TableViewToSearchId, सहेजे गए खोज स्ट्रिंग - यदि भूमिका में विशेषता का उपयोग नहीं किया गया है इसे खाली परिणाम सेट

Answer 8

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

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

1. यदि उपयोगकर्ता एक नया खोज मानदंड संपादित करना चाहता है तो हमें एक बड़े पैमाने पर स्ट्रिंग मैनिपुलेशन करना होगा।

2. जटिल खोज मानदंड संग्रहीत करना एक मुद्दा होगा। अगर मैं एक जटिल और शर्त को बचाना चाहता हूं तो क्या होगा। (एक्सएमएल में, क्योंकि यह पहले से ही पदानुक्रमित है, मैं बस अपनी सारी जानकारी को स्टोर कर सकता हूं)।

3. समाधान स्केलेबल हो सकता है और एसक्यूएल इंजेक्शन हमलों से आपके आवेदन को भी स्वच्छ कर देगा।

4. चूंकि एक्सएमएल एक परिपक्व तकनीक है, इसलिए आप इसे बैक एंड पर पास करने से पहले सत्यापन करने के लिए भी उपयोग कर सकते हैं।