ما سوالات را داخل سوالات شما قرار دادیم
تیم متابیس
سازنده پرسوجوی Metabase به شما امکان اجرای پرسوجوهای ساده روی یک جدول واحد در پایگاه داده شما را میدهد. در این اصطلاح اساسی، ما توانایی کشیدن اطلاعات از جداول مرتبط با Foreign Keys، تغییر ستونها، و ایجاد ستونهای جدید بر اساس عبارات ریاضی را اضافه کردهایم. با این حال، این الگوی اصلی بوده است که ما به آن پایبند بودهایم، و در terms of usability بازدهی داشته است.
ما دریافتیم که در حالی که به اندازه برخی ابزارهای دیگر قدرت ارائه نمیدهد، به ۸۰٪ از کاربران غیرفنی امکان میدهد ۲۰٪ از سوالات خود را بپرسند در حالی که همه چیز دیگر روی این تمرکز دارد که به یک الیت ۵٪ از شرکت امکان بدهد ۸۰٪ از سوالات خود را بپرسند.
با ساخت روی این، با انتشار جدید ما، اکنون میتوانید از یک سوال ذخیره شده به عنوان یک "جدول" در سازنده پرسوجوی ما استفاده کنید.
چرا این مفید است؟
مورد استفاده واضح این است که نتایج سوال دیگری را تجمیع یا برش و تکهتکه کنید، به عنوان مثال، "میانگین درآمد روزانه". جالبتر، میتوانید از سوالات ذخیره شده — چه GUI یا SQL — به عنوان نقطه شروع برای یک سوال جدید استفاده کنید.
این به شما امکان میدهد از SQL برای تولید یک نتیجه میانی پیچیده (که به عنوان یک زیرپرسوجو نیز شناخته میشود) استفاده کنید و سپس از آن در سازنده پرسوجو استفاده کنید.
ابزارهای دیگر شما را مجبور میکنند که یا قالبهای SQL واقعاً عظیم بسازید، یا از یک زبان اختصاصی YAML عجیب برای تولید آثار "سنگین" که کاربران غیرفنی شما میتوانند استفاده کنند. اما با سوالات تو در تو، میتوانید از SQL استاندارد برای ایجاد این زیرپرسوجوها استفاده کنید و سپس از سازنده پرسوجو استفاده کنید. اگر با پیشبینی انجام شود، این به این معنی است که میتوانید از SQL سبک و vanilla و سازنده پرسوجو برای در معرض قرار دادن رابطهایی استفاده کنید که در غیر این صورت نیاز به SQL یا YAML عجیب زیادی داشت.
در مورد joinها چطور؟
اکنون، اگر میخواهید سوالی بپرسید که شامل دو یا چند جدول است، از یک join در زیرسوال تو در تو استفاده کنید. به جای ایجاد یک رابط پیچیده برای تسهیل joinها، میتوانید فقط از SQL استاندارد استفاده کنید. در حالی که پیچیدگیهای joinهای inner، outer، left، right، up، down و همه اطراف واقعاً ظریف است و میتواند پیچیده باشد، سینتکس SQL واقعی نسبتاً ساده است. به جای اختراع مجدد یک چرخ گرافیکی، ما فکر میکنیم هر کسی که تفاوت بین یک left inner و right outer join را میداند، مقداری SQL نیز میداند.
آیا این به این معنی است که شما ویژگیهای قدرتمندتر را به سازنده پرسوجو اضافه نمیکنید؟
اصلاً. ما چیزهای زیادی برای سازنده پرسوجو در ذخیره داریم! ما در انتشارات آینده به شدت روی در معرض قرار دادن عملکرد بیشتر برای کاربران غیرفنی و کاربران فنی فشار میآوریم. آنها روی چیزهایی تمرکز میکنند که SQL در آنها چندان خوب نیست به جای چیزهایی که SQL واقعاً خوب انجام میدهد. ما همچنین رابط را دوباره طراحی میکنیم تا حتی برای کاربران غیرفنی قابل دسترستر شود، و یافتن نقاط شروع رایج برای سوالات آنها را آسانتر کند.
آیا این کند نخواهد بود؟
این بستگی دارد. ممکن است یک پرسوجوی کند تولید کنید، اما اگر از یک زیرپرسوجوی صریح نیز استفاده میکردید کند میبود، و ما دریافتیم که کاربران ما تمایل دارند که آنها را نسبتاً اغلب استفاده کنند.
اگر کاربران من پرسوجوهای ترکیبی زیادی اجرا کنند و چیزها را کند کنند چه میشود؟
این به این معنی است که کاربران شما در اجرای آن پرسوجوها ارزش پیدا میکنند، و باید آنها را بهینه کنید. مسیر بهینهسازی تبدیل زیرپرسوجو به یک view مادیشده است، و اگر آن کند است (به عنوان مثال، در inserts)، آن را به یک فرآیند تبدیل batch یا streaming که یک جدول مشابه تولید میکند تقسیم کنید. ما پیشنهاد میکنیم همان نام جدول را نگه دارید، زیرا این به شما امکان میدهد که به طور بالقوه پرسوجوها را در جای خود جایگزین کنید.
بعدی چیست؟
ما پیشنهاد میکنیم که پرسوجوهای تو در تو را امتحان کنید و به ما بازخورد دهید. ما تعدادی issue باز داریم که در آن در مورد مراحل بعدی و بهبودها بحث میکنیم:
- توانایی استفاده از پرسوجوهای تو در تو در SQL؟
- توانایی مشخص کردن دستی متادیتا برای پرسوجوهای تو در تو؟
- حمل Foreign Keys در پرسوجوهای SQL تو در تو.
- اسکن خودکار بهبود یافته نتایج پرسوجو برای پر کردن متادیتای ما.
- توانایی ایجاد یک view مادیشده از یک سوال.
اگر یک یا بیشتر از اینها به طور قابل توجهی زندگی شما را ساده میکند، لطفاً در issues نظر دهید. ما بهبودهای ویژگی را بر اساس اینکه چند نفر از کاربران ما نیز فکر میکنند که ایدههای خوبی هستند اولویتبندی میکنیم.
