Snippetها در مقابل سؤال‌های ذخیره شده در مقابل Viewها

درباره ویژگی‌های متابیس که می‌توانید برای سازماندهی کد SQL خود استفاده کنید یاد بگیرید.

این مقاله نمای کلی از ابزارهایی که متابیس برای سازماندهی کد SQL شما ارائه می‌دهد ارائه می‌دهد، و برخی راهنمایی برای زمانی که باید به یک ابزار به جای دیگری برسید ارائه می‌دهد.

دو ابزار اصلی برای سازماندهی کد SQL شما وجود دارند: snippetها و سؤال‌های ذخیره شده. همچنین درباره viewهای پایگاه داده برای تمایز استفاده آن‌ها از سؤال‌های ذخیره شده در متابیس صحبت می‌کنیم، اگرچه viewها خاص به پایگاه داده شما هستند (یعنی، بخشی از متابیس نیستند).

هم snippetها و هم سؤال‌های ذخیره شده به عنوان templateهایی عمل می‌کنند که می‌توانید در سؤال‌های SQL دیگر inject کنید. در مورد اینکه کدام را استفاده کنید و چه زمانی، قاعده سرانگشتی این است: از snippetها برای fragmentهای کوچک، معمولاً استفاده شده SQL استفاده کنید، و از سؤال‌های SQL ذخیره شده برای هر کدی که می‌خواهید به تنهایی اجرا شود استفاده کنید.

Snippetها و پوشه‌ها

از Snippetها برای کد SQL بحرانی یا مکرراً استفاده شده استفاده کنید. Snippetها باید خطوط کوتاه، قابل استفاده مجدد SQL باشند.

همانطور که می‌توانید aggregationها و فیلترهای رسمی را به عنوان معیارها و بخش‌ها با استفاده از Query Builder تعریف کنید، می‌توانید از Snippetها برای codify کردن KPIها و فیلترها استفاده کنید. به عنوان مثال، ممکن است بخواهید دقیقاً نحوه محاسبه درآمد، یا آنچه یک کاربر فعال را تشکیل می‌دهد ذخیره کنید. آن کد SQL را به عنوان snippet ذخیره کنید، یک توضیح اضافه کنید (حتی می‌توانید اطلاعات تماس خود را در صورت داشتن سؤال توسط هر کسی شامل کنید)، و همه در تیم شما حالا قادر به ارجاع به آن SQL crystallized در snippet شما خواهند بود:

SELECT *
FROM users
WHERE {{ snippet: Active Users }} AND {{ snippet: Adults }}

Snippetها می‌توانند برای consolidating و standardizing کردن کد شما حیاتی باشند. اگر در هر نقطه تعریف آنچه یک کاربر فعال را تشکیل می‌دهد را refine کنید، فقط نیاز به به‌روزرسانی snippet Active Users دارید، و تغییر به هر سؤالی که از آن snippet استفاده می‌کند propagate می‌شود.

Metabase Enterprise Edition علاوه بر این به شما اجازه سازماندهی Snippetها در پوشه‌ها را می‌دهد، بسیار شبیه collectionها سؤال‌ها و داشبوردها را سازماندهی می‌کنند. می‌توانید مجوزها را روی این پوشه‌ها تنظیم کنید تا دسترسی به SQL حساس را محدود کنید، یا به سادگی اطمینان حاصل کنید که کاربران نیاز به wade کردن از طریق پوشه‌های نامرتبط به domain خود ندارند.

اگر متوجه شدید snippet طولانی می‌نویسید، و آن snippet مجموعه‌ای از نتایج را برمی‌گرداند (یعنی، snippet فقط یک بند WHERE نیست—یک پرس‌وجو به خودی خود است)، در نظر بگیرید پرس‌وجو را به عنوان یک سؤال برای دیگران برای ارجاع در پرس‌وجوهای خود ذخیره کنید.

سؤال‌های ذخیره شده به عنوان بلوک‌های ساختمانی

برای chunkهای بزرگتر کد SQL که به خودی خود مورد علاقه هستند، در نظر بگیرید آن کد را به عنوان یک سؤال ذخیره کنید. این، پس از همه، همان چیزی است که بیشتر مشتریان با متابیس انجام می‌دهند: آن‌ها سؤال می‌پرسند.

سؤال‌ها می‌توانند با هم در داشبوردها group شوند، اما همچنین می‌توانند به عنوان بلوک‌های ساختمانی برای پرس‌وجوهای بزرگتر استفاده شوند، درست مثل اینکه می‌توانستید چندین snippet را در یک پرس‌وجو کنار هم بگذارید.

فرض کنید یک پرس‌وجو می‌نویسید و آن را به عنوان یک سؤال ذخیره می‌کنید. می‌توانید آن را در پرس‌وجوی دیگر مثل این inject کنید:

