Как назвать таблицу в sql

Названия таблиц

Несмотря на то, что названия таблиц необязательны для неповторяющихся полей, их все же лучше использовать для большей ясности.

Для выбора всех полей применяется символ звездочки (*). Для выбора всех полей из нескольких таблиц укажите название таблицы, точку (.), а затем название поля (в данном случае — звездочку).

Тема 3.2. Операторы языка sql Команда from в sql-выражении

Команда FROM, как следует из ее названия, указывает таблицы (или запросы), содержащие поля в выражении SELECT. Эта команда указывает Access, где искать записи. При работе с одной таблицей, как в приведенном примере, команда FROM просто указывает имя таблицы:

SELECT [CoinpanyName], Country, FROM Customers

При работе с несколькими таблицами в команде FROM можно указывать, какие данные выбираются. В команде FROM устанавливается объединение между несколькими таблицами, которые будут соединены в результирующей таблице. Объединения бывают трех типов:

INNER JOIN. . .ON используется для указания традиционного объединения Access.

LEFT JOIN и RIGHT JOIN работают почти так же, с той лишь разницей, что вместо внутреннего объединения они указывают внешнее.

Команда where в sql-выражениях

Команда WHERE в SQL-выражениях служит для указания условий. Выражение SQL можно начать, к примеру, с команды WHERE:

WHERE (Customers. [Customer I D]=»EASTC»)

Условие WHERE может быть любым допустимым выражением. Оно может быть простым выражением, состоящим из одного условия (как в приведенном примере), или же сложным выражением, включающим несколько критериев.

В SQL-выражении команда WHERE должна следовать за командой FROM.

Команда order by

Команду ORDER BY можно использовать для сортировки запроса. С помощью ORDER BY данные сортируются по возрастанию или по убыванию. Например, для указания порядка сортировки по полю CustomerlD следует ввести следующее:

ORDER BY Customers. [CustomerlD];

Окончание sql-выражения

Поскольку SQL-выражение может состоять из 64 000 символов, необходимо обозначить его конец. SQL-выражение необходимо оканчивать точкой с запятой (;).

Access забывает о том, что вы должны использовать завершающую точку с запятой. Если точка с запятой не будет помещена в конец запроса, то запрос выполнится так, как будто точка с запятой в конце есть.

Если точка с запятой случайно окажется внутри SQL-выражения, то Access выдаст сообщение об ошибке и попытается указать, где она произошла.

При использовании SELECT, FROM, WHERE и ORDER BY можно создавать различные SQL-выражения для просмотра и вывода данных из таблиц. Например, можно построить SQL-выражение, выполняющее действия, перечисленные ниже.

1. Выбор полей CompanyName, Country, OrderlD и OrderDate.

2. Объединение таблиц Customers и Orders по полю Customer] D.

3. Вывод только тех записей, в поле CustomerlD которых содержится EASTC.

4. Сортировка данных по полю OrderDate. Соответствующее SQL-выражение должно выглядеть следующим образом:

SELECT [CompanyName], Country, [OrderlD], [OrderDate] FROM Customers INNER JOIN Orders ON Customers. [CustomerlD] = _ Orders. [CustomerlD] WHERE [CustomerlD] = «EASTC» ORDER BY Orders. [OrderDate];

Приведенная ниже информация о SQL-выражениях может служить описанием процесса создания SQL-выражений в Access 97. В SQL-выражениях можно также использовать другие команды. SQL относительно легок для понимания и использования и является неоценимым помощником в создании запросов и их использовании.

Согласования имен SQL

Согласования имен SQL для таблиц и всех связанных с ними объектов, таких как индексы, ограничения, ключи и триггеры, важны для совместной работы. Таблицы с плохими именами и другие объекты затрудняют ведение баз данных.

