{"id":18763784,"url":"https://github.com/roverdotcom/sql-style-guide","last_synced_at":"2026-03-19T06:15:28.881Z","repository":{"id":146067445,"uuid":"104281568","full_name":"roverdotcom/sql-style-guide","owner":"roverdotcom","description":"Rover SQL Style Guide","archived":false,"fork":false,"pushed_at":"2017-09-21T00:31:21.000Z","size":14,"stargazers_count":2,"open_issues_count":4,"forks_count":0,"subscribers_count":7,"default_branch":"master","last_synced_at":"2025-12-09T19:55:48.947Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":null,"language":null,"has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":null,"status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/roverdotcom.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":null,"code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2017-09-21T00:24:28.000Z","updated_at":"2023-07-07T17:32:48.000Z","dependencies_parsed_at":null,"dependency_job_id":"edbae4af-b02f-4d30-87ed-7bcc4319c2fc","html_url":"https://github.com/roverdotcom/sql-style-guide","commit_stats":null,"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"purl":"pkg:github/roverdotcom/sql-style-guide","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/roverdotcom%2Fsql-style-guide","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/roverdotcom%2Fsql-style-guide/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/roverdotcom%2Fsql-style-guide/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/roverdotcom%2Fsql-style-guide/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/roverdotcom","download_url":"https://codeload.github.com/roverdotcom/sql-style-guide/tar.gz/refs/heads/master","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/roverdotcom%2Fsql-style-guide/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":28814294,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-01-27T12:25:15.069Z","status":"ssl_error","status_checked_at":"2026-01-27T12:25:05.297Z","response_time":168,"last_error":"SSL_read: unexpected eof while reading","robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":false,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2024-11-07T18:27:26.961Z","updated_at":"2026-01-27T14:02:00.559Z","avatar_url":"https://github.com/roverdotcom.png","language":null,"funding_links":[],"categories":[],"sub_categories":[],"readme":"# The SQL style guide\n\nThe goal of this style guide is to improve the readability, quality, performance, and consistency of SQL queries.\n\n## Formatting\n\n### Keywords\n\n* Keywords should be UPPERCASE.\n\n    ```SQL\n    /* Good */\n    SELECT COUNT(1) FROM tablename WHERE 1;\n    \n    /* Bad */\n    select count(1) from tablename where 1;\n    ```\n\n### Names\n* Named objects should not be surrounded by backticks, no matter what MySQL says when it dumps the table structure for you.\n  *  If you need to use backticks because of something in your table name, rename your table.\n* Table names are singular.\n* Avoid tables and columns named with reserved SQL keywords.\n\n### Indentation and newlines\n\n* Newlines should be used for any query that is at all complex or longer than 72 characters.\n\n* Each clause should begin a new line.\n  SELECT, JOIN, LEFT JOIN, OUTER JOIN, WHERE, UNION, etc. are keywords that begin new clauses.\n\n    ```SQL\n    /* Good */\n    SELECT COUNT(1)\n      FROM tablename\n     WHERE really_loooong_column = CONCAT(other_column, ' street');\n    \n    /* Bad */\n    SELECT COUNT(1) FROM tablename WHERE really_loooong_column = CONCAT(other_column, ' street');\n    ```    \n\n* The keywords that begin a clause should be right-aligned.\n  The idea is to make a single character column between the keywords and their objects.\n\n    ```SQL\n    /* Good */\n    SELECT COUNT(1)\n      FROM tablename\n     WHERE 1;\n    \n      SELECT key_column, COUNT(1)\n        FROM tablename\n    GROUP BY key_column;\n    \n    /* Bad */\n    SELECT COUNT(1)\n    FROM tablename\n    WHERE 1;\n    ```\n\n## Common Table Expressions (CTEs)\n\n[From AWS](http://docs.aws.amazon.com/redshift/latest/dg/r_WITH_clause.html):\n\n\u003e`WITH` clause subqueries are an efficient way of defining tables that can be used throughout the execution of a single query. In all cases, the same results can be achieved by using subqueries in the main body of the `SELECT` statement, but `WITH` clause subqueries may be simpler to write and read.\n\nThe body of a CTE must be one indent further than the `WITH` keyword. Open them at the end of a line and close them on a new line:\n\n```sql\nWITH backings_per_category AS (\n  SELECT\n    category_id,\n    deadline,\n    ...\n)\n```\n\nMultiple CTEs should be formatted accordingly:\n\n```sql\nWITH backings_per_category AS (\n  SELECT\n    ...\n), backers AS (\n  SELECT\n    ...\n), backers_and_creators AS (\n  ...\n)\nSELECT * FROM backers;\n```\n\nIf possible, `JOIN` CTEs inside subsequent CTEs, not in the main clause:\n\n__GOOD__:\n\n```sql\nWITH backings_per_category AS (\n  SELECT\n    ...\n), backers AS (\n  SELECT\n    backer_id,\n    COUNT(backings_per_category.id) AS projects_backed_per_category\n  INNER JOIN ksr.users AS users ON users.id = backings_per_category.backer_id\n), backers_and_creators AS (\n  ...\n)\nSELECT * FROM backers_and_creators;\n```\n\n__BAD__:\n\n```sql\nWITH backings_per_category AS (\n  SELECT\n    ...\n), backers AS (\n  SELECT\n    backer_id,\n    COUNT(backings_per_category.id) AS projects_backed_per_category\n), backers_and_creators AS (\n  ...\n)\nSELECT * FROM backers_and_creators\nINNER JOIN backers ON backers_and_creators ON backers.backer_id = backers_and_creators.backer_id\n```\n\nAlways use CTEs over inlined subqueries.\n\n* Subqueries should be aligned as though the open parenthesis were the 0-column\n  So, they should be indented as a unit, to identify them as subqueries.  They should continue to have the opening keywords right-aligned.\n\n    ```SQL\n    /* Good */\n    SELECT *\n      FROM (  SELECT candidates.name, count(1)\n                FROM candidates\n                JOIN votes ON candidates.id = votes.candidate_id\n            GROUP BY candidates.name) name_count\n      JOIN city c ON name_count.name = c.mayor;\n    \n    /* Bad */\n    SELECT *\n      FROM (SELECT candidates.name, count(1)\n        FROM candidates\n        JOIN votes ON candidates.id = votes.candidate_id\n        GROUP BY candidates.name) name_count\n      JOIN city ON name_count.name = city.mayor;\n    ```   \n\n## Structure\n\n* Column aliases should always use the keyword AS\n  This becomes significant when a query has several columns selected with columns aliased.  Without the AS keyword, a dropped comma makes two columns become a single aliased column.\n\n    ```SQL\n    /* Good */\n    SELECT ebe_ebs_sox_flag_set_for_all_crs AS sox_ok\n      FROM tablename;\n    \n    /* Bad */\n    SELECT ebe_ebs_sox_flag_set_for_all_crs sox_ok\n      FROM tablename;\n    \n    ```    \n* Table aliases and column aliases should be descriptive.\n  Much like variable names, \"a\", \"b\", \"x\", etc are not generally useful in and of themselves outside of short examples.\n\n* Tiny names for table aliases can sometimes work as abbreviations.\n  As an example, if \"releases\" is referenced frequently, it might make sense to abbreviate it \"r\".  However, \"rel\" is almost as short, and much more descriptive.  Have a good reason for \"r\" instead of \"rel\".\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Froverdotcom%2Fsql-style-guide","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Froverdotcom%2Fsql-style-guide","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Froverdotcom%2Fsql-style-guide/lists"}