Помощь со скриптом
Добрый день!
Помогите пжл разобраться с синтакисом в скрипте SQL.
Вот так выглядит в оригинале:
SELECT loc1.fieldid [start]
,loc1.fieldxloc [startx]
,loc1.fieldyloc [starty]
,loc1.fieldzloc [startz]
Не понимаю, что означают значения в квадратных скобках?
Сильно не пинайте, только учусь.
Данные Мосбиржи в эл.таблицу
Ребят, привет.
Интересует такой вопрос:
Есть ли возможность добавить исторические данные тикеров Мосбиржи в электронную таблицу?
Знаю, что у майкрософт в лицензионном софте есть в data данные по акциям, берущиеся из refinitiv.com. Но там общие данные об эмитенте и цена на текущий момент с размахом.
Гугл таблицы исторические данные имеют, но только не для мосбиржи.
Подойдут варианты с добавлением в злоебучий аксесс, либо в sql-подобный сервер, либо сразу в power bi.
насколько я знаю, у мосбиржи есть api через python, но, к сожалению, руки не доходят его изучить.
заранее всем спасибо
Помогите новичку)
Подскажите, как в запросе sql обращаться к полям, если у них названия на русском языке? Как должен писаться запрос?
SQL создание таблиц используя код
В БД создать 3 таблицы colors, cars, manufacturer(здесь и далее используя оператор(ы), а не графический интерфейс).4. В color поместить значений: белый, черный, красный5. В manufacturer: toyota, nissan, mitsubishi6. Cars: названия машин и сделать связку с color, manufacturer (здесь подскажу по структуре: все таблицы помимо значений будут иметь уникальные id. Соответственно нужно, что бы таблица color имела структуру id, color_name; cars: id, color_id, manuf_id, car_name).
Спасибо!
Как обойти ограничение в 1000 элементов для оператора IN в ORACLE
Рано или поздно, каждый специалист, работающий с базами данных ORACLE, наталкивается на ограничение максимального количества элементов для оператора IN:
SELECT *
FROM VOUCHERS
WHERE CLIENT_ID IN (28, 45, 46, 102,...)
В ORACLE для оператора IN в скобках можно перечислять не более 1000 элементов через запятую.
Иногда этого количества может не хватать. Что делать в этом случае?
Во-первых, давай рассмотрим случай когда такого большого количества может не хватать? Не каждый день составляешь запрос и вручную перечисляешь через запятую тысячу элементов, верно? :)
На самом деле, SQL-запросы могут формировать и программы (прямо налету), а не люди. Например, в некотором приложении пользователь нажал кнопку, согласно которой должны выбраться все счета из таблицы VOUCHERS базы данных, но именно счета видимых в данный момент на экране (а список клиентов определённым образом отфильтрован).
И программа динамически строит запрос, как я и написал выше, где в скобках для оператора IN перечисляются идентификаторы видимых на экране клиентов. И далее этот запрос для отчёта или для другой экранной формы должен выбрать данные.
SQL-запросы с большим количеством элементов для оператора IN могут составляться не только программно, но и человеком. Однажды написанный SQL запрос с оператором IN/NOT IN, может со временем, дорабатываться и включать в себя всё новые элементы. Через какое-то время количество элементов у оператора IN/NOT IN может превысить установленный Ораклом лимит и такой запрос не сможет быть выполненным.
Как-то одному из разработчиков ORACLE задали вопрос: почему именно 1.000 элементов и не планируется ли в будущих выпусках ORACLE увеличить этот лимит?
На что разработчик ответил: а какой бы Вы хотели иметь лимит? 2.000, 5.000, или, может быть, 100.000? Вы можете написать SQL более оптимально и не придётся перечислять такое большое количество элементов для оператора IN.
Как можно поправить SQL запрос, убрав ограничение в 1.000 элементов?
Способ первый:
Использование (временной) таблицы. (Временная) таблица (пусть называется TMP_TABLE) заполняется значениями (например, идентификаторами клиентов) и далее они используются в ограничении выборки путём INNER JOIN-а с этой таблицей или её также можно использовать в IN:Сначала заполняем (временную) таблицу:
INSERT INTO TMP_TABLE
(CLIENT_ID)
VALUES
(28);
INSERT INTO TMP_TABLE
(CLIENT_ID)
VALUES
(45);
...
И далее используем её для ограничения вывода данных из основной таблицы:
SELECT v.*
FROM VOUCHERS v
INNER JOIN TMP_TABLE t
ON v.CLIENT_ID = t.CLIENT_ID
Или так:
SELECT *
FROM VOUCHERS
WHERE CLIENT_ID IN (SELECT CLIENT_ID FROM TMP_TABLE)
Способ второй:
Использование нескольких операторов IN:SELECT *
FROM VOUCHERS
WHERE ( CLIENT_ID IN (28, 45, 46, 102,...)
OR CLIENT_ID IN (1789, 1800,..) )
Есть и ещё способы обойти ограничения в 1.000 элементов оператора IN в ORACLE, о них ты можешь почитать тут.
Программы, строящие SQL-запросы динамически и с применением IN, контролируют сколько элементов размещается в скобках через запятую. При большом количестве элементов, они будут размещены в нескольких операторах IN, соединённых между собой оператором OR (второй способ).
Буду рад, если оценишь статью лайком и подпишешься на мой канал, если ещё не подписан.
Неявные ошибки в SQL запросах
Проверяя работу наших учеников курса "SQL. Базы данных. ORACLE", и даже курса "Программирования в PL/SQL (ORACLE)" иногда встречаю следующее использование функции to_date, которое содержит ошибку. И сейчас напишу почему. Итак, вот конструкция, содержащая ошибку:
to_date(sysdate, 'dd.mm.yyyy')
Функция to_date служит для преобразования ТЕКСТА в дату согласно указанной маске, а в примере выше функции на вход даётся итак дата (sysdate ведь дата, только ещё и со временем). Во-первых, неразумно из итак даты делать дату, иначе будет как в мультфильме про Кунг-фу панду:
-Ты не должен делать из них себя, ты должен делать из них их;
-Как я могу делать из них их, если они итак уже они? :)
Почему же эта конструкция ещё и содержит ошибку. Ошибка в том, что в этой конструкции Ораклу придётся задействовать неявное преобразование.
Чтобы функция to_date смогла отработать, она должна принять на вход ТЕКСТ и преобразовать его в дату, согласно указанной маске. А в примере выше Ораклу подаётся дата, ведь sysdate это итак дата (текущая, со временем). И Оракл сначала неявно преобразовывает ее в текст, а вот как он это выполняет без указанной макси преобразования, может зависеть от региональных настроек представления даты. В итоге дата в текст может быть преобразована совсем другая (будет другой день, месяц или год). И уже из текста, в котором может быть совершенно неожиданно другая дата, to_date сделает дату согласно указанной маске. Результат может быть неожиданным.
Неявного преобразования всегда нужно избегать. Это может привести к скрытым ошибкам. Все работает (ORACLE не показывает ошибку), а данные в результате в самый неподходящий и ответственный момент будут получены не правильные.
Я обычно всегда спрашиваю ученика для чего такая конструкция была сделана и что требовалось здесь получить. В итоге, чаще всего, нужна бывает текущая дата без времени. Текущую дату со временем в ORACLE даёт функция SYSDATE, и чтобы отбросить у неё часы, минуты и секунды (то есть чтобы сделать ее просто датой), можно обернуть её в функцию trunc. Функция trunc сделает из неё дату без времени (усечёт часы, минуты и секунды). То есть конструкцию:
to_date(sysdate, 'dd.mm.yyyy')
лучше заменить на:
trunc(sysdate).
Буду рад лайку этой статье и твоей подписке на мой канал, если ты еще не подписан.


