SQL סטנדרטי מאז 1987 ומתוחזק כ ISO/IEC 9075, אם כי כל מנוע מוסיף את הניב שלו למעלה - וזו בדיוק הסיבה שמעצב צריך לנתח ולא להתאים דפוסים.
השאילתה הגרועה ביותר שנאלצתי לסקור אי פעם הייתה 340 שורות במחשבה הגיונית אחת: דוח הכנסות עבור Laravel SaaS, שנכתב כאחד DB::select() מחרוזת גולמית, שנבנתה במשך שמונה חודשים על ידי שלושה מפתחים שלכל אחד מהם היה רעיון שונה לגבי שימוש באותיות רישיות ואף אחד לגבי מעברי שורות. איפשהו בקיר הטקסט הזה, א LEFT JOIN הפך בשקט ל INNER JOIN במהלך refactor, ולקוחות עם אפס הזמנות נעלם מן הדוח הבאג היה מילה אחת מציאת זה לקח יום וחצי - לא בגלל ההיגיון היה קשה, אלא בגלל השאילתה הייתה בלתי קריא, וקוד בלתי קריא מסתיר את הבאגים שלו לעין.
Here's העניין ב-SQL: למסד הנתונים לא אכפת מהעיצוב שלך. המנתח קורא select id,name from users where active=1 ו SELECT id, name FROM users WHERE active = 1 כמו אותה הצהרה, מייצרת את אותה תוכנית ביצוע, מחזירה את אותן שורות באותו זמן עיצוב SQL הוא אך ורק לבני אדם - וזו בדיוק הסיבה ששווה לעשות את זה 's, כי בני אדם הם אלה שבודקים אותו, מנפים באגים בו ב-2 לפנות בוקר, ויורשים אותו שלוש עבודות מאוחר יותר שאילתה שאתה יכול't skim היא שאילתה שאתה יכול't לאמת.
An פורמט SQL הופך כל שאילתה - מודבקת מיומן, פלט ניפוי באגים ORM's, עמית לעבודה's הודעת Slack, הליך מאוחסן מדור קודם - ל-SQL מוזנח באופן עקבי, בעל מעטפת עקבית, הניתן לבדיקה בלחיצה אחת. זה ב-Toolz.dev פועל כולו בדפדפן שלך, מה שחשוב יותר עבור SQL מאשר כמעט כל טקסט אחר שאתה 'd הדבק בכלי מקוון, מכיוון ששאילתות ייצור נושאות את הסכימה שלך ולפעמים את הנתונים שלך.
מדריך זה מכסה את אופן השימוש בו, את מוסכמות העיצוב החשובות בפועל (מארז מילות מפתח, הזחה ומלחמת הפסיקים הנצחית), ואת זרימות העבודה שבהן מעצב משלם על עצמו מדי יום.
TL;DR: הדבק כל שאילתה לתוך Toolz.dev SQL Formatter וקבל בחזרה באופן עקבי, SQL עם מארז מילות מפתח - מיידי, חינמי, בצד הלקוח, ללא הרשמה עיצוב לעולם לא משנה מה שאילתה עושה או כמה מהר היא פועלת; זה משנה אם אדם יכול לאמת את זה מוסכמות שכדאי לאמץ: מילות מפתח רישיות, סעיף אחד בכל שורה, הזחה מתחת לכל סעיף, ובחר סגנון פסיק והפסק להתווכח על זה. חבר את זה עם ה פורמט JSON עבור שכבת ה-API מעל מסד הנתונים שלך וה- כלי Text Diff להשוואה בין שתי גרסאות של שאילתה.
תכונות מפתח
הזחה עקבית בלחיצה אחת
מהלך הליבה של הפורמט 's: כל סעיף עיקרי - SELECT, FROM, WHERE, GROUP BY, ORDER BY - מתחיל קו משלו, עם עמודות, תנאים, ומצטרף מחורצים מתחת זהו "river" מבנה מנוסה SQL קוראים סריקה על ידי: העין רץ במורד הקצה השמאלי קריאת מילות מפתח סעיף, ואז צולל לתוך כל סעיף משנה. שאילתה בפורמט 60 שורות עם ביקורות מבנה ברור יותר מהר מאשר אחד לא מעוצב בן 6 שורות, כי המבנה עושה חצי מהקריאה בשבילך סיפור האימה שלי בן 340 השורות היה סקירה של עשרים דקות עם הצורה הזו - סוג החיבור שהשתנה היה יושב לבד על הקו שלו, שגוי בעליל.
נורמליזציה של מקרה מילות מפתח
SELECT לעומת select באמת ' זה משנה לכל מסד נתונים - מילות מפתח SQL אינן רגישות לרישיות לפי התקן, וכל ניב מכבד את זה. עם זאת, זה חשוב מאוד לבסיס קוד, מכיוון שמארז מעורב הוא רעש חזותי שגורם לשאילתות זהות מבחינה מבנית להיראות אחרת. מילות מפתח רישיות הן המוסכמה הישנה יותר, המתוארכת לעורכים ללא הדגשת תחביר, שם SELECT בכובעים היה ההדגשה. אני עדיין כותב אותיות רישיות - מילות מפתח קופצות כנגד מזהים באותיות קטנות, והיא שורדת כל הקשר שמפשיט הדגשה: יומנים, הבדלים, דואר אלקטרוני בטקסט רגיל, פלט מסוף. הפורמט מנרמל למוסכמה שבחרת כך שבסיס קוד שנכתב על ידי חמישה אנשים נקרא כאילו הוא נכתב על ידי אחד.
מטפל ב-ORM ובפלט יומן
השאילתות הזקוקות ביותר לעיצוב הן אלו שאף אדם לא כתב: פלט Eloquent ו-ActiveRecord, Doctrine's שנוצרו מצטרפים, המפלצות בשורה אחת ביומן השאילתות האיטיות שלך. פלט ORM מגיע כשורה אחת עם כינויים שנוצרו על ידי מכונה (t0, t1, laravel_reserved_0), ולקרוא אותו גולמי הוא איך אתה מקבל כאבי ראש. השימוש השכיח ביותר שלי בפורמט: תפוס את השאילתה מ-Laravel's יומן שאילתות או טלסקופ, פרמט אותה, ולמעשה ראה מה ה-ORM החליט לעשות - שזה הצעד הראשון של כל "למה נקודת הקצה הזו איטית" חקירה, ממש לפני EXPLAIN.
סובלנות רב דיאלקטית
SQL בעולם האמיתי היא משפחה של דיאלקטים: MySQL's מזהים שצוטטו ב-backtick, PostgreSQL's מרכאות כפולות ו :: casts, SQL Server's סוגריים מרובעים ו TOP, SQLite's מקל על הכל. מעצב שימושי מטפל בכולם מבלי לדרוש ממך להכריז תחילה על ניב, תוך שמירה על תחביר ספציפי לדיאלקט ולא " תיקון" זה. תקן ANSI/ISO SQL (ISO/IEC 9075) מגדיר את הליבה המשותפת, אבל אף אחד לא כותב SQL סטנדרטי טהור בפועל, ומעצב שמדבר רק את התקן ייחנק ב-backtick הראשון.
משמר סמנטיקה, מובטח
שווה לציין במפורש כי 's הפחד שעוצר אנשים: עיצוב לא יכול לשנות תוצאות. Whitespace ו-keyword case אינם סמנטיים ב-SQL - האזהרה ההיסטורית היחידה היא זאת מילולי מחרוזת מושווים ברגישות רישיות או לא בהתאם לאיסוף שלך, ומעצב לעולם לא נוגע בחלק הפנימי של המחרוזות המצוטטות שלך. הפלט הוא אותו משפט, בית-עבור-בית שבו בתים חשובים. לָרוּץ EXPLAIN בשתי הגרסאות אם רוצים לראות: תוכניות זהות.
צד לקוח, מה שבעצם חשוב כאן
SQL היא קטגוריית הטקסט הרגישה ביותר שנדבקת באופן שגרתי בכלים מקוונים. שאילתות חושפות את הסכימה שלך - שמות טבלאות, שמות עמודות, מערכות יחסים - ושאילתות שהועתקו מיומנים מכילות לעתים קרובות ערכים מילוליים: מיילים ב WHERE סעיפים, טווחי זיהוי, מדי פעם משהו שלא היה צריך להיות במחרוזת שאילתה בכלל. ה Toolz.dev formatter מעבד הכל בדפדפן שלך; שום דבר לא מועבר. עבור SQL ספציפית, I'd לקרוא לעיבוד בצד הלקוח דרישה, לא תכונה - אמת זאת בכרטיסייה רשת ולאחר מכן הירגע.
כיצד להשתמש בפורמט SQL
שלב 1: לכידת השאילתה
העתק את ה-SQL מהמקור שלו: קובץ ההגירה שלך, הליך מאוחסן, פלט ניפוי הבאגים ORM's (DB::listen() או טלסקופ בלארוול, ActiveRecord::Base.logger ב-rails), יומן השאילתות האיטי, או לשונית השאילתה של כלי ה-APM שלך. אם זה הגיע מיומן, ייתכן שהוא חמק ממרכאות או ממצייני מיקום של פרמטרים (?, $1) - זה ' בסדר, מעצבים מטפלים במצייני מיקום, ולראות אותם בבירור זה לעתים קרובות העניין.
שלב 2: הדבק ועיצוב
פתח את פורמט SQL, הדבק, והגרסה המעוצבת מופיעה אין טקס ניב, אין תצורה נדרשת כדי לקבל ברירת מחדל טובה אם השאילתה שלך כוללת הצהרות מרובות מופרדות על ידי נקודות פסיק, הן פורמטים כהצהרות נפרדות - שימושי לקריאת סקריפטים של הגירה שלמים.
שלב 3: קרא את זה כמו מבקר
עכשיו האם קיים הדבר שעיצוב: סרוק את הקצה השמאלי לאילו טבלאות מצטרפים, ועם אילו סוגי חיבורים? האם ה WHERE לסעיף יש את התנאים שאתה מצפה להם - והם AND/OR קבוצות סוגריים הדרך שבה אתה לחשוב הם מקבצים? (קדימות מפעיל ב-SQL puts AND לפני OR, ותערובות לא מסוגרות של השניים הן מקור הבאגים השני בגודלו שאני רואה בסקירה, מיד אחרי סוגי הצטרפות שגויים.) SQL מעוצב הופך את שתי הטעויות לגלויות תוך שניות.
שלב 4: העתק אותו בחזרה - באופן סלקטיבי
עבור שאילתות הנכנסות לבסיס הקוד שלך, העתק את הגרסה המעוצבת להעברה, ה ->select() ביטוי גולמי, ה .sql קובץ. for one-off debugging, don't trare round-tripping; the formatted copy served its purpose the moment you read it.מקום אחד לא כדי להדביק SQL מעוצב: חזרה למערכות המאחסנות שאילתות כמחרוזות תצורה שבהן מישהו ' כלי הבדל של s diff יציג כעת קיר של שינויים ברווח הלבן. פורמט לקריאה תמיד; עיצוב מחדש של שאילתות מאוחסנות רק כאשר אתה ' מוכנים להיות הבעלים של ההבדל.
שלב 5: תקן את אמנת הצוות
הפורמט' הערך הגדול ביותר של זה הוא חיבור: בחר את המוסכמות שאתה יכול להפוך לאוטומטיות - מקרה מילות מפתח ורוחב הזחה הם השניים שהפורמט הזה שולט ישירות - עצב כל דבר חדש בדרך לבסיס הקוד, וחיכוך סקירת SQL יורד לצמיתות. רשום את הבחירה במדריך התורם שלך. המוסכמה הספציפית שנבחרה חשובה הרבה פחות מכולם המשתמשים באותו אחד - משפט שנכון לכל ויכוח עיצוב בתוכנה ולא מאמינים בו על ידי אף אחד באמצע הדיון.
צלילה עמוקה טכנית: האמנות שכדאי לקבל דעות לגביהן
מעטפת מילות מפתח. מילות מפתח רישיות, מזהים קטנים היא המוסכמה הדומיננטית וההמלצה שלי הטיעון הוא 't מסורת - it's חוסן. הדגשת תחביר נעלמת ביומנים, מסופים, הערות סקירת קוד ותשובות Stack Overflow שהודבקו ב-Slack; מילות מפתח רישיות מדגישות שנוסעות עם הטקסט. טיעון הנגד (הכול באותיות קטנות, תן לעורך להדגיש) הוא קוהרנטי ו-I' עבד בבסיסי קוד שהשתמשו בו בשמחה. What's לא קוהרנטי הוא ערבוב, וזה מה שאתה מקבל מבלי שמעצב יאכוף את הבחירה.
סעיף אחד בכל שורה, תוכן מחורץ. הכלל המבני עם התמורה הגבוהה ביותר. SELECT מתחיל שורה; העמודות שלו מחורצות למטה (או על אותה שורה אם קצרה). כָּל JOIN מקבל קו משלו עם שלו ON מצב גלוי - תנאי הצטרפות מוסתרים באמצע הקו הם המקום שבו מסתתרים באגים שגויים. WHERE תנאים מחסנית אחד לכל קו, מיושר, עם AND/OR מוביל כל שורה כך שהמבנה הלוגי יקרא אנכית. כאשר שאילתה 's תנאים נקראים כעמודה, תנאי חסר גלוי כ-a פער בתבנית, אילו עיניים אנושיות טובות במיוחד בזיהוי.
מלחמת הפסיק. פסיקים עוקבים (אחרי כל עמודה) נקראים באופן טבעי; פסיקים מובילים (לפני כל עמודה, בתחילת השורה) הופכים את הפיסוק למבני:
-- Trailing (most common)
SELECT
u.id,
u.email,
o.total
-- Leading (the DBA classic)
SELECT
u.id
, u.email
, o.total
לתומכי פסיק מובילים יש שתי נקודות טובות באמת: הערה של כל שורה מלבד הראשונה לעולם לא שוברת את ההצהרה, ופסיק חסר נראה מיידית בשוליים השמאליים לתומכי פסיק נגררים יש אחת: זה נראה כמו כל שפה אחרת שאתה כותב. אני כותב פסיקים נגררים והפסקתי להרגיש רע עם זה - אבל שימו לב ש-SQL, בניגוד ל-JavaScript או Python המודרניים, כן לא סלח פסיק משתלשל אחרי העמודה האחרונה, וזו הסיבה הוויכוח הזה קיים בכלל ולמה הסגנון המוביל מסרב למות בחוגי DBA גילוי נאות: Toolz.dev formatter לוקח את הצד המיינסטרים ופולט פסיקים נגררים - אין לו מצב מוביל-פסיק, אז אם אתה 're חנות מובילה-פסיק מחויבת זה המוסכמה היחידה שהוא זכה 't reformat בשבילך בחר סגנון בית, ליישם אותו בעקביות, ולהמשיך הלאה.
מה עיצוב לא עושה. זה עושה 't לייעל. a מעוצב SELECT * על פני חיבור של חמישה שולחנות יש בעיית ביצועים מחוררת להפליא. עיצוב הוא תנאי מוקדם לאופטימיזציה - אינך יכול לנמק לגבי שאילתה שאינך יכול לקרוא - אך ההיגיון עדיין דורש EXPLAIN, מודעות לאינדקס, והכרת הנתונים שלך 's shape. אני חושב על הצינור כמו: פורמט, קרא, EXPLAIN, ואז בצע אופטימיזציה. דילוג על שלב ראשון עושה 't הופך אותך למהיר יותר; זה הופך את השלבים שניים עד ארבע לאיטיים יותר. אותה דיסציפלינה מחילה שכבה אחת למעלה ב-API, וזו הסיבה שה מדריך לפורמט JSON מעלה טיעון זהה מבחינה מבנית לגבי מטענים.
תגובות שורדות. בניגוד למיניפיקציה, עיצוב משמר הערות - -- הערות שורה ו /* */ בלוקים עוברים שלמים השתמש בהם. א -- deliberately LEFT JOIN: include customers with no orders תגובה מעל הצטרפות היא ביטוח הבאגים הזול ביותר שנכתב אי פעם, והוא 's התגובה שסיפור האימה שלי בן 340 השורות היה צריך.
מקרי שימוש נפוצים
סקירת קוד
SQL לא מעוצב בבקשת משיכה היא סקירה שהיא' לא יקרה - העיניים של המבקר' מחליקות מקיר הטקסט והאישור נוחת בכל מקרה עיצוב השאילתה לפני פתיחת יחסי הציבור הוא אדיבות בסיסית עם תמורה ניתנת למדידה: סוגי הצטרפות, קבוצות תנאים ורשימות עמודות הופכים לגלויים בנפרד, מה שאומר שהם הופכים לניתנים לביקורת בנפרד כל באג SQL אמיתי I' נתפס בביקורת - ההצטרפות הלא נכונה, הבלתי מסוגרת OR, ה DELETE חסר חצי מזה WHERE סעיף - תפסתי כי השאילתה עוצבה מספיק טוב כדי לקרוא שורה אחר שורה.
איתור באגים בשאילתות שנוצרו על ידי ORM
ORMs נפלאים ממש עד שנקודת הקצה איטית, ובשלב זה אתה צריך לראות את הפלט SQL - ו-ORM בפועל הוא תמיד קו צפוף אחד. עצב אותו והסיפור מופיע: ה-N+1 שהטעינה הנלהבת פספסה, ההצטרפות להגדרת הקשר הוספה בשקט, ה ORDER BY על עמודה לא באינדקס בעבודה של לארוול זהו טקס כמה פעמים בשבוע: טלסקופ, העתק, פורמט, wince, תקן את הקוד Eloquent, חזור. המעצב עושה 't לאבחן שום דבר בעצמו; זה הופך את השאילתה לקריא מספיק את you יכול.
ארכיאולוגיה על שאילתות מורשת
לכל מערכת ארוכת חיים יש אותם: ההליך המאוחסן משנת 2015, תצוגת הדיווח שאף אחד לא מעז לגעת, השאילתה מוטמעת בקובץ תצורה עם המחבר המקורי 's עיצוב (כלומר, אין). לפני שינוי SQL מדור קודם, עצב אותו וקרא אותו מקצה לקצה - you'll באופן שגרתי למצוא תנאים שיכולים ' לעולם לא יהיו נכונים, מצטרף לטבלאות שכבר לא מקבלות כתיבה, והגיון ההנחות הנוכחיות של team's סותרות. עיצוב סיבובים ראשונים " שאילתה מורשת מפחידה" לתוך " שאילתה ארוכה אך קריא," שזו בעיה אחרת וטובה יותר.
השוואת גרסאות שאילתות
כאשר דוח 's מספרים משתנים בין מהדורות, השאלה היא "מה השתנה בשאילתה," והתשובה דורשת הבדל של שתי גרסאות - מה שעובד רק אם שתיהן מעוצבות באופן זהה תחילה. עצב את שתיהן עם אותן הגדרות, ולאחר מכן הפעל אותן דרך כלי Text Diff: הרעש נעלם ושני הקווים שהשתנו עומדים לבדם הרצף המדויק הזה מצא את באג החיבור הפנימי שלי, בסופו של דבר. עכשיו אני עושה את זה לפני היום וחצי של בלבול במקום אחרי.
הוראה ותיעוד
SQL במדריכים, ספרי ריצה ומסמכים פנימיים נקרא הרבה יותר פעמים ממה שהוא נכתב, על ידי קוראים שפחות מכירים את הסכימה מאשר המחבר. דוגמאות מעוצבות עם מילות מפתח גדולות ומבנה של מושג אחד לכל שורה קלות יותר ללמוד מהן באופן דרמטי - המבנה מלמד לצד התוכן. כשאני כותב תיעוד עם שאילתות משובצות, כל אחד עובר קודם על הפורמט; SQL לא מעוצב במסמכים אומר לקורא שהמחבר עשה ' אל תצפה שמישהו באמת יקרא אותו.
מוסכמות עיצוב בהשוואה
| בחירת אמנה | אפשרות א | אפשרות ב | הטייק שלי |
|---|---|---|---|
| מקרה מילות מפתח | SELECT (אותיות גדולות) |
select (אותיות קטנות) |
אותיות רישיות - שורד הקשרים בלי להדגיש |
| מקרה מזהה | מקרה נחש | התאמת הגדרות טבלה | הגדרות התאמה; לעולם אל תילחם בסכימה |
| פסיקים | נגרר (id,) |
מוביל (, id) |
נגרר, אבל להוביל זה בר הגנה - פשוט בחר אחד |
| פריסת סעיף | סעיף אחד בכל שורה | קו יחיד קומפקטי | אחד לכל שורה לכל דבר טריוויאלי בעבר |
AND/OR השמה |
מוביל כל קו תנאי | קו קודם נגרר | מוביל - ההיגיון קורא אנכית |
| תנאי הצטרפות | ON בקו משלו או בשורה עם JOIN |
קבור באמצע הקו | גלוי עם ההצטרפות, תמיד |
| רוחב הזחה | 2 חללים | 4 חללים | או; SQL מקנן פחות מ-JSON, אז 4 זה בסדר כאן |
לאף אחת מהשורות הללו אין תשובה שגויה, וזה ' זה בדיוק המלכודת - מכיוון שכל אפשרות ניתנת להגנה, צוותים מתדיינים מחדש לנצח אלא אם מעצב הופך את ההחלטה למכנית. המהלך המנצח משעמם: בחר, הגדר, עצב הכל, והשקע את זמן הטיעון המוחזר בדברים המשפיעים על תוכנית הביצוע. לשאר ערכת הכלים היומית סביב זו, עיין ב מדריך כלי קידוד והרחב יותר ערכת כלים למפתחי אינטרנט.
שָׁוא
מה עושה מעצב SQL?
מעצב SQL משכתב שאילתה' רווח לבן, מעברי שורות ומארז מילות מפתח למבנה עקבי וקריא - כל סעיף בשורה משלו, תנאים ועמודות מוזחות, מילות מפתח מנורמלות למקרה אחד. ההצהרה ' המשמעות אינה נגועה: מנתחי SQL מתעלמים לחלוטין מהעיצוב, כך שהשאילתה המעוצבת מחזירה תוצאות זהות עם תוכנית ביצוע זהה. השינוי מיועד אך ורק לבני האדם שבודקים, מנפים באגים ומתחזקים את השאילתה.
האם עיצוב SQL משנה את ביצועי השאילתה?
מס 'Whitespace ו - מקרה מילות מפתח אינם סמנטיים ב - SQL - מסד הנתונים מנתח את שתי הגרסאות לאותו ייצוג פנימי ומייצר את אותה תוכנית ביצוע, אותה ניתן לאמת על ידי הפעלה EXPLAIN על כל אחד מהם עיצוב הוא התנאי המקדים לעבודת ביצוע ולא לעבודת ביצוע עצמה: אתה יכול 't סיבה לגבי אינדקסים ולהצטרף לסדר בשאילתה שאתה יכול 't לקרוא.
האם מילות מפתח SQL צריכות להיות רישיות או קטנות?
שניהם תקפים - מילות מפתח SQL אינן רגישות לאותיות רישיות לפי התקן - כך שזו מוסכמות קריאות, לא כלל נכונות. מילות מפתח רישיות (SELECT, FROM, WHERE) להישאר הבחירה הנפוצה ביותר כי הם פועלים כמובנה מדגיש בהקשרים כי פס צבעים: יומנים, diffs, מסופים, והודעות טקסט רגיל.Whatever שתבחר, עקביות על פני בסיס הקוד משנה הרבה יותר מאשר הבחירה עצמה.
מהם פסיקים מובילים ב-SQL ומדוע אנשים משתמשים בהם?
סגנון פסיק מוביל מציב את הפסיק בתחילת כל שורת עמודה (, email) במקום הסוף של הקודם. Advocates אוהבים את זה כי הערה של כל עמודה מלבד הראשונה לעולם לא מייצרת שגיאת תחביר, ופסיקים חסרים נראים באופן מיידי בשוליים השמאליים - יתרונות אמיתיים, שכן SQL עושה ' לא לסבול פסיק משתלשל אחרי העמודה האחרונה כמו JavaScript המודרני. פסיקים נגררים נשארים נפוצים יותר; כל אחד מהם עובד אם מיושם באופן עקבי.
האם אני יכול לעצב SQL שנוצר על ידי ORM כמו Eloquent או ActiveRecord?
כן, וזה 's אחד השימושים הטובים ביותר של מעצב - פלט ניפוי באגים ORM מגיע כקו צפוף יחיד עם כינויים שנוצרו על ידי מכונה, ועיצובו הוא השלב הראשון של אבחון נקודות קצה איטיות ובעיות N+1. ללכוד את השאילתה מה-ORM's רישום (Laravel Telescope, ActiveRecord logs), הדבק אותה ב- פורמט SQL, וקרא מה ה-ORM בנה בפועל לפני שהגיע אליו EXPLAIN.
האם הפורמט עובד עם תחביר MySQL, PostgreSQL ו-SQL Server?
כן - מעצבים מעשיים מטפלים בניבים העיקריים' מוזרויות, שימור של MySQL backticks, מזהים עם ציטוט כפול של PostgreSQL ו :: casts, וסוגריים מרובעים של SQL Server במקום לשכתב אותם תקן ANSI SQL מגדיר את הליבה המשותפת, אבל אף מסד נתונים ייצור לא מדבר SQL סטנדרטי טהור, ולכן סובלנות דיאלקט היא דרישה לפורמט להיות שימושי בשאילתות אמיתיות.
האם זה בטוח להדביק שאילתות ייצור לתוך פורמט SQL מקוון?
רק בצד הלקוח, מכיוון ש-SQL רגיש בצורה יוצאת דופן: שאילתות חושפות את הסכימה שלך, ושאילתות המועתקות מיומנים מכילות לרוב ערכים מילוליים כמו מיילים או מזהים WHERE סעיפים. ה Toolz.dev SQL Formatter מעבד הכל בדפדפן שלך עם שום דבר לא משודר או מאוחסן - אמת זאת בעצמך על ידי צפייה בכרטיסייה רשת בזמן שאתה מדביק. הימנע ממעצבים מבוססי שרת עבור כל דבר מייצור.
האם עיצוב משמר הערות SQL?
כן - שניהם -- הערות שורה ו /* */ לחסום הערות לעבור דרך שלם, בניגוד minification, אשר מוחק אותם זה עושה עיצוב בטוח עבור שאילתות מוערות נהלים מאוחסנים שבו הערות לשאת כוונה.Use that: הערה בשורה אחת המסבירה מכוון LEFT JOIN או מצב חריג הוא ההגנה הזולה ביותר מפני המפתח הבא "fixing" משהו שהיה 't שבור.
