А ещё есть электромагнитные ливни, когда высокоэнергетичный гамма фотон при попадании в вещество рождает электрон-позитронную пару, дальше, каждый из пары излучает тормозной фотон, и если у этих двух фотонов достаточная энергия, процесс повторяется.
Зря вы так про приус, хорошая, очень просторная для пассажиров, и очень надёжная машина. А в качестве замены баофенгам, могу порекомендовать Quansheng TG-UV2, в условиях гор гораздо лучше.
Даже если и чистое, оно же не бесшумное. Постоянно пролетающее гудящее нечто только в фильме красиво, а когда ты неподвижен и мимо тебя оно туда-сюда, туда-сюда, надоест. Не говоря уже о том, что при падении (оно же будет падать, пусть и очень редко?) площадь поражения будет больше, чем у автомобиля.
Меня, в этом отношении, даже массовая доставка дронами не возбуждает. Либо это должны быть маршруты не задевающие своим шумовым загрязнением людей.
У меня один диапазон 2.4ГГц. Конфигами не поделюсь, извините, чтобы случайно не поделиться секретами, там ещё несколько впн клиентов поднято. Я не настолько в микротике понимаю, обычный домашний пользователь, а разобраться в конфиге нужно время.
Когда-то был восхищён неубиваемостью точек ruckus (там, кстати, тоже честный beamforming), но когда встал вопрос о прозрачном роуминге, чтобы покрыть бОльшую площадь, стало понятно, что без контроллера не обойтись. Покупать контроллер для трёх точек, накладно.
В итоге сейчас сеть построена на роутере mikrotik, точках доступа wAP и встроенном ПО CAPsMAN, где контроллером выступает роутер. Быстровозводимое, надёжное решение, которое не требует внимания. Дома сделал также. Единый SSID по всей площади. В процессе перекидывания с точки на точку, если, идти например с ноутбуком с включенным пингом, теряется один пакет. Если говорить через sip или видеосвязи, вообще не заметно.
Далеко не обычно. В больших таблицах кластерный индекс (например по дате операции) ещё и определяет схему секционирования (в MSSQL). И никак не связан с первичным ключём, который определяет уникальность записи.
Во-первых, я не вижу никакой разницы между вашими примерами, что вы этим хотели показать – загадка.
Во-вторых, вы с собой договоритесь с версией происходящего, у меня «распространённое заблуждение», или всё таки «ваше IMHO».
В-третьих, alias (псевдоним) на то и псевдоним, чтобы использовать его на своё усмотрение для повышения читаемости кода.
Вот, кстати, что по этому поводу пишет technet.
спойлер
Удобочитаемость инструкции SELECT может быть улучшена с помощью псевдонима таблицы, известного также как корреляционное имя или переменная диапазона. Псевдоним таблицы можно назначить с ключевым словом AS или без него:
table_name AS table alias
table_name table_alias
В следующем примере псевдоним c назначается таблице Customer, а псевдоним s — таблице Store.
USE AdventureWorks2008R2;
GO
SELECT c.CustomerID, s.Name
FROM Sales.Customer AS c
JOIN Sales.Store AS s
ON c.CustomerID = s.BusinessEntityID ;
Видимо я код изучаю сильно чаще, чем данные, мне на данные плевать) да и смотрю я их в приложении, где поля уже построены так, как требует потребитель. А вот код наоборот, ускорить выполнение, понять почему криво работает фильтр и т. д.
Про осмысленные алиасы – хорошо, когда таблиц немного, или они все имеют разные корни, а когд много похожих названий, сокращения становятся всё длиннее и неудобнее, не только читать, но и писать.
Так пишут многие, поэтому я и спрашиваю «как выглядит». Но я честно, не вижу в этом удобства, все таблицы перемежаются ключевыми словами, и тяжело вычленить алиасы, они все на разных уровнях? Результаты можно поизучать с лёгким неудобством, во имя удобства последующего чтения (все поля таблицы примерно в одном месте).
Двойные кавычки не работают, но зато есть такое ключевое слово как AS и спокойно переваривает только такую запись: SELECT name as Имя_товара FROM goods; хотя во многих случаях AS можно упустить, но сразу теряется в наглядности.
Вот согласен на 100%, не надо ничего опускать, читать же неприятно.
Кстати, о наглядности, интересно, какое у присутствующих мнение по поводу такой записи:
SELECT a.ClientID
,a.ClientName
,a.ProductID
,a.ManagerID
,b.ProductName
,c.ManagerName
FROM Clients a
LEFT JOIN Products_view b ON a.ProductID=b.ProductID
LEFT JOIN Managers c ON a.ManagerID=c.ManagerID
WHERE a.ClientName LIKE '%'
AND
((@ManagerName IS NULL) OR (@ManagerName IS NOT NULL AND b.ManagerName=@ManagerName))
AND
c.ProductName LIKE @ProductName+'%'
ORDER BY a.ClientName
,b.ManagerName
смысл записи примерно в следующем:
1. каждое ключевое слово и поле на новой строке
2. запятые перед полями, в столбик, а не в конце где они рассыпаются в зависимости от длины наименования поля
3. псевдонимы присоединяемых таблиц присваиваются последовательно, по алфавиту, у всех псевдонимов одинаковая длина (зачастую она буква)
4. псевдонимы выровнены так, чтобы быть в одну колонку, а искать выбранные поля из конкретной таблицы становится просто
5. поля в выборку пишутся по алфавиту псевдонима таблицы (сначала поля таблицы a, потом b, потом c и т. д.)
6. условия WHERE по каждому полю пишутся каждое на новой строке
7. параметры сортировки пишутся в столбик, как поля в разделе SELECT
Всё это, чтобы повысить читабельность выборок с большим количеством присоединённых таблиц и/или условий выборки.
Вот, например, об этом https://geektimes.ru/post/275480/
первая картинка хорошая, введите пароль или приложите палец. и конечно, чувак начинает вводить пароль.
@Uneverse
Ученик(будуЙШий програмист)
Зря вы так про приус, хорошая, очень просторная для пассажиров, и очень надёжная машина. А в качестве замены баофенгам, могу порекомендовать Quansheng TG-UV2, в условиях гор гораздо лучше.
Даже если и чистое, оно же не бесшумное. Постоянно пролетающее гудящее нечто только в фильме красиво, а когда ты неподвижен и мимо тебя оно туда-сюда, туда-сюда, надоест. Не говоря уже о том, что при падении (оно же будет падать, пусть и очень редко?) площадь поражения будет больше, чем у автомобиля.
Меня, в этом отношении, даже массовая доставка дронами не возбуждает. Либо это должны быть маршруты не задевающие своим шумовым загрязнением людей.
У меня один диапазон 2.4ГГц. Конфигами не поделюсь, извините, чтобы случайно не поделиться секретами, там ещё несколько впн клиентов поднято. Я не настолько в микротике понимаю, обычный домашний пользователь, а разобраться в конфиге нужно время.
А, ну и главное, помимо надёжности – цена. Роутер hAP ac (он же одна из точек) 6к. руб., одна точка wAP ac 4к. руб.
Когда-то был восхищён неубиваемостью точек ruckus (там, кстати, тоже честный beamforming), но когда встал вопрос о прозрачном роуминге, чтобы покрыть бОльшую площадь, стало понятно, что без контроллера не обойтись. Покупать контроллер для трёх точек, накладно.
В итоге сейчас сеть построена на роутере mikrotik, точках доступа wAP и встроенном ПО CAPsMAN, где контроллером выступает роутер. Быстровозводимое, надёжное решение, которое не требует внимания. Дома сделал также. Единый SSID по всей площади. В процессе перекидывания с точки на точку, если, идти например с ноутбуком с включенным пингом, теряется один пакет. Если говорить через sip или видеосвязи, вообще не заметно.
Во-вторых, вы с собой договоритесь с версией происходящего, у меня «распространённое заблуждение», или всё таки «ваше IMHO».
В-третьих, alias (псевдоним) на то и псевдоним, чтобы использовать его на своё усмотрение для повышения читаемости кода.
Вот, кстати, что по этому поводу пишет technet.
table_name AS table alias
table_name table_alias
В следующем примере псевдоним c назначается таблице Customer, а псевдоним s — таблице Store.
ссылка.
Про осмысленные алиасы – хорошо, когда таблиц немного, или они все имеют разные корни, а когд много похожих названий, сокращения становятся всё длиннее и неудобнее, не только читать, но и писать.
Вот согласен на 100%, не надо ничего опускать, читать же неприятно.
Кстати, о наглядности, интересно, какое у присутствующих мнение по поводу такой записи:
смысл записи примерно в следующем:
1. каждое ключевое слово и поле на новой строке
2. запятые перед полями, в столбик, а не в конце где они рассыпаются в зависимости от длины наименования поля
3. псевдонимы присоединяемых таблиц присваиваются последовательно, по алфавиту, у всех псевдонимов одинаковая длина (зачастую она буква)
4. псевдонимы выровнены так, чтобы быть в одну колонку, а искать выбранные поля из конкретной таблицы становится просто
5. поля в выборку пишутся по алфавиту псевдонима таблицы (сначала поля таблицы a, потом b, потом c и т. д.)
6. условия WHERE по каждому полю пишутся каждое на новой строке
7. параметры сортировки пишутся в столбик, как поля в разделе SELECT
Всё это, чтобы повысить читабельность выборок с большим количеством присоединённых таблиц и/или условий выборки.