SELECT *
FROM {{#123}}

جایی که 123 ID سؤال است. همچنین می‌توانید از سؤال به عنوان یک Common Table Expression (CTE) استفاده کنید:

WITH active_users AS {{#123}}
SELECT *
FROM Active Users

سؤال‌های ذخیره شده راهی کم‌تلاش برای modularize کردن تحلیل شما هستند. بزرگترین مزیت modularizing کردن پرس‌وجوهای خود از طریق سؤال‌های ذخیره شده (در مقابل Snippetها) این است که می‌توانید سؤال‌های ذخیره شده را به طور مستقل اجرا کنید و نتایج آن‌ها را ببینید، که سؤال‌ها را بسیار آسان‌تر از snippetها برای debug می‌کند.

به طور جایگزین، می‌توانستید به سادگی یک سؤال را duplicate کنید و از سؤال قبلی build کنید، اما این duplication با هزینه همراه است. حالا همان کد را در دو سؤال دارید؛ اگر بعداً یک خطا در یک سؤال پیدا کردید، همچنین باید خطا را در سؤال دیگر اصلاح کنید - با فرض اینکه یادتان باشد که آن‌ها همان کد را share می‌کنند. با به سادگی ارجاع به یک سؤال ذخیره شده، فقط نیاز به به‌روزرسانی کد در یک مکان دارید.

به عنوان مثال، اگر یک startup هستید، احتمالاً داده درباره کاربران scattered در جداول normalized دارید. در متابیس، می‌توانید آن جداول را به روش‌های مختلف join کنید تا مجموعه‌ای از سؤال‌ها که کاربران شما به آن‌ها علاقه‌مند خواهند بود ایجاد کنید، که به آن‌ها اجازه build کردن روی آن نتایج، ارجاع به آن سؤال‌ها در پرس‌وجوهای خود برای slice کردن داده به روش خاص را می‌دهد.

Viewهای پایگاه داده

اگر فکر می‌کنید سؤال‌های ذخیره شده خیلی شبیه viewها در یک پایگاه داده به نظر می‌رسند، درست می‌گویید. مزیت با یک سؤال این است که نیاز به admin بودن برای ایجاد آن‌ها ندارید، و می‌توانید سؤال‌ها را on the fly ایجاد کنید و آن‌ها را در سؤال‌های دیگر nest کنید. عیب این است که یک سؤال یک construct متابیس است، و بهینه‌سازی‌های performance یک view native به پایگاه داده خود را دریافت نمی‌کنید (اگر وجود داشته باشند). همچنین، هنگام ارجاع به سؤال دیگر در کد SQL خود، به خاطر داشته باشید که فقط می‌توانید به نتایج سؤال دسترسی داشته باشید: نمی‌توانید به پرس‌وجو خود دسترسی داشته باشید، یعنی نمی‌توانید به هیچ متغیری که ممکن است در آن وجود داشته باشد ارجاع دهید.

اگر متوجه شدید که مشتریان اغلب به یک سؤال در متابیس به عنوان foundation برای پرس‌وجوهای خود ارجاع می‌دهند، در نظر بگیرید با admin پایگاه داده خود درباره ایجاد یک materialized view که همان مجموعه نتیجه را به عنوان آن سؤال ذخیره شده برمی‌گرداند صحبت کنید. مزیت یک materialized view این است که پایگاه داده نیاز به recompute کردن نتایج هر بار ندارد؛ materialized view خیلی شبیه یک جدول واقعی در یک پایگاه داده رفتار می‌کند.

استفاده از سؤال‌های ذخیره شده دیگر در templateهای SQL عالی است برای زمانی که دسترسی به ایجاد viewها در پایگاه داده ندارید، یا اگر فقط در حال کاوش داده خود هستید و نمی‌خواهید view ایجاد کنید.

همانطور که رشد می‌کنید، منطق کسب‌وکار را بیشتر در pipeline بالا ببرید

بسیاری از تحلیل‌ها به سادگی slice کردن داده به روش‌های مختلف برای دریافت حس بهتری از داستان‌هایی که می‌تواند بگوید است. همانطور که analytics footing خود را پیدا می‌کنید، لزوماً نمی‌دانید کدام sliceهای داده به شما کمک می‌کنند بهترین تصمیمات را برای شرکت خود بگیرید.

همانطور که setup analytics سازمان شما mature می‌شود، می‌خواهید منطق کسب‌وکار را بیشتر در pipeline بالا ببرید، تا جداولی که مشتریان در متابیس پیدا می‌کنند واحدهای منطقی کسب‌وکار شما را group کنند. curating و build کردن روی یک مجموعه core از سؤال‌های ذخیره شده راهی آسان برای sort کردن اینکه کدام داده بیشترین اهمیت را برای سازمان شما دارد.

به طور کلی، هر چه آسان‌تر برای مشتریان تحلیل داده شما باشد، سازمان productiveتری خواهید بود. اشتباهات رایج مدل داده که startupها مرتکب می‌شوند را برای یادگیری بیشتر ببینید.

[

](snippets.html)

[

](filters.html)