SQL Formatter אונליין

הפכו שאילתה צפופה למשהו שחבר צוות יכול לסקור לפני שהיא נכנסת למיגרציה, דוח או production.

Dialect:
הזחה:
מילות מפתח:
קלט SQL
פלט מעוצב
ממתין לקלט...

למה לעצב את SQL?

SQL צפוף הוא המקום שבו מסתתרות טעויות קטנות: צירוף שגוי, סוגריים חסר, פילטר המחובר לסעיף הלא נכון, או כינוי שנראה ברור אתמול. עיצוב לא הופך שאילתה לנכונה, אבל הוא הופך את הכוונה לגלויה מספיק כדי לבדוק אותה.

מבנה קריא: הזחה ומעברי שורות עקביים הופכים רשימות SELECT, JOIN-ים, שאילתות משנה, CTEs ותנאי WHERE לקלים יותר למעקב.
עקביות בצוות: סגנון עיצוב משותף מפחית רעש בסקירה של מיגרציות, דוחות, מחברות נתונים וספריות שאילתות שמורות.
איתור באגים מהיר יותר: פריסה נקייה יותר מקלה לזהות טעויות לוגיות, alias חסר, קבוצות AND/OR שגויות ותנאים שבורים.
שינויים ידידותיים להבדלים: מעברי שורות יציבים מקלים על סקירת עריכות של שאילתות בבקשות משיכה במקום לקרוא קיר של SQL בשורה אחת.

התייחסות מהירה לדיאלקט

Dialectתכונות משותפותהגדרה מומלצת
SQL רגילקו בסיס למטרות כלליות עבור שאילתות יחסים פשוטות.מילות מפתח רישיות, הזחה של 2 רווחים
MySQL / MariaDBBackticks, סעיפי LIMIT ותחביר ספציפי ל-MySQL.ניב MySQL
PostgreSQLמחרוזות $tag$, אופרטורים של JSONB ותחביר עם הרבה cast-ים.ניב PostgreSQL
Transact-SQL (T-SQL)מזהים בסוגריים מרובעים, פסקאות TOP ותחביר שרת SQL.ניב T-SQL

שאלות נפוצות

האם זה מעלה את ה-SQL שלי לשרת?

לא. העיצוב מתרחש בדפדפן, כך שטקסט השאילתה נשאר בדף.

איך מפרמטים מחדש SQL דחוס?

מדביקים את השאילתה בת השורה האחת בחלונית הקלט ובוחרים את ה-dialect הקרוב ביותר. הכלי יבנה מחדש מעברי שורות, הזחה ורישיות של מילות מפתח באופן אוטומטי.

האם העיצוב יכול לשנות את אופן הפעלת השאילתה?

רווח לבן ואותיות מילות מפתח לא אמורות לשנות את הסמנטיקה של SQL. ובכל זאת, התייחס לפלט מעוצב כאל קוד: סקור אותו, הרץ בדיקות והיזהר סביב תחביר ספציפי לדיאלקט.

באיזה ניב SQL עלי לבחור?

בחרו את מסד הנתונים שיריץ את השאילתה. ל-PostgreSQL, MySQL ו-SQL Server יש כללי quoting שונים, פונקציות שונות, cast-ים ותחביר LIMIT/TOP שונה, לכן ה-dialect הקרוב ביותר נותן את הפלט הנקי ביותר.