Имена таблиц должны соответствовать правилам для идентификаторов SQL Server и содержать не более 128 символов. Можно заставить SQL Server принимать нестандартные имена таблиц, заключив их в квадратные скобки, но это очень плохая идея, потому что их нужно «цитировать» всякий раз, когда они используются в сценариях.

Временные имена таблиц немного отличаются тем, что они имеют префикс одного знака (#) и имеют длину не более 116 символов. После любого префикса со специальным значением («@» означает переменную таблицы, «#» означает временную таблицу или «##» означает глобальную временную таблицу), первая буква должна быть буквой, определенной стандартом Unicode 3.2. Это означает, что это либо латинский символ от A до Z, прописные или строчные буквы, либо буквенный символ из других языков. Последующие символы могут законно использоваться:

• буквы, как определено в стандарте Unicode 3.2.,
• десятичные числа из базовой латиницы или других национальных сценариев,
• «At» (@), «знак доллара» ($), «число» или «знак хеша» (#)
• Подчеркивание, обычно используемое для представления пробелов, таких как Overdue_Account.

Никогда не используйте пробелы, встроенные символы или зарезервированные имена, потому что они не переносимы, требуют квадратных скобок и могут запутать сценарии и процедуры.

Мы можем очень просто проверить соответствие спецификации идентификаторов SQL Server с помощью следующего SQL.

SELECT name FROM sys.objects

WHERE name LIKE ‘%[^_A-Z0-9@$#]%’ COLLATE Latin1_General_CI_AI

—contains illegal characters

OR name NOT LIKE ‘[A-Z]%’ COLLATE Latin1_General_CI_AI

—doesn’t start with a character

Мы можем проверить зарезервированные слова в объектах в этом немного громоздком, но эффективном коде

VALUES (‘ADD’), (‘EXTERNAL’), (‘PROCEDURE’), (‘ALL’), (‘FETCH’),

(‘PUBLIC’), (‘ALTER’), (‘FILE’), (‘RAISERROR’), (‘AND’),

(‘FILLFACTOR’), (‘READ’), (‘ANY’), (‘FOR’), (‘READTEXT’), (‘AS’),

(‘FOREIGN’), (‘RECONFIGURE’), (‘ASC’), (‘FREETEXT’), (‘REFERENCES’),

(‘AUTHORIZATION’), (‘FREETEXTTABLE’), (‘REPLICATION’), (‘BACKUP’),

(‘FROM’), (‘RESTORE’), (‘BEGIN’), (‘FULL’), (‘RESTRICT’), (‘BETWEEN’),

(‘FUNCTION’), (‘RETURN’), (‘BREAK’), (‘GOTO’), (‘REVERT’), (‘BROWSE’),

(‘GRANT’), (‘REVOKE’), (‘BULK’), (‘GROUP’), (‘RIGHT’), (‘BY’),

(‘HAVING’), (‘ROLLBACK’), (‘CASCADE’), (‘HOLDLOCK’), (‘ROWCOUNT’),

(‘CASE’), (‘IDENTITY’), (‘ROWGUIDCOL’), (‘CHECK’), (‘IDENTITY_INSERT’),

(‘RULE’), (‘CHECKPOINT’), (‘IDENTITYCOL’), (‘SAVE’), (‘CLOSE’), (‘IF’),

(‘SCHEMA’), (‘CLUSTERED’), (‘IN’), (‘SECURITYAUDIT’), (‘COALESCE’),

(‘INDEX’), (‘SELECT’), (‘COLLATE’), (‘INNER’),

(‘SEMANTICKEYPHRASETABLE’), (‘COLUMN’), (‘INSERT’),

(‘SEMANTICSIMILARITYDETAILSTABLE’), (‘COMMIT’), (‘INTERSECT’),

(‘SEMANTICSIMILARITYTABLE’), (‘COMPUTE’), (‘INTO’), (‘SESSION_USER’),

(‘CONSTRAINT’), (‘IS’), (‘SET’), (‘CONTAINS’), (‘JOIN’), (‘SETUSER’),

(‘CONTAINSTABLE’), (‘KEY’), (‘SHUTDOWN’), (‘CONTINUE’), (‘KILL’),

(‘SOME’), (‘CONVERT’), (‘LEFT’), (‘STATISTICS’), (‘CREATE’), (‘LIKE’),

(‘SYSTEM_USER’), (‘CROSS’), (‘LINENO’), (‘TABLE’), (‘CURRENT’),

(‘LOAD’), (‘TABLESAMPLE’), (‘CURRENT_DATE’), (‘MERGE’), (‘TEXTSIZE’),

(‘CURRENT_TIME’), (‘NATIONAL’), (‘THEN’), (‘CURRENT_TIMESTAMP’),

(‘NOCHECK’), (‘TO’), (‘CURRENT_USER’), (‘NONCLUSTERED’), (‘TOP’),

(‘CURSOR’), (‘NOT’), (‘TRAN’), (‘DATABASE’), (‘NULL’), (‘TRANSACTION’),

(‘DBCC’), (‘NULLIF’), (‘TRIGGER’), (‘DEALLOCATE’), (‘OF’),

(‘TRUNCATE’), (‘DECLARE’), (‘OFF’), (‘TRY_CONVERT’), (‘DEFAULT’),

(‘OFFSETS’), (‘TSEQUAL’), (‘DELETE’), (‘ON’), (‘UNION’), (‘DENY’),

(‘OPEN’), (‘UNIQUE’), (‘DESC’), (‘OPENDATASOURCE’), (‘UNPIVOT’),

(‘DISK’), (‘OPENQUERY’), (‘UPDATE’), (‘DISTINCT’), (‘OPENROWSET’),

(‘UPDATETEXT’), (‘DISTRIBUTED’), (‘OPENXML’), (‘USE’), (‘DOUBLE’),

(‘ORDER’), (‘VARYING’), (‘ELSE’), (‘OUTER’), (‘VIEW’), (‘END’),

(‘OVER’), (‘WAITFOR’), (‘ERRLVL’), (‘PERCENT’), (‘WHEN’), (‘ESCAPE’),

(‘PIVOT’), (‘WHERE’), (‘EXCEPT’), (‘PLAN’), (‘WHILE’), (‘EXEC’),

(‘PRECISION’), (‘WITH’), (‘EXECUTE’), (‘PRIMARY’), (‘WITHIN GROUP’),

(‘EXISTS’), (‘PRINT’), (‘WRITETEXT’), (‘EXIT’), (‘PROC’)

) AS reserved (word)

ON reserved.word = sys.objects.name;

Остерегайтесь чисел в любых именах объектов, особенно имен таблиц. Обычно он отображает неуклюжую денормализацию, когда данные вводятся в имя, как в «Year2017», «Year2018» и т. д. Обычно значение цифр очевидно для исполнителя, но не для тех, кто поддерживает систему.

SELECT name FROM sys.tables

WHERE name LIKE ‘%[0-9]%’ COLLATE Latin1_General_CI_AI —contains numbers

Если вы более спокойно относитесь к этому и будете терпеть отдельные числа, но не более, попробуйте это:

SELECT name FROM sys.tables

WHERE name LIKE ‘%[0-9][0-9]%’ COLLATE Latin1_General_CI_AI

–contains more than one adjacent number

Нет общепринятых стандартов для именования объектов SQL. Хотя ИСО/МЭК 11179 упоминается как стандарт для именования, он фактически устанавливает только стандарт для определения соглашений об именах. В документе «Принципы присвоения имен» есть образец стандарта (ИСО/МЭК 11179-5), но это всего лишь пример того, как следует определять стандарт. Тем не менее, это довольно близко к общей хорошей практике в программировании.

При именовании таблицы рекомендуется использовать собирательное имя или «object class term» для объекта, если такой существует (например, «Сотрудник», «Стоимость», «Дерево», компонент, член, аудитория, персонал или преподавательский состав), но использовать единственное число а не форма множественного числа, где это возможно. В целях обслуживания используйте согласованное соглашение об именах, которое является информативным, но кратким. Это очень помогает начать со словаря правильных существительных и глаголов, связанных с доменом приложения, и использовать его. Если это оказывается недостаточным, то команда может достроить его. Если модель данных была создана как часть фазы проектирования, этот словарь должен быть конечным продуктом этой работы.

Никогда не используйте описательный префикс, такой как tbl_. Эта нотация, обратная венгерской, никогда не была стандартом для SQL и противоречит соглашениям об именах SQL Server. Некоторым системным процедурам и функциям были присвоены префиксы «sp_», «xp_» или «dt_» для обозначения того, что они были «специальными» и их следует сначала найти в базе данных master. Использование tbl_prefix для таблицы, часто называемой «tibbling», пришло из баз данных, импортированных из Access, когда SQL Server был впервые представлен. К сожалению, это было соглашение о доступе, унаследованное от Visual Basic, свободно типизированного языка. Даже если бы префиксы были хорошими, никто не использовал бы «Tbl_» для таблицы. Существуют установленные коды для SQL Server, а код для таблицы — U (очевидно, сокращение от «User Table»). Все еще есть много администраторов баз данных, которые хотят «тиблить», но никогда не возникает сомнений, какой тип объекта находится в SQL Server, если вы знаете его имя, схему и базу данных, потому что его тип есть в sys.objects: очевидно из использования. SQL Server является строго типизированным языком.

SELECT name FROM sys.objects

WHERE Left(name,3) IN (‘tbl’,’sp_’,’xp_’,’dt_’) —tibbling!

Не присваивайте таблице такое же имя, как у одного из ее столбцов.

SELECT Thetable.Name FROM sys.columns cols

INNER JOIN sys.tables Thetable

ON Thetable.object_id = cols.object_id

По возможности избегайте объединения двух имен таблиц вместе, чтобы создать имя таблицы отношений, когда в языке уже есть слово для описания отношений. Например используйте Client, а не EmployeeCustomer

Этот код найдет эти таблицы. Не пытайтесь сделать это на огромной базе данных!

FROM sys.tables AS TheTable

SELECT first.name + second.name

FROM sys.tables AS first

(SELECT name FROM sys.tables) AS second

ON combined.doubleName = TheTable.name;

На AdventureWorks2016 вы получите несколько таблиц с более подходящим названием

Следите за тем, чтобы имена таблиц были короткими, потому что многие соглашения об именах требуют, чтобы триггеры, ограничения и индексы включали в себя имя используемой таблицы или таблиц. Ограничение внешнего ключа может стать громоздким.

Будьте последовательны в расположении таблиц и использовании подчеркивания для разграничения слов.

Столбец таблицы должен иметь «качество, общее для всех членов класса объекта», и должно иметь имя, которое соответствует тому, как простой язык ссылается на свойство, например First_Name, Amount, Measure, Number, Quantity или Text. Никогда не применяйте коллективное имя к свойству, например, свойство «Employee_name» в таблице Employee. Это обеспечит избыточность, когда в запросе будет указан квалифицированный столбец — Employee.Employee_name.

Вы можете быстро найти все столбцы с избыточностью в их именах, если они обозначены точечной нотацией.

SELECT TheTable.name AS TableName, TheColumn.name AS ColumnName

FROM sys.tables AS TheTable

INNER JOIN sys.columns AS TheColumn

ON TheColumn.object_id = TheTable.object_id

WHERE TheColumn.name LIKE ‘%’ + TheTable.name + ‘%’;

AdventureWorks полна такого рода проблем.

Кто бы ни придумал имя Person.Person.personType, у него не хватало словарного запаса. Это может быть идеей обнаружить еще более гнусное преступление, назвав таблицу так же, как схему!

SELECT name FROM sys.objects WHERE Object_Schema_Name(object_id) = name;

Простое руководство по именованию заключается в уважении идеи SQL как понятного языка, основанного на письменном языке. Это предполагает, что имена функций должны вписываться в семантику предложения SELECT, если у нас есть функция, которая вводит предложение с заглавной буквы, делает первый символ каждого слова длиннее трех символов заглавной буквой (MLA), тогда вы бы назвали его ‘заглавной ()’. Процедуры имели бы имена глагол-существительное задач, так как они выполняются.

Процедуры должны следовать соглашению об использовании глагола, популяризованному PowerShell. Очевидно, что стандартные глаголы и существительные будут происходить из процесса проектирования базы данных и модели данных организации или предметной области.

Резюме

В SQL Server есть определенные правила стиля, но их не так много. Более важно быть последовательным и, по возможности, писать так, чтобы это было наиболее близко к стандартному SQL. SQL Server дает вам немного свободы в вашем стиле, но поскольку вы можете делать такие вещи, как ввод чисел, пробелов и управляющих символов в имена, это не значит, что вы должны это делать. Вы можете писать на эксцентричных архаичных диалектах SQL, но вы все еще эксцентричны. В командной работе лучше всего принять определенный стандарт, каким бы абсурдным он ни был, и приложить все усилия, чтобы убедить остальную команду измениться.

SQL отличается от любого другого компьютерного языка тем, что он был спроектирован так, чтобы быть максимально приближенным к человеческому языку, поэтому он может использоваться непрофессионалами для бизнес-анализа. Соглашения об именах должны вписываться в эту основную идею, чтобы код базы данных читался четко с минимальным количеством документации, и у других не возникало трудности в понимании.

1.6. Именование

Отдельного разговора требует рассмотрение именование. Дело в том, что SQL Server достаточно лояльно относиться к именам таблиц. Например, вы можете использовать в качестве имен русские слова, и даже имена из нескольких слов. Только если имя состоит из нескольких слов, оно должно заключаться в квадратные скобки. Посмотрим на следующий пример:

В данном случае все имена объектов имеют русские названия. Я заключил все русские названия в квадратные скобки, чтобы их явно было видно. В реальных условиях, я рекомендую все же назвать все английскими названиями.

С помощью квадратных скобок можно создавать поля и из зарезервированных слов. Например, если попытаться создать таблице с именем поля min, то сервер вернет ошибку, потому что это зарезервированное имя (есть такой оператор). Но если имя поля из одного не зарегистрированного слова заключить в квадратные скобки, то ошибки не будет.

Квадратными скобками нужно выделять и имена полей из нескольких слов. Если в примере выше убрать квадратные скобки с имени поля «Название товара», то сценарий закончит выполнение ошибкой.

1.7. Резюме

Давайте сведем всю рассмотренную в данной главе информацию и создадим базу данных из четырех таблиц:

1. tbPeoples – в этой таблице будет храниться информация о сотрудниках;
2. tbPositions – это справочник должностей. Несколько сотрудников могут иметь одинаковую должность. Например, даже небольшая организация может содержать в штате несколько водителей. Чтобы не писать в таблице у каждого сотрудника одну и ту же должность, достаточно только выбрать ее из справочника. К тому же, справочник будет иметь возможность отображение подчинения должностей, т.е. будет внешний ключ на саму таблицу должностей;
3. tbPhoneNumbers – номера телефонов. Так как у одного сотрудника может быть несколько номеров (стационарный, сотовый, домашний), перенесем номера телефонов в отдельную таблицу;
4. tbPhoneType — чтобы жизнь не казалась медом, добавим возможность отображения типа телефона (стационарный рабочий, стационарный домашний сотовый рабочий, сотовый собственный). Эта таблица также позволит не вводить для каждого телефона его тип буквами, а достаточно будет только выбрать нужный вариант из справочника.

В нашей базе данных два полноценных справочника для хранения должностей и для хранения типов телефонов. Справочники позволяют:

• упростить работу операторам. Не надо каждый раз вводить названия, достаточно выбрать нужный номер из справочника;
• уменьшить вероятность ошибок при вводе. При вводе символьной информации очень часто возникают ошибки. Особенно это проявляется в раскладках клавиатуры. Например, один пользователь может ввести слово «сотовый», и другой введет «сотовый», но SQL сервер будет воспринимать их по-разному. Вы не видите ошибки? На взгляд ее увидеть невозможно. Просто одно из слов может содержать первую букву в английской раскладке. Дело в том, что русская «с» и английская «с» выглядят одинаково и находятся на одной клавише. Пользователи очень часто начинают вводить на английском, потому видят, что ошиблись, стирают лишнее, переключаются в русскую раскладку и вводят заново. При этом, первая буква «с» остается в английской раскладке.
• Уменьшить размер базы данных. В базе данных название телефона присутствует только один раз и занимает, например, 30 символов. Во всех строках номеров телефонов стоит только ссылка, которая занимает 4 байта, что намного меньше. Если отказаться от справочника, то в каждой строке номера телефона уже будет съедаться не 4 символа, а 30, для хранения полного названия типа телефона. Конечно, можно использовать varchar, который хранит реальное значение и не резервирует полный доступный размер, но лишних затрат все равно будет достаточно.

На рисунке 1.11 показано окно программы Enterprise Manager, которая входит в состав MS SQL Server и позволяет визуально работать с базой данных. Чтобы было удобно видеть структуру, я создал визуальную диаграмму и добавил в поля описания их предназначения.

Связь между таблицами персонала (tbPeoples) и должностями (tbPosition) происходит по схеме один ко многим. Одной строке из таблицы таблицы должностей соответствует множество строк из tbPeoples. Связь между персоналом и телефонами (tbPhoneNumbers) происходит по схеме один ко многим. Одной записи из таблицы персонала может соответствовать несколько номеров телефонов. Между номерами телефонов и их типами снова связь один ко многим – одному типу телефона соответствует много номеров.

В листинге 1.11 показан код создания этой базы данных. Внимательно изучите его, потому что он резюмирует все, что мы рассматривали в этой главе. Текст, который находиться после символов — (два тире) является комментарием и не выполняется программой, а используется только для того, чтобы вам проще было разобраться с выполняемыми действиями.

Листинг 1.11. Создание базы тестовой данных

Помимо этого, создадим еще и таблицу с русскими именами, которая не связана с предыдущими таблицами:

Эта таблица проста, но пригодиться в будущем при тестировании некоторых операторов, особенно во второй главе.

Обязательно создайте эту базу данных на своем SQL сервере, потому что мы будем использовать эту структуру в последующих главах для тестирования примеров.

Name already in use

opensql / tsql_standart.md

• Go to file T
• Go to line L
• Copy path
• Copy permalink

• Open with Desktop
• View raw
• Copy raw contents Copy raw contents

Copy raw contents

Copy raw contents

Стандарт оформления T-SQL

Объект	Длина	Префикс	Допустимые символы	Пример
Database	30	[A-z]	MyDatabase
Schema	30	[A-z][0-9]	MySchema
Database Trigger	50	DTR_	[A-z]	DTR_CheckLogin
File Table	128	FT_	[A-z][0-9]	FT_MyTable
Global Temporary Table	128	##[A-z][0-9]	##MyTable
Local Temporary Table	128	#[A-z][0-9]	#MyTable
Table	30	[A-z][0-9]	MyTable
Table Column	30	[A-z][0-9]	MyColumn
Table Default Values	128	DF_	[A-z][0-9]	DF_MyTable_MyColumn
Table Check Column Constraint	128	CK_	[A-z][0-9]	CK_MyTable_MyColumne

Завершайте каждый оператор в задании точкой с запятой

Признак конца инструкции Transact-SQL. Хотя точка с запятой не требуется для большинства инструкций, но она понадобится в следующей версии Хорошо:

Ограничьте длину строки максимум 79 символами. Для более длинных блоков текста с меньшими структурными ограничениями (строки документации или комментарии), длину строки следует ограничить 72 символами. Ограничение необходимой ширины окна редактора позволяет иметь несколько открытых файлов бок о бок, и хорошо работает при использовании инструментов анализа кода, которые предоставляют две версии в соседних столбцах

Создавайте комментарии в хранимых процедурах, триггерах и скриптах, когда что-либо не является очевидным. В первую очередь пишите зачем нужен этот код, а не что он делает

Используйте шапку для процедур / триггеров / функций

Не используйте * в запросах. Указывайте названия столбцов явно

Разница будет и во времени выполнении запроса и в том, что будет возможность сделать меньше логических чтений за счет покрывающего индекса Хорошо:

Используйте нативные названия переменных. Избегайте аббревиатур и односимвольных имен

Это поможет понять код Вам и Вашим коллегам Хорошо:

Соблюдайте DRY (не повторяйтесь)

Принцип DRY формулируется как: «Каждая часть знания должна иметь единственное, непротиворечивое и авторитетное представление в рамках системы» Нарушения принципа DRY называют WET — «Write Everything Twice» (рус. Пиши всё по два раза) Хорошо:

Best practice: Используйте инструкцию SET — для констант, SELECT — для литералов

Используйте CamelStyle или under_score для именования составных пользовательских объектов

Используйте префиксы для именования объектов

Не используй префикс «sp_ » в имени своих хранимых процедур: Если имя нашей процедуры начинается с «sp_», SQL Server в первую очередь будет искать в своей главной базе данных. Дело в том, что данный префикс используется для личных внутренних хранимых процедур сервера. Поэтому его использование может привести к дополнительным расходам и даже неверному результату, если процедура с таким же имененем как у вас будет найдена в его базе.

• P — User Stored Procedures
• V – Views
• FN — Scalar Valued Functions
• TF — Table Valued Functions
• FK — Foreign keys
• DF — Default constraints
• IX — Indexes
• TR — Trigger

(Рекомендуется) Используйте имена таблиц — в единственном числе

Единственным разумным доводом для этого утверждения является тот факт, что в Английском языке, у некоторых слов, форма множественного числа описывается не явно Хорошо:

Вставка во временные таблицы

При вставке во временную таблицу без использования дополнительных архитектурных настроек, используйте конструкцию SELECT * INTO #table FROM… Это поможет избежать двух лишних компиляций

Наименование foreing key — используйте сначала имя родительской таблицы

Используй имя схемы с именем объекта

Данная операция подсказывает серверу где искать объекты и вместо того чтобы беспорядочно шарится по своим закромам, он сразу будет знать куда ему нужно пойти и что взять. При большом колличестве баз, таблиц и хранимых процедур может значительно сэкономить наше время и нервы.

Много / одно — строчные операторы

Правильно организуйте операторы

Хорошо, однострочный оператор:

Хорошо, многострочный оператор:

Не хорошо (лишний перевод строки):

Не хорошо (условие and должно стоять в начале условия):

Избегайте смешивания подходов (отсутствует перевод строки перед FROM):

При определении сложных условий, описывайте каждое условие на новой строке. При этом каждая строка должна начинаться с оператора AND | OR. Исключением может быть случай, когда два или более условия накладываются на один и тот же столбец — в этом случае их можно разместить на одной строке.Делайте отступы, соответствующие уровню вложенности условий. Обозначайте скобками группы условий только там, где это необходимо — объединяя группы из условий ИЛИ условием И.

Отступы, область видимости

При создании области видимости всегда делайте отступ. (Рекомендация от себя: при сложных конструкциях, оставляйте комментарии в конце большой конструкции) Хорошо: