Косая черта-звездочка (блочный комментарий) (Transact-SQL)
Обозначает текст комментария пользователя. Текст между /* сервером не */ вычисляется.
Синтаксис
/* text_of_comment */ Сведения о синтаксисе Transact-SQL для SQL Server 2014 (12.x) и более ранних версиях см . в документации по предыдущим версиям.
Аргументы
text_of_comment
Текст комментария. Это одна или более символьных строк.
Замечания
Комментарии могут вставляться в отдельную строку или в пределах инструкции Transact-SQL. Несколько строковый комментарий должны быть указаны в /* и */. Стилистическое соглашение часто используется для нескольких строковый комментарий, заключается в том, чтобы начать первую строку с /*, последующие строки с **, и заканчиваться */.
Длина комментариев не ограничена.
Поддерживаются вложенные комментарии. Если шаблон символов /* возникает в любом месте существующего комментария, он рассматривается как начало вложенного комментария и, следовательно, требует закрытия */примечание. Если метки, закрывающей комментарий, нет, выдается ошибка.
Например, следующий код вызовет ошибку:
DECLARE @comment AS VARCHAR(20); GO /* SELECT @comment = '/*'; */ SELECT @@VERSION; GO Чтобы избежать этой ошибки, внесите следующее изменение:
DECLARE @comment AS VARCHAR(20); GO /* SELECT @comment = '/*'; */ */ SELECT @@VERSION; GO Примеры
В приведенном ниже примере комментарии используются для пояснения действий, выполняемых блоком кода.
USE AdventureWorks2022; GO /* This section of the code joins the Person table with the Address table, by using the Employee and BusinessEntityAddress tables in the middle to get a list of all the employees in the AdventureWorks2022 database and their contact information. */ SELECT p.FirstName, p.LastName, a.AddressLine1, a.AddressLine2, a.City, a.PostalCode FROM Person.Person AS p JOIN HumanResources.Employee AS e ON p.BusinessEntityID = e.BusinessEntityID JOIN Person.BusinessEntityAddress AS ea ON e.BusinessEntityID = ea.BusinessEntityID JOIN Person.Address AS a ON ea.AddressID = a.AddressID; GO Что значит Звёздочка (*) в Access
Что значит звездочка в условии при выполнении запроса Access и что будет, если ввести условие запроса без звездочки?
Лучший ответ
Остальные ответы
Слово со сноской Бренд или торговая марка
select * from mytable;
(вывести все поля из таблицы mytable)
select str from mytable where str like «ted*»;
(вывести поле str, в котором содержится текст, начинающийся на «ted» и заканчивающийся любым текстом)
. Like «Солнечный» — это значит, что текстовое поле содержит (равно) значение «Солнечный» и никакой другой текст
Солнечный* выводит все комбинации, где будет встречаться Солнечный с начала слова. Например «Солнечный бульвар», «Солнечный что-то там», «Солнечныйваопрваплв»
если без звездочки, то выводится строго «Солнечный».
Access SQL. Предложение SELECT
Это статья из цикла статей о языке SQL для Access. В ней описано предложение SELECT и приведены примеры, поясняющие различные методы, используемые при его составлении.
Общие сведения о языке SQL для Access см. в статье Access SQL. Основные понятия, лексика и синтаксис.
В этой статье
- Выбор полей: предложение SELECT
- Выбор всех полей
- Выбор отдельных значений
- Использование псевдонимов полей или выражений: ключевое слово AS
- Использование выражения при выборе
Выбор полей: предложение SELECT
Инструкция SELECT обычно начинается с предложения SELECT. В предложении SELECT указываются имена полей, которые содержат данные, используемые в запросе. Вместо полей или вместе с ними также можно использовать выражение. В качестве поля можно даже использовать ещё одну инструкцию SELECT — это называется вложенным запросом.
Предположим, что вы хотите узнать телефонные номера клиентов. Пусть поле, которое содержит телефонные номера клиентов, называется txtCustPhone, тогда предложение SELECT будет выглядеть следующим образом:
Имя можно заключить в квадратные скобки. Если имя не содержит пробелов или специальных знаков (например, знаков препинания), скобки можно не использовать. Если имя содержит пробелы или специальные знаки, скобки необходимы.
Совет: Имена, которые содержат пробелы, проще читать и сэкономить время при создании форм и отчетов, но в итоге при создании SQL ввести текст. Следует учитывать этот факт при именовывом имени объектов в базе данных Access.
Если инструкция SQL содержит несколько полей с одинаковыми именами, в предложении SELECT к имени каждого поля необходимо добавить имя соответствующего источника данных. В качестве имени источника данных нужно использовать то же имя, что и в предложении FROM.
Выбор всех полей
Чтобы включить в запрос все поля из источника данных, можно указать их все по отдельности в предложении SELECT или использовать подстановочный знак — звездочку (*). Если используется звездочка, при выполнении запроса Access определяет, какие поля содержит источник данных, и включает все эти поля в запрос. Это позволяет обеспечить актуальность запроса в случае добавления в источник данных новых полей.
В инструкции SQL звездочку можно использовать и с несколькими источниками данных. В этом случае вместе с ней необходимо указать имя источника данных, чтобы приложение Access могло определить, из какого источника читать поля.
Предположим, например, что нужно выбрать все поля из таблицы Orders и только адрес электронной почты из таблицы Contacts. Предложение SELECT может выглядеть следующим образом:
SELECT Orders.*, Contacts.[E-mail Address]
Примечание: За использованием звездочки нужно внимательно следить. Если позднее в источник данных будут добавлены поля, которые использовать не планировалось, результаты запроса могут оказаться не такими, как ожидалось.
Выбор отдельных значений
Если вы знаете, что инструкция выбирает избыточные данные, а вам необходимы лишь отдельные значения, в предложении SELECT можно использовать ключевое слово DISTINCT. Предположим, например, что каждый клиент представляет несколько разных служб, в некоторых из которых используется один и тот же телефонный номер. Чтобы каждый телефонный номер был представлен только один раз, предложение SELECT должно выглядеть следующим образом:
SELECT DISTINCT [txtCustomerPhone]
Использование псевдонимов полей или выражений: ключевое слово AS
Чтобы изменить подпись поля в режиме таблицы, в предложении SELECT следует использовать ключевое слово AS и псевдоним поля. Псевдоним поля — это имя, которое назначается полю в запросе, чтобы результаты было удобнее читать. Например, при выборе данных из поля txtCustPhone, которое содержит телефонные номера клиентов, можно улучшить удобочитаемость результатов с помощью псевдонима поля в предложении SELECT следующим образом:
SELECT [txtCustPhone] AS [Customer Phone]
Примечание: Псевдоним поля необходимо использовать, если в предложении SELECT используется выражение.
Использование выражения при выборе
Иногда необходимо вывести результаты вычислений, основанных на выбираемых данных, или извлечь лишь часть данных поля. Предположим, например, что необходимо возвратить год рождения для всех клиентов, используя данные поля BirthDate. Предложение SELECT может выглядеть следующим образом:
SELECT DatePart(«yyyy»,[BirthDate]) AS [Birth Year]
Это выражение содержит функцию DatePart и два аргумента: : «yyyy» (константа) и [BirthDate] (идентификатор).
В качестве поля можно использовать любое допустимое выражение, если, принимая одно значение, оно возвращает также одно значение.
SQL-запросы. Нужно ли перечислять конкретные поля в SELECT?
В рамках данной статьи про SQL-запросы, я расскажу вам про то, нужно ли перечислять конкретные поля в SELECT, а так же какие при этом могут быть нюансы.
Базы данных предоставляют массу полезных возможностей, для облегчения процесса написания sql-запросов. Однако, периодически их бездумное применение может весьма заметно сказываться на производительности и возникновении ошибок. Это же касается и оператора SELECT с возможностью получить все поля выборки, только указав символ * (звездочка).
Конечно, когда речь идет о выборке небольшой таблицы с парой десятков строк и простейшими столбцами, то нет никакой необходимости перечислять поля в запросе. А уж если поля такой таблицы генерируются по мере необходимости, то звездочка сильно упрощает процесс получения данных, ведь нет никакой необходимости на серверной стороне заниматься рутинной задачей получения информации о колонках таблицы и составления динамического запроса.
Однако, всегда существуют ситуации, где необдуманное применение выборки всех полей может если не привести к ошибкам, то сказаться на производительности. И далее я приведу пару примеров в порядке — вначале простой и предугадываемый, затем более сложный.
Но, прежде, чем рассказывать, введем небольшую вводную. Представьте, что у вас есть две таблицы. Например, продукты и категории. Считаем, что продукт может быть только в одной категории. Вот так выглядят эти две таблицы.
| product_id | cat_id | name | desc |
|---|---|---|---|
| 1 | 1 | Продукт 1 | Длинное описание |
| . | . | . | Длинное описание |
| N | X | Продукт Z | Длинное описание |
| cat_id | name | desc |
|---|---|---|
| 1 | Категория 1 | Длинное описание |
| . | . | Длинное описание |
| Z | Категория Z | Длинное описание |
Вполне себе стандартные таблицы. А теперь, попробуем рассмотреть разные запросы для получения данных.
Первая ситуация. SQL-запрос для получения полных данных по каждому продукту. Если в такой ситуации вы не будете перечислять поля, а используете в SELECT звездочку, то в зависимости о БД и серверного кода, вы можете столкнуться с рядом проблем. Вот запрос.
-- Получим все поля сразу select * from `product` p join `cat` c on cat.cat_id = p.cat_id
Если вы запустите этот SELECT в админке БД, то никаких ошибок не появится и вы получите все товары с их категориями. Однако, если же вы попытаетесь использовать классы с динамическим присваиванием имен полей, например, в PHP, то возникнут проблемы. Дело в том, что колонки «name» и «desc» повторяются у таблиц. Это означает, что в результате при получении данных значения полей в том же PHP будут заменяться. К примеру, вместо описаний продуктов вы получите описания категорий.
Примечание: Стоит знать, что в зависимости от драйверов и типа БД, данный запрос может интерпретироваться по разному и так же результаты могут быть разными, но в большинстве своем они все будут приводить к ошибкам.
Если же вы перечислите поля и используете возможность указания названия полей в результатах SELECT, то с такой ошибкой вы не столкнетесь:
-- Получим нужные поля select p.product_id, p.name, p.desc, c.cat_id, c.name as cat_name, c.desc as cat_desc from `product` p join `cat` c on cat.cat_id = p.cat_id
Как видите, такой select запрос уже не приведет к проблемам на серверной стороне.
Примечание: Стоит понимать, что несмотря на то, что пример простой, в больших БД со сложной структурой такая мелочь может привести к существенным ошибкам.
Вторая ситуация. SQL-запросы для получения значений справочников. Каждый знаком с выпадающими списками. Чаще всего они используются в админках сайтов и, порой, во всяких формах обратной связи. Представим себе как раз ситуацию с некой формой, где вам нужно указывать отдельно товар и отдельно категорию. Чаще всего в такой ситуации используют два следующих запроса:
-- Получим все поля продукта select * from `product` -- Получим все поля категории select * from `cat`
Несмотря на то, что выглядят эти SQL-запросы вполне логичными, их применение может серьезно сказываться на производительности. И вот почему это происходит.
Когда у вас десяток строк в каждой таблице и сайт посещает сотня другая человек в день, то каких-то проблем не будет. Однако, если записей хотя бы 1000 и поля с описаниями заполнены хорошими объемными статьями в среднем по 3000 символов, то при большой посещаемости вы можете получать тормоза, несмотря на то, что задача элементарна.
Дело в том, что используя оператор * (звездочка) в SELECT, вы говорите БД, чтобы она вытаскивала не только нужные вам данные (идентификатор и название), но и все описания. А это значит, что каждый запрос потребует дополнительного возвращать по 3 Мб данных (1000 * 3000). Т.е. для отображения формы вам нужно дополнительно формировать 6 Мб данных. Что же будет, если хотя бы сотня пользователей откроет вашу страничку? Правильно, вначале БД придется передавать веб-серверу, а затем веб-серверу придется передавать браузерам пользователей 600 Мб. ненужных данных.
Примечание: Конечно, стоит знать, что БД предусматривают кэш запросов, ровно как и некоторые классы серверных приложений, однако на производительности это все равно сказывается.
Решается же эта проблема легко и элементарно:
-- Получим нужные поля продукта select `product_id`, `name` from `product` -- Получим нужные поля категории select `cat_id`, `name` from `cat`
Вроде бы указали всего пару полей, но в такой ситуации, БД уже не будет передавать эти 6 Мб лишних данных и пользователи не будут наблюдать тормоза на сайте.
Как видите, используя возможности SQL-запросов, того же SELECT и * (звездочки), всегда стоит задумываться о здравом смысле.