- 20MB से कम आकार का हल्का लेकिन शक्तिशाली, user-friendly डेटाबेस प्रबंधन टूल
- PostgreSQL, MySQL, SQLite3, MongoDB, Redis, MariaDB, ElasticSearch
- जटिल SQL लिखने के बजाय natural language में डेटा query और management संभव: Ollama, ChatGPT, Anthropic के साथ integration
- फ्रंटएंड table virtualization सपोर्ट
- डेटाबेस schema को ग्राफ़ के रूप में विज़ुअलाइज़ करना
- इंटरफ़ेस में सीधे (inline) डेटा संशोधन और परिणाम preview
- Scratchpad: Jupyter Notebook शैली का डेटाबेस query इंटरफ़ेस
- Go में विकसित, इसलिए तेज़, और Docker का उपयोग करके आसानी से install किया जा सकता है
- अन्य टूल्स के साथ संबंध
- Adminer से प्रेरित, हल्केपन और उपयोग में आसानी के आधार पर UX और डेटा visualization को मजबूत करने वाले टूल के रूप में विकसित
- DBeaver समृद्ध फीचर्स देता है लेकिन उसकी resource requirement अधिक है, जबकि WhoDB हल्का और कुशल है तथा छोटे environment में भी अच्छी तरह काम करता है
8 टिप्पणियां
प्रॉम्प्ट यहाँ परिभाषित हैं: https://github.com/clidey/whodb/blob/main/core/src/common/chat.go प्राकृतिक भाषा के ज़रिए कमांड देने की सुविधा वास्तव में बहुत ही बुनियादी स्तर पर लागू की गई है।
मैंने इसे ollama phi4 से जोड़कर साधारण DB सेटअप किया और कमांड चलाकर देखा, तो लगभग 10 कमांड सही तरह से चल गए। इसके लिए किसकी तारीफ़ करनी चाहिए, समझ नहीं आ रहा।
मैंने डेमो इस्तेमाल करके देखा, और इसमें सुधार की काफी गुंजाइश दिखी। इसे खुद से शक्तिशाली कहना अभी काफी जल्दबाज़ी लगती है।
मुख्य फीचर सूची को फिर से देखा तो उसमें inline editing साफ़ तौर पर लिखा है। प्रोजेक्ट विवरण में लिखे inline editing से क्या मतलब है, यह थोड़ा अस्पष्ट लग रहा है।
क्या यह LLM के ज़रिए natural language में कमांड देने वाला है?
फिर तो इसे live DB पर इस्तेमाल नहीं कर सकते...
आम तौर पर sql बनाते समय टेबल संरचना, संबंध, फ़ील्ड विवरण आदि का उपयोग किया जाता है, इसलिए शायद मेरे डेटा के सीखने में इस्तेमाल होने की संभावना नहीं है। साथ ही, OpenAI API के बारे में यह भी कहा गया है कि वह request डेटा से training नहीं करता। फिर भी अगर आपको चिंता हो, तो आप local LLM का उपयोग कर सकते हैं 👏
अरे, इस्तेमाल करके देखा तो यह query बनाने वाला तरीका नहीं है 😂 असली DB में इसका इस्तेमाल करना सच में मुश्किल होगा
संवेदनशील काम, खासकर डेटा को modify/delete करना या table structure बदलने जैसे काम, natural language के ज़रिए LLM से कराना अभी भी काफ़ी जोखिमभरा लगता है.
आख़िरकार, execution से पहले generated SQL की review करनी ही पड़ेगी.
मुझे लगता है कि मूल टिप्पणी का मुख्य बिंदु वह नहीं है।
प्रोडक्शन में चल रहे db में सिर्फ
selectसे भी लोड और lock आदि की वजह से समस्या हो सकती है, इसलिए ऐसा कहना लगता है कि LLM के जरिए निकाली गई query को सीधे इस्तेमाल करने में जोखिम है।