منسق سطر أوامر SQL يتم تشغيله في أي بيئة تقريبًا (طالما تم تثبيت Node.js).
وهو يعتمد على حزمة Poor Man's T-SQL Formatter NPM (poor-mans-t-sql-formatter)، والتي بدورها تعتمد على مكتبة C# التي تحمل الاسم نفسه ( https://github.com/TaoK/PoorMansTSqlFormatter ).
يجب أن يكون هذا المنسق مكافئًا في وظائفه لمنسق سطر الأوامر C# الموجود منذ بضع سنوات (يمكن تنزيله على http://architectshack.com/PoorMansTSqlFormatter.ashx)، مع وجود اختلافين رئيسيين:
إنه سهل التثبيت للغاية، خاصة في بيئات Unixey - طالما أن Node.js متاح
إنه أبطأ قليلاً من المنسق المستند إلى .Net.
(بافتراض تثبيت Node.js)
npm install --global poor-mans-t-sql-formatter-cli
إدخال الأنابيب/stdin وإخراج stdout:
echo "select a from b join c on b.id = c.id where abc = 123 and def = N'whatêver' " | sqlformat
إدخال وإخراج الملف:
echo "with a as (select 1 as b) select * from a cros join c" > testfile.sql sqlformat -f testfile.sql -g testfile.sql cat testfile.sql
سيخرج منسق سطر الأوامر هذا برمز خروج غير 0 إذا "واجه مشكلة" تحليل SQL - على سبيل المثال، إذا واجه عبارة "IF" غير مكتملة، مما يشير إلى أن شيئًا ما حول SQL لم يتم فهمه/تحليله بشكل صحيح، و لذلك قد "يخرج بشكل خاطئ". هناك خيار لتعطيل هذا السلوك إذا كان من المعروف أن SQL مشبوهة، أو كان من المعروف أن ارتباك التحليل غير ضار.
إذا تم إحباط التحليل، فسيتم ترك أي "ملف إخراج" محدد دون تغيير.
الخيارات الخاصة بالأداة المساعدة لسطر الأوامر:
خيار | وصف | يكتب | تقصير |
---|---|---|---|
--inputFile | قراءة المدخلات المراد تنسيقها من ملف بدلاً من stdin (الإدخال المكتوب أو عبر الأنابيب) | خيط | |
--outputFile | كتابة مخرجات منسقة إلى ملف - مثل إعادة توجيه shell لـ stdout، إلا في حالة حدوث خطأ فإنه يترك الملف دون تغيير | خيط | |
--تجاهل الأخطاء | إرجاع رمز الخروج 0 (نجاح) حتى في حالة فشل التحليل (وبالتالي فإن الإخراج المنسق مشكوك فيه) | منطقي | |
--inputEncoding | استخدم ترميز أحرف محددًا تدعمه العقدة للإدخال - بشكل أساسي utf-16le أو utf-8 | خيط | أوتف-8 |
--outputEncoding | استخدم ترميز أحرف محددًا تدعمه العقدة للإخراج - بشكل أساسي utf-16le أو utf-8 | خيط | أوتف-8 |
--forceOutputBOM | أضف علامة ترتيب البايت (BOM) إلى بداية الإخراج | منطقي |
خيارات المنسق القياسية:
(يرجى ملاحظة أن الخيارات المنطقية التي عادةً ما تكون افتراضية على "صحيح" في المكتبة قد تم قلبها ببادئة "لا"، باتباع اصطلاحات معلمات سطر الأوامر unixey)
خيار | وصف | يكتب | تقصير |
---|---|---|---|
--مسافة بادئة | وحدة المسافة البادئة - عادةً علامة تبويب (t) أو عدد من المسافات | خيط | ر |
--maxLineWidth | اطلب من المنسق تغليف الخطوط الطويلة لتجنب تجاوز طول الخط هذا | كثافة العمليات | 999 |
--spacesPerTab | يُستخدم هذا لقياس طول الخط، ولا ينطبق إلا إذا كنت تستخدم علامات التبويب | كثافة العمليات | 4 |
--statementBreaks | كم عدد فواصل الأسطر التي يجب إضافتها عند بدء عبارة جديدة؟ | كثافة العمليات | 2 |
--clauseBreaks | كم عدد فواصل الأسطر التي يجب إضافتها عند بدء جملة جديدة داخل العبارة؟ | كثافة العمليات | 1 |
--no-expandCommaLists | هل ينبغي تقسيم القوائم المفصولة بفواصل (الأعمدة، المجموعة حسب الوسائط، وما إلى ذلك) إلى أسطر جديدة؟ | منطقي | |
--لا يوجد فواصل زائدة | عند بدء سطر جديد بسبب فاصلة، هل يجب أن تكون الفاصلة في نهاية السطر (مقابل بداية السطر التالي)؟ | منطقي | |
--spaceAfterExpandedComma | هل يجب إضافة مسافة بعد الفاصلة؟ (عادةً لا إذا كانت "زائدة") | منطقي | |
--no-expandBooleanExpressions | هل يجب أن تتسبب عوامل التشغيل المنطقية (AND، OR) في حدوث فاصل أسطر؟ | منطقي | |
--no-expandCaseStatements | هل يجب أن تحتوي تعبيرات الحالة على تعبيرات "متى" و"ثم" على أسطر جديدة؟ | منطقي | |
--no-expandBetweenConditions | هل يجب أن يكون بين التعبيرات وسيطة max مقسمة على سطر جديد؟ | منطقي | |
--expandInLists | هل يجب أن تحتوي قوائم IN() على كل وسيطة في سطر جديد؟ | منطقي | |
--breakJoinOnSections | هل يجب تقسيم قسم ON في جملة JOIN إلى سطر خاص به؟ | منطقي | |
--لا توجد كلمات رئيسية بأحرف كبيرة | هل يجب كتابة الكلمات الرئيسية T-SQL (مثل SELECT وFROM) بأحرف كبيرة تلقائيًا؟ | منطقي | |
--keywordStandardization | هل يجب استبدال الكلمات الأساسية T-SQL الأقل شيوعًا بنظيراتها القياسية؟ (ملاحظة: آمن فقط لـ T-SQL!) | منطقي |
خيارات المنسق المشوش (الأمر "min"):
خيار | وصف | يكتب | تقصير |
---|---|---|---|
--عشوائية KeywordCase | هل يجب أن تكون حالة الكلمات الرئيسية عشوائية لتقليل الوضوح؟ | منطقي | |
--عشوائيةLineLengths | هل يجب تغليف SQL على فترات زمنية عشوائية لتقليل الوضوح؟ | منطقي | |
--لا يوجد حفظ للتعليقات | هل يجب الاحتفاظ بالتعليقات الموجودة في الكود (مقابل إزالتها)؟ | منطقي | |
--enableKeywordSubstitution | هل يجب أن تستخدم الكلمات الرئيسية ذات المرادفات نماذج أقل شيوعًا؟ (ملاحظة: آمن فقط لـ T-SQL!) | منطقي |
يرجى ملاحظة أن أداة سطر الأوامر هذه لا تنتج حاليًا مخرجات HTML (بناء الجملة المميز). ستكون هذه ميزة تافهة إلى حد معقول لإضافتها، فهي مدعومة بالتأكيد من قبل المكتبة الأساسية، لكنني لم أر أي حالة استخدام واقعية. إذا كان لديك واحدًا، فيرجى إبلاغي بذلك (و/أو الشوكة، أضف الخيار (الخيارات)، أخبرني بذلك).
"يرث" هذا المنسق جميع وظائف مكتبة Poor Man's T-SQL Formatter:
الدعم الكامل لـ MS SQL Server T-SQL، مع عدم وجود (على حد علمي) أي فشل في التحليل ** بما في ذلك الدعم الكامل للكود الإجرائي/الدفعي، DDL، DML، إلخ.
دعم معقول لهجات SQL الأخرى (يُستخدم بانتظام لتنسيق استعلامات PL/SQL، وPostgreSql، وMySQL، وما إلى ذلك) ** قد لا تعمل بنيات معينة أو قد لا يتم الحفاظ عليها بشكل صحيح/مخلص لتلك اللهجات الأخرى - يرجى الإبلاغ عن المشكلات عند تحديد مثل هذه المخاوف
عدد معقول من خيارات تكوين التنسيق، مع المزيد في الطريق.
كما هو مذكور في مستند حزمة مكتبة JS (https://github.com/TaoK/poor-mans-t-sql-formatter-npm-package)، فإن هذا المنسق بطيء جدًا في الوقت الحالي. على جهاز الكمبيوتر المحمول الخاص بي، يستغرق تنسيق استعلام واحد حوالي نصف ثانية. يشير ذلك إلى أنه بالنسبة لأحمال عمل التنسيق المجمع، قد يكون من المنطقي تقديم خيار إدخال/إخراج ملف بدل/تكراري.
دعم التشفير أيضًا محدود جدًا - نظرًا لأننا نستخدم دعم التشفير المدمج في العقدة، فإنه يصل إلى utf-8 أو utf-16le. قد يكون من المفيد معالجة هذا الأمر من خلال مكتبة Iconv-lite، لكن إضافة المزيد من التعليمات البرمجية للتحميل سيكون له أيضًا جوانب سلبية. شيء للتفكير فيه.
إلى جانب هذه الأشياء، لست على علم بأي مخاوف كبيرة معلقة (مقابل على سبيل المثال إصدار C# / .Net من نفس منسق سطر الأوامر الذي يمكن تنزيله على http://architectshack.com/PoorMansTSqlFormatter.ashx)، لذا فإن أي إدخال/ميزة الطلبات موضع ترحيب!