О, тепер ще й на запис буде. Фро-п-ро. Зіречко рідко хто ставить, частіше за все вказують, які саме колонки нам потрібно, але це ми точно вже пам'ятаємо декілька. По парі точно вже на практиці мали спробувати.
Прямо тут ми можемо... Пару етапів, якісь результати, яких в оригінальній таблиці немає. Відповідно, наприклад, зарплата плюс премія, плюс 100. Якщо нам не потрібні всі дані, ми з вами поговорили, є чудова команда V, яка дозволяє профільтрувати, і тут має бути якась логічна умова.
Наприклад, мені треба всі люди, у яких не порожня премія. Home is not now. Тоді давайте зарплату плюс премію. І нарешті порядок рядків не визначений до тих пір, поки я не попрошу.
І ми минулий раз завершили з вами тим, що додали ще одну команду Order By, яка задає, в якому самому порядку застосовується результат. Ну, давайте по третій колонці. Там може бути і назва колонки, і вираз який-небудь, і псевдоніми нарешті тут можна використати. На цьому ми з вами завершили.
Тепер мені треба зробити невеличкий назад крок, для того, щоб полегшити вам сприйняття матеріалу і трошки зрозуміліше було, що відбувається у вас на практиках. Бо коментарі, які я бачив в одному із каналів групи, мені підказали, що принаймні таке ліричне відступлення треба робити. Я запускаю зараз командний рядок і пишу тут команду. Наприклад, я хочу створити папочку tmp.
mkdir tmp. І ми розуміємо, що ця папка створюється не в цьому віконці чи в якомусь файлі, а насправді командний інтерпретатор бере текст. відправляє його на виконання в CMDX, який в свою чергу записує дані на диск про те, що створилася нова папочка TMP. І тепер, якщо хто-небудь інший звернеться до CMDX, він точно також сходить на диск і подивиться, що там є. І то точно також API від Windows сходить на диск і подивиться, що на диску є.
А у нас... просто текстовий рядочок, який записаний у командному рядку. Те саме із SQL.
Я зараз написав select і десь зберіг, неважливо, це текстовий файл чи що-небудь ще. Це просто текст, так само, як команда у мене в 7D. Цей текст мені якимось чином треба відправити у систему управління базами даних, тому Наступним кроком у мене буде або голий драйвер для з'єднання із базою даних, як я б робив би, якщо писав десь і використовував десь у своїй програмі. Я б взяв драйвер, встановив з'єднання, відправив результати, сам би розбирав.
Або, так, щоб нам зручно було, так, як зараз на екрані у нас є, у мене зараз запущений DataGrid. Хтось встановив PG-Admin, у когось встановлено DB Beaver. Це SQL-клієнти. Їх задача бути розумним текстовим редактором, який візьме текстовий від текстових файлів чи текстову команду в Select чи що-небудь ще. Сформують з нього, зробить з'єднання із СУБД.
У нашому випадку це частіше за все по ЗСКІ, який доступний на парті ТТСП. СП, локал, хост, 5, 4, 3, 2, і далі по замовченню співпадає база даних з ім'ям користувачам, тому просто РЕС. Але те, що воно розташоване по якійсь адресі, підказує, що може це бути зовсім і на нашому комп'ютері.
І частіше за все база даних виноситься кудись подалі від самого додатку. Якщо щось відбувалося, ми могли окремо працювати з базою даних, окремо з сервером додатку. І він запише все у базу даних.
Відповідно, прийде якийсь інший клієнт, він так само звернеться до PostgreSQL, якийсь в свою чергу звернеться до бази даних. Єдине, що різниться, у нас в СУБД кожен свою базу даних обслуговує. Напряму на диск залізти і щось з файлами цим зробити теоретично можна, але практичної користі від цього мало, де рідко хто так робить.
Наприклад, під час відновлення це потрібно. А так, у більшості випадків це і недоречно. Якщо з файловою структурою, так як я папочку створював, там є і Windows IP, і що не б...
і що-небудь ще, і багато хто на диск лізе і читає, то в випадку СОБД дані десь всередині, і вони нікому не світяться. Відповідно, питання, як перенести на інший комп'ютер, воно має під собою взагалі-то такий дуже спірний сенс. У нас просто текстовий вивід. Він нам потрібен для того, щоб ми його могли додати до нашої лабораторної роботи.
Щоб якщо у нас навернеться ноутбук, на якому запущена СОБД, ми спокійно могли взяти з лабораторної роботи набір команд, заново їх виконати і створити все, що треба. Так, як у вашій другій лабораторній роботі, ви бачили там файли pginit.sq. в якої просто текстова, в якій написана команда, як все створити.
Клієнт ці команди бере, заворачує в пакетики, відправляє в постгре, в постгре виконує роботу, повертає результат, наш клієнт інтерпретує результат. Тому, який саме клієнт ви будете використовувати, неважливо. Де ви зберете, як будете зберігати ваші команди, неважливо.
Воно все виконане. було один раз системою керування бази даних і записано на диск десь там у її недрах. Де для нас хай буде краще темним лісом?
Ми про внутрішню структуру подгреб поговоримо на початку наступного семестра. Для нас зараз це чорний ящик, куди ми навіть не таркаємося. Відповідно, який буде клієнт? Не принципово. Аби ми приєднувалися до одної бази даних і все.
Бо одно із СУБД, СУБД всю роботу свою зробить, прочитає, сформує результат, відправить і так далі. Підкажіть, будь ласка, з цим зрозуміло те, що ми написали у клієнті, неважливо, ми у блокноті написали, а потім командного рядка клієнт ПСКЛ запустили, чи якимось іншим чином, все буде абсолютно однаково, бо це просто проміжна ланка, яка... передає інформацію в сервер управління базами даних підкажіть аналогії всі зрозуміли так так другий момент на який варто звернути увагу про те що відбувається всередині Субиде у нас є десь файли записані на диску до яких Субиде бігає і читає інформацію Таблиці зазвичай бувають велетенські, гігабайти без проблем.
Нормальна таблиця, в якій декілька мільйонів рядків, декілька десятків мільйонів рядків. Суббд до них бігає і отримує інформацію для того, щоб обробити запит. Суббд явно відокремлена від диску, вона сама знає, куди побіжати, там є проміжний слой, який розповідає, де ті чи інші дані записані, де починається чи закінчується таблиця. І далі у нас є інформація, яку ми хочемо передати нашому клієнту, неважливо, це якийсь аплікейшн сервер чи наш SQL-клієнт, DB Beaver, DataGrip чи що-небудь ще.
Ми відправляємо SQL запит, база даних бігає за внутрішніми якимись представленнями, читає по маленькому блоку і тягне собі. І формує невеличку віртуальну табличку, яку можна назвати Result Set. набір результатів прочитала пакетик підходить поклала в результат прочитала пакетик підходить поклала в результат тут достатньо накопичилась інформації для того щоб уже якусь відповідь сформувати я відправлю цей скріль клієнти буде почищу за собою і продовжу накопичувати Тому навіть якщо у нас таблиця на кілька гігабайт, ми можемо давати відповіді досить швидко.
Вона почне відповідати, ще рядки, ще рядки, ще рядки, ще рядки, ще рядки, а всередині зберігає не так багато. Не треба для того, щоб, якщо я хочу, відмовно кажучи, передати таблицю розміром в гігабайт, мені не треба цей гігабайт розміщати у пам'яті Субеди. Взяв шматочок. Обробив, підходить, поклав результат, там накопичилось, відправили з клієнтом.
Накопичилось, відправили з клієнтом. Відповідно, мені мінімум треба тримати у пам'яті. Але у мене є десь внутрішня таблиця на диску записана, і є окремий результат, який я формую, що я буду відправляти клієнту. І тепер, якщо подивитися на нашу команду, То давайте подивимося.
From це робота з таблицею. Звідси я беру один рядочок і підправляю далі. Куди я відправляю?
Я відправляю у V, який каже, мені підходить цей рядок із таблиці, і чи ні. Тут я все ще продовжую працювати із таблицею, читаю, мені ці дані потрібні, чи ці мені дані не потрібні. І кожен раз береться один рядок, перевіряється один рядок. обробляється один рядок передається далі а далі мені треба зрозуміти що я буду повертати клієнту відповідно перша команда у мене це про формування тої віртуальної таблички результат сета де я буду накопичувати результати у мене сформувалися підходящий рядочок є я її відправлю і збережу віртуальні таблички Result Set, які я потім колись передам клієнту.
І, відповідно, це у нас рядочок 3. Він стоїть по виконанню наче третім, але база даних сперша ж місцем, де себе має підготувати, куди саме результати буде записувати. Тому по запиту він стоїть першим. І тому, якщо я...
тому якщо я напишу ось тут колонку ком це збезначає це місце куди я буду складати це колоночка заготовлена в результаті куди я буду складати результати із відповідних рядків якщо я тут напишу їй тимчасове ім'я комішн це в результаті я заведу колоночку, яку я позначу комішн, і в цю колоночку я буду складати дані з таблиці, із колонки ком. Але якщо я напишу отут комішн, то стривайте. В у мене фільтрує дані із таблиці.
У таблиці є колонка комішн? Ні, її немає. Колонка Commission з'являється у віртуальному результат-сеті, який я буду відправляти клієнту. Відповідно, у V використовувати псевдоніми не можна, бо це фільтр для таблиці, а це, де ми збираємо результати. Ну і нарешті, а сортувати що ми будемо?
Дані з таблиці чи той результат, який ми хочемо клієнту надіслати? Мабуть, той результат, який хочемо натиснути клієнту. Відповідно, останню очію виконується ордербай.
І виконується він саме для того, що ми збираємося відправляти клієнту. Для нашої віртуальної таблички Result Set. Можемо відсортувати, відсортували, відправили. Відповідно, тут... Псевдоніми використовувати можна, бо ми сортуємо саме результати, які ми збираємося відправити клієнту.
Тому начебто якось дивно, там можна псевдоніми, а там не можна псевдоніми. Порядок якийсь дивнуватий, але за ним все ж якась логіка прослідковується. From і With це робота з даними з таблиці. Select що ми будемо повертати клієнту, а Order By в якому порядку.
ми будемо повертати це клієнту. Єдиний, хто порушує ось такий порядок виконання, це MySQL, який дозволяє у конструкції V використовувати вже псевдонім. Але наскільки це правильно, відверто кажучи, я не впевнений.
Так, воно по ходу читання запиту логічно, а ось по порядку його виконання, ну, не зовсім логічно. Тому це як синтаксичний цукор можна розраховувати, але підтримка з боку інших баз даних тут зовсім ніяка, окрім MySQL ніхто в не вміє використовувати псевдодніми, які ми в селекті задали. Перезупиняюся на секундочку, підкажіть, будь ласка.
ці аналогії те як розповів воно зрозуміло чи потребує все ж таки якогось додаткового уточнення ще раз це робота з таблицями Select це куди ми будемо писати результат В як ми будемо в якому порядку ми будемо результат тому це просто трошки різні речі розповідь тому і що можемо використовувати що не можемо використовувати трошки різних Добре давайте тоді продовжимо з тим що у нас зараз є ми з вами сказали що конструкція в підтримує будь-які умови аби це повертали для поточного рядка істина або лож Насправді у нас трошки гірше з істина або лож, бо є іще значення хто з нескільки. І хто з нескільки це істина і не лож, бо я не знаю це хто з нескільки. Але точно не істина. Тому я не впевнений, що це істина, тому пропускати не буду.
Ми з вами проговорили про стандартні оператори, які нам надає SQL, і там все начебто було зрозуміло. Більше, менше, менше дорівнює, більше дорівнює, не дорівнює. Із екзотичного тільки був ізнотнув або ізнув.
Це порожньо, точно, от якраз для того, щоб перевірити, ми можемо ними скористатися. Але ми явно розуміємо, що умов різних може бути набагато більше, відповідно, якимось чином треба їх записати. Підкажіть, будь ласка, зараз має бути PowerPoint у мене на екрані.
Так, видно. Так, і тепер у вигляді презентації на повний екран. Так.
Так. Так, із того, що є незвичним у порівнянні із більшістю мов програмування, що ми можемо написати у конструкції V? По-перше, це between. знаходиться у якихось межах. Наприклад, всі пари, які є у цьому семестрі.
Тобто ті, що починаються з 12.08 і закінчуються 1 грудня. От якраз бітвін для цього. Мені треба всі люди, у яких зарплата від 1000 до 2000. Салари так, 1000. Стандарт не оговорює про строго чи не строго равенство.
Але більшість реалізацій, які я зустрічав, вони і верхню, і нижню межу включають. Тобто у нас можна записати знак, як умови, як зарплата більше або дорівнює півтори тисячі, та менше або дорівнює дві тисячі. Бітвін зручний, працює для всіх типів даних, які між собою можна порівняти. Для чисел, для дат, для рядків.
З приводу рядків, як для себе уявити, у нас є люди. Select, Ename, From, EMP, Order, Buy, по-перше, колонці. Чому у нас Adams написано вище за Allen? Тому що цей рядок менше за рядок Allen. Тому що перша буква одна, однакова, а друга D менше, ніж L.
Код. літери D, чи D стає раніше за алфавітом, за L. Відповідно, рядок Adams буде менше за рядок Allen. Рядок Allen з іншими буде те саме.
Подивилися на першу літеру, подивилися на другу, на третю і так далі. Бітвін це просто більш розумний оператор, більше-менше, тому для так само в проміжках можна використовувати і можна використовувати і такові константи без проблем буде прекрасно працювати вибори ми всі мені всіх людей від одного до іншого від Адамса до Форда А чому б ні всіх людей від Адамса до Форда Пам'ятаємо, що порівняння з строковими літералами у нас по замовченню чутливе до регістру. Тобто великими літерами написано і маленькими літерами написано. Це дві людини. Так, порядок, щоб нам зрозуміли по імені.
Ось вони від Адамса до Форда вивелись по єдному імені. що-то різне хоч було є ним тому бітвін наче він зручний він корисний і час від часу ним користуєшся підтримує всі типи даних які ми можемо впорядкувати А це у нас більшість значення є другий варіант якщо мені треба вибрати із цього переліку тільки окремих людей Адамса Алана і Блейка Мені б хотілося зручний спосіб, як би написати, що саме цих трьох людей треба і вибрати. І в мене на допомогу приходить оператор Ін, який каже, мені, будь ласка, порівняй рядочок, і якщо моє ім'я входить в цей список, то добре. Як не входить, то нічого страшного, бери, перевіряй наступний рядок. З фіксованими такими переліками Ін.
Ну, так собі, відверто кажучи, по корисності. Бо так, щоб довгий перелік і відразу, ну, зустрічається, але... Зустрічається і часто зустрічається неправий. А ще далі ми будемо говорити про динамічне формування цих списків. Тобто, коли нам один запит принесе всі значення, які цими треба перевірити, і потім ми в іні будемо з цим динамічно сформованим списком.
перевіряти, там ще більше буде користі від ІНА. Це потужний оператор. І коли у вас є там перелік довгий, айдішок яких-небудь чи номерів, чи що-небудь, ще знайти, хто ж там за цими айдішками стоїть, оператор ІН тут якраз найкращий варіант. Знайти одне це познаку дорівнює, а знайти щось із переліку це якраз оператор ІН.
у цьому дуже сильно допомагає Ну і є зворотні йому нот і всі ті хто не в переліку теж буває досить корисно Ну і нарешті посередині між бітвіном і і нам у нас є чудовий оператор лайк який підтримується абсолютно всіма базами даних Так виходить що в нас З порівняння із рядками зводилися до більше-менше, починаючи з Алана, заканчуючи Фордом, включено, значить більше А дорівнює Алана, менше дорівнює Форда. Або точним співставленням. Ім'я точно дорівнює Адамс.
Ім'я точно дорівнює Алана. А як мені вибрати всіх людей, які починаються на літеру А? Перелічити їх я не знаю, можуть будуть інші люди додані. Сказати between, теж не так добре. Between починається з А і закінчується на Б.
Буде працювати до тих пір, поки не з'явиться людина, яку звуть Б, і тоді він теж у списку появиться. А я дуже хочу вибрати всіх людей, чиї ім'я починається саме на літеру А. І тут мені до допомоги приходить оператор Like, який є якраз у всіх базах даних, де ми можемо використовувати не один до одного співставлення з зразком, а певні шаблони.
І шаблони край примітивні. У них є буквально два символи для підстановки. Це так, так.
Нижні підкреслення і процент. Все правильно поставив. Де відсоток це 0 або б'єте скільки завгодно символів.
Це 0 або. А нижні підкреслення це строго один якийсь символ. Я не знаю, який, але він там є.
Давайте подивимося, що у нас вийшло. У нас умова. Ім'я відповідає шаблону перша літера А, а потім 0 або більше будь-яких символів.
Ось вони є. А є люди, яких ім'я завершується на літеру А. Нуль або більше будь-яких символів, а потім А.
Все, це тільки кінець рядку. Ні, таких немає. А так, щоб всередині була літера А. О, а таких багато.
Наприклад, Блейк вивели тому, що під перший відсоток нуль або більше будь-яких літер підійшли букви F, B і A. Потім A наша, а потім K і E під другий підкреслення. А є люди, у яких літера A стоїть на другому місці.
І тут якраз наші нижні підкреслення, а далі це одна будь-яка буква, потім літера A, а потім нуль або більше будь-яких літер. Так, у Джекі Чана, Джеймса Мартіна і Варда дійсно буковка A строго друга. А давайте передостання А. Там буковка А є, а після неї ще один якийсь символ.
Він обов'язково є. От Джекі Чан підійшов. Лайка вистачає у більшості випадків. Він простий, він досить потужний, він має своє обмеження.
Наприклад, нам не можна перевірити, це точно число чи не число. Чи там може якісь букви є. Для цього лайк не підійде. Але для більшості стандартних порівнянь він підходить.
Зверніть увагу, що лайк так само чутливий до регістру. Тобто там, де міститься А велике і А маленьке, це два різних запити. Бо тут А маленьке шукається, а у нас все чутливе до регістру.
Переважно. Що можна зробити в випадку, коли нам треба, щоб і шукали і великі, і маленькі літери? Тут два варіанти.
Один, який буде працювати у більшості баз даних. Це привести до того, про який ми знаємо. Наприклад, зробити так, щоб гарантовані всі літери у ім'я були великими. АП.
І про функції ми з вами коротко сьогодні ще поговоримо. Приклад, SELECT, AP, T, S, T, O. Все великими літрами. Тепер, якщо тут все великими літрами, і я знаю, в якому регістрі, відповідно, можу порівнювати. Такий варіант буде працювати у більшості популярних СБД. Тому якщо вас цікавить саме переносимість, то це варіант для вас.
Якщо вас цікавить тільки PostgreSQL, то на додачу до такого варіанту є ще I-like. Ця буковка I на початку це ignore case. Тобто неважливо, маленькими-великими літерами я буду шукати ігноруючий регістр. Працює, але виключно в PostgreSQL.
Оці три оператора, Between, Like і In, існують у всіх сучасних СБД, вони йдуть зі стандарту, і з ними все добре, і поведінка майже однакова між різними СБД, з якимись малеткими косметичними відмінностями. На жаль, Like вистачає не завжди, тому різні СБД починають щось з цього. приводу вигадувати той самий postgre каже у мене є декілька варіантів так щоб вам було цікавіше порівнювати postgre sql like see me class у мене тут за панеллю інструментів так стековий флоп Розділ, паттерн matching, тобто порівнювання із зразком не чітке. У Postgre представлений трьома варіантами. Live, який є в стандарті, і на додачу ilive до нього той, який є ignore case.
Трошки similar. Це чисто позгрешний варіант, і він вкрай схожий на те, як працюють символи підстановки у файловій системі. Ми кажемо, я хочу знайти всі файли з розширенням.txt, і пишемо.txt. От similar вкрай на нього петисхожий. По можливостям він трошки потужніший за лайк, але сказати, що б сильно потужний, ну не зовсім.
І наостанок у нас є регулярні вирази, регекспи, де за допомогою якого, ну якщо слона з'їсти не вийде, ну... Заслана, скоріше за все, з'їсти вийде, хіба що хосмічний корабель у космос не запустиш. Регулярні вирази суперпотужні, супервикористовувані. Тому, якщо ви не знайомі ще з регулярними виразами, я рекомендую вам познайомитися з цією темою. Вони реально допомагають вирішити...
величезну кількість питань по пошуку заміні підстановці і так далі. Тому, якщо ви не знайомі з регулярними виразами, я рекомендую для вас нагайно два сайти. Це Regex Crossword, це вивчення регулярних виразів за допомогою в ігровій формі.
Коли ви заповнюєте... кросворд по вертикалі і горизонталі, у якого написані регулярні вирази. Він проводить від таких простих прикладів із туторіала і закінчує страшними махінами, так зараз який-небудь хексагон, де всі регулярні вирази йдуть відразу по кільком напрямкам.
Принаймні рівень Tutorial Beginner я вкрай рекомендую вам пройти. Це ті знання, які за плечима не носити. Те, що дійсно вам в житті знадобиться, неважливо, з чим ви там далі будете працювати, бо вкрай спосуджено.
І другий сайт, який я вам теж вкрай рекомендую, це будь-яка варіація на Reject 101. Я в гуглі ввів regex101, і їх тут декілька дуже однотипних. Сенс у чому? Це сайти, які дозволяють відразу протестувати, чи правильно ви регулярку написали. У мене є декілька варіантів. Мені з цих варіантів треба вибрати тільки ті, які містять виключно числа і точки.
Ну, я там що-небудь напишу. Там будуть цифри і може бути точка. І це має бути від початку рядка до кінця рядка.
Тут, так, мультилайн, мультилайн, стандарт, end of a line. Ага, там чого не вистачає, це, а це, і може бути отак от. О, все нормально, підсвітили. Чим цей Регекс-101, його аналоги, крутить?
Тим, що вони, по-перше, розповідають, що саме ви написали, пояснюючи, що запозначає той чи інший елемент. Підсвічують, що підійшло, що не підійшло. І є повний перелік, що там взагалі в регулярці можна написати.
І більш того, на жаль, регулярні вирази так само, як... і SQL мають багато діалектів, тому ви можете підібрати той, який підійде саме для вашого випадку. В випадку PostgreSQL там постфікс совмістимий, тому перші два частіше за все будуть нормально працювати і повертати саме той результат, який очікувався.
В Rust не пам'ятаю, Java трошки з відмін. Та джавовський теж можна пробувати. Там теж приблизно те саме буде.
Можливостей багато, тому з регулярками це моя рекомендація. Знайдіть собі час для того, щоб вивчити і ознайомитись з цим. Це дійсно в житті вам допоможе. Це не напряму пов'язано з базами даних, але в житті допоможе.
Можете кинути, будь ласка, пряме посилання кудись? Можна в чат сюди? Так.
Чому я пишу Google? Тому що їх там декілька, вони однотипні. Підберіть той, який вам більше подобається. В них і Регі Експрес. Ну є не є так і відповідно наш приклад повертаючись до лайка можна переписати наступним чином опозрізки там дивний оператор тільда і мені треба щоб містила літеру А так Ага, нічого, а тільда зі зіречкою якраз ігнор кейсових варіантів.
О, всіх з літерою А мені повиводило. Операторів різних у PostgreSQL насправді дуже багато, не всі з них доречні, деякі все ж таки позбуваються, але регулярки, ну, от ось таким досить простим способом записуються, це унікальний у порівнянні з іншими субеде-варіантами. І частіше за все для використання регулярних виразів інші СОБД функції використовують на кштатах regex-like, regex-replace чи щось ще.
Але, мабуть, це найбільш часто вживане із того, що взагалі-то у конструкції вебі пишеться. Лайки, бітвіни і незвичайні порівняння регулярки. використовується настільки поодиноко що навіть в туторіалах я його не так часто зустрічаю щоб розповідали там десь застосовували про це обирають люди або більш простий лайк бо він більш швидкий або більш потужні регулярки бо як взяли вже стріляти із пушки так давайте вже потужнішу пушку брати а не щось там мелкокаліберне Так, з тих операторів, які присутні, навіть згадуються у стандарті, хоча не декларуються, як саме мають бути записані, але корисними на практиці є оператор із DistinctFrom.
Дивіться, яка основна проблема. Якщо у нас є намагання... порівняти щось із хто з наскільки, результат такого порівняння завжди буде я не знаю воно може до рівня може не до рівня бо я не знаю скільки це хто знає скільки а довжелезний оператор із distinct from или is not distinct from який більше вам підійде під кокет каже вони різні Да я бачу з одного боку написано нуля з іншого написано хто знає скільки воно по-різному написано тому вони відрізняються Тут з обох боків написано одне й те саме, і там хто знає скільки, і там хто знає скільки.
Ну, тоді вони не відрізняються. Оцей оператор з'явився у стандарті відносно пізно, і тому в масові туторіали по мові SQL він ще до кінця не прибрався. Але коли ви починаєте друмити про порівняння і тут...
може бути порожня, тут не може бути порожня, тут я забув про те, що може бути порожня. Інколи він є корисний. Його можна замінити і іншими варіантами, але як корисна можливість, він присутній і час від часу їм варто користатися.
Ну і нарешті, щоб завершити нашу конверт... роботу із В, треба зрозуміти, що одного порівняння у більшості випадків недостатньо. Нам треба, щоб і людина багато заробляла, і премію не була, і він не був менеджером, і що-небудь ще.
Відповідно, треба порівняти, зробити декілька логічних операцій, які потім між собою об'єднати. І для цього у нас чудово з'являється and, or, and not. Основна проблема з базами даних, що логіка у нас не двоїчна, а троїчна. Окрім істини і лож, у нас є ще хто з наскільки. Хто з наскільки у логічному виконанні визначається як unknown.
Це слово unknown присутнє у стандарті, хоча ніякими способами від null. воно не відрізняється. Що б ми не робили, ми не можемо там зрозуміти, що база даних всередині там тримає now чи unknown, бо одне і те саме.
Логічно воно може десь і відрізняється, але на фізичному рівні ви ніде різниці не знайдете. Так от, давайте звернемо на таблицю істинності для end і ora у випадку нашої тричної логіки. End може повертати всі три результати.
Може повернути true У випадку, як з правої, з лівої стає true. Як обидва апаранди відомі, і один із них false, то у нас буде результат false. Але якщо у нас true або null, то в результаті порівняння у нас теж результат буде хтось нескільки.
Бо end як каже. Мені треба істина, якщо тільки обидві сторони істинні. Тут все нормально, чисто. Якщо одна сторін лож, то 100% лож я одразу і не буду думати. Бо з одної сторони лож результат 100%.
А якщо хоча б з одного боку хтось знає скільки, то і результат буде хтось знає скільки. Який те саме, насправді, що й інший. З ОРОМ трошки простіше. Хоча б з одного боку у нас true, то все буде добре.
Але і повертати вона не завжди true або false. Інколи воно повертає хтось наскільки. У яких випадках, якщо у нас з одного боку точно ні, а з іншого боку хтось наскільки стоїть.
І це інколи впливає на результат операції. Просто треба пам'ятати, що... не двоїста логіка троїста. А ні, з істини робить лож, з ложі робить істину, а хто зна скільки, так і залишається хто зна скільки. Бо я ж не знаю, скільки це хто зна скільки.
Давайте спробуємо. Мені треба люди, у яких немає премії, або премія дорівнює нулю. Псал. І знав.
або премія до рівня 0. Премія, перепрошую, там і там премія. Якщо хоча б одна з сторін цього виразу істина, тобто або там дійсно премія нульова, і там один так одна людинка з нульовою премією є, або премія не встановлена, то подія буде його виводити. Мені треба так, щоб у людини була і зарплата, і премія.
Зарплата більше за нуль, а премія точно була. А теж, до речі, більше за нуль, в кому-му. Все прекрасно працює.
Підводні камені із логічними операціями починаються тільки у той момент, коли ми хочемо поєднати декілька різних логічних операторів в одному виразі. Мені треба так, щоб у людини була зарплата більше 2 тисяч, а премії не було. А премії не було це у нас два варіанти.
Або це нал із нал, або до рівня нулю. Дивимося, запускаємо і отримуємо Тьорнера, який явно не підходить під першу умову. А чому так сталося?
Незважаючи на те, що всі логічні оператори між собою були створені рівними, пріоритет у енда вищий, ніж пріоритет у ора. Для себе, щоб зрозуміти, можна записати як множення і додавання. Оце у нас як множення, а це у нас як додавання. Понятно, що множення відбувається раніше, додавання відбувається пізніше.
І тому, якщо у вас з'являється в одному логічному виразі і енди, і ори, краще розставити дужки. Тоді на 100% всім буде абсолютно зрозуміло, що в якому випадку я порядку виконується. О, наш хто там зник, бо у нього першого вогна не виконувалося. Ну, друга була істина, перша була лож.
але N повертає істину тільки якщо з двох сторін стоїть істина. А от якщо б ми сказали 2500, то ще й більше дать? Ну і перша людинка у нас би там теж з'явилася, Тьомор, з його півтори тисячі.
Тому великі граблі. У операції логічних різний пріоритет. OR як плюс для логічних виконується в останню чергу. And перед останнім, перед ним нот виконується.
Тому на це просто треба пам'ятати, а ще краще, як тільки вони починають змішуватися в одному виразі, то розставити дужки, і тоді ви точно не помилитеся. На слайдах цей самий приклад був у такому вигляді. Мені треба люди, які є сейлсменами або президентами з зарплатою більше за півтори тисячі.
Чи з тим, що дужок ніяких немає, то end виконується раніше, or виконується пізніше. Відповідно, у нас президенти з зарплатою більше за півтори тисячі або сейлсмени, неважливо з якої зарплати. Не подобається, розставили дужки.
буде працювати так само як і хотілося б підкажіть будь ласка логічні операції більш-менш клія або все ж таки треба додаткові якісь коментарі зробити зрозуміло все як завжди Опасайте значення но бо воно якраз може більш за все підгадати так Добре, давайте ми подивимося на наш результат. Тут завінемо на щонебудь більш розумне, наприклад, по імені відсортуємо. Уявимо, що у нас випадете, це є частина певного додатку, і нам треба відобразити результат.
Але якщо результатів на стрінці буде дуже багато, то в нас ця сторінка буде повільно завантажуватись а інколи ми знаємо що результатів 100% буде багато і в інтернет магазинах у нас по сторінкам розбивається перші 50 товарів потім ще 50 товарів потім ще 50 товарів бо точно знаємо що список довгий і багато хто далі першої сторінки не йде тому виникає про це задача вивезти не все але це не все про те, що мені фіксована кількість рядків треба. І отут повний конфлікт із реляційною теорією. Реляційна теорія каже, стривай, у тебе ж всі елементи множини між собою однакові.
Як ти можеш сказати, виведи мені половину множини? Та ні, я забудь. А бізнес каже, я не хочу ганяти всі дані по мережі, мені треба тільки перших 10 рядків, а потім ще підгружу 10 рядків, а потім ще підгружу 10 рядків. І тому щонебудь у цьому напрямку було стандартизовано відносно пізно.
Якщо перші стандарти з Кріль це 1987 рік, 1992 рік повноцінний вже стандарти з Кріль. скрилі в тому вигляді, як ми його знаємо, то щонебудь про те, що мені перших 10 рядків треба, з'явилися аж в стандарті скрилі 2008. А до цього всі популярні СУБД вже існували. І тому вони вигадували щось своє.
Найбільш дивнувате, як так сказав би, по іншого слова, у мене немає на цей Вигадали Microsoft. Вони запропонували після селекта писати слово топ і скільки вам рядків треба. Я тут неправильно написав якусь колонку. І начебто воно і починається логічно.
Ми скажемо скільки ми будемо рядити. Ми фіксуємо розмір результат, де будуть накопичуватися наші дані. І як тільки воно доходить до необхідного розміру, ми просто припиняємо виконання нашого запиту.
Виглядає логічно. Але ж у нас є ордербай, який розповідає, в якому порядку. І в результаті в MySQL порядок from, далі в, далі частинка select.
та яка розповідає які самі у нас колонки будуть після цього ордер бай після цього скільки рядків тобі треба і перший рядок виконується нібито половина в один момент половина в інший момент ну таке ораклавці сказали стривайте у вас що обмеження де обмеження пишемо обмеження пишемо колодзь ООВ. Давай-ка ми тобі створимо змінну, яка буде сказати, скільки у тебе значень у результат-сеті вже накопичилось. Тобто в тому, що ти збираєшся користувачу відіслати.
Навіть не так. На який рядок результат-сета ти будеш писати результат, який ти збираєшся зараз записати. Тобто для першого рядку, який я хочу...
відправити користувачу, нам буде містити саме одиничку. Записали одинички, перший рядочок заповнений, тепер другий, третій, четвертий, п'ятий. І тут, в принципі, зрозуміло, як мені логічно, все вв, обмежується, супер.
Проблема з цим варіантом, знов-таки, з ордербай. Бай і що там? по якийсь колонці бо тепер ордер бай до чого працює фром віддає в конструкці скільки чи треба пропускати цей рядок після цього передає в селект і в результат дописує необхідне значення а потім результат сортується так а що ми сортуємо те що накопичили відповідно якщо ми сказали дай мені перших 10 рядків то відсортуємо ці 10 рядків і все.
Найбільш логічним, як на мене, варіантом, який був у спроб проміжних. Був той, який запропонований і вони часто зустрічаються і це і SQLite, і MySQL, і PostgreSQL, які додали конструкцію ліміт. По порядку вона йде після ордербайя.
Ось тут ще ордербай має бути. Тоді ми читаємо рядок. вирішуємо, чи потрібен нам він чи ні, відправляємо у ResultSet, OrderByResultSet сортує в тому порядку, який потрібно, і лімітом ми кажемо, скільки з тих рядків, які є, ми будемо віддавати клієнту, а всі інші просто у себе залишимо.
Тому воно принаймні хоч рознесено по різним реченням і виглядає найбільш логічно. І з лімітом насправді найбільша кількість туторіалів і в інтернеті зустрічаються. Хоча він не входить у стандарт. А от хлопці, які пишуть стандарт SQL, нарешті розродилися, що така конструкція, яка повертає тільки верхніх N запитів, тільки в стандарті SQL 2008. І те, що вони вигадали, зараз підтримується більшістю сучасних баз даних. А вони замість того ліміта вигадали більш довгу конструкцію fetch-first з кількістю rows-only.
З невеличкими варіантами, що можна row, а можна rows писати, що там можна сказати не перших, а наступних після якогось рядку. Але в стандарті є саме цей варіант. Він зараз підтримується більшістю СБД. Хоча виглядає монструозно. Через свою монструозність в більшості навчальних підручників зустрічається варіант ліміт, хоча він в стандарт не входить.
Ось така дивна чахарда. І так, давайте з нашим варіантом. Ми можемо написати у хозгре, дай мені будь ласка перш п'ять людей.
Коротка, проста і читабельна. Або те саме, але сумісне з стандартом. Fetch first five rows only. Результат, як бачите, однаковий. Всередині результат теж однаковий.
Між першим і другим варіантом різниці ніякого й нема. Питання тільки наскільки ви дбаєте про сумісність. Тому не принципово. З цим підкажіть, будь ласка, чи є питання, чи ні.
Чи можемо рушати далі? Давайте далі. Супер.
Наступне. У нас Select 5 поділити на 2. Скільки буде? два з половиною не вгадали бо 5 ціле число і два ціле число і такий результат не всім подобається а комусь хочеться дійсно що було два з половиною це про те що а так у нас поділити взагалі не вийде а ну вийде нормально ставилися нормально ось так не вийде як з двох сторін стоять о Такого оператора немає.
А інколи так хочеться. Так ось з цього приводу є в СУБД явне і неявне приведення типів. Неявне приведення типів працювало, поки база даних могла розібратися, що тут відбувається.
Оператор ділення, з одного боку число. Значить, мабуть, з іншого має бути число, як там не число буде, я видам помилку. Я спробував перевести 5D в число, не вийшло, я помилку видам. І переважно ви будете писати, і у вас все буде спрацьовувати. Наприклад, мені всі люди, крім ЄМК, які були прийняті на роботу після 2012 року.
В... Аааа... Як там воно?
Ааа... Hard Date? Більше за 2013-01-01. Так, немає? А, 13 я просив.
Але ж з цього боку у нас було число, а з цього було дата. А ні, все нормально, спрацювало, база даних зрозуміла, приведення типів відбулося, пішли далі скакати. Але якщо ми хочемо бути абсолютно впевнені, або...
база даних не може розібратися, що тут взагалі відбувається. В нашому прикладі, коли ми рядок 5 ділили на рядок 2. Або якщо у нас функція є, у якій є аргументи з різними типами, і в залежності від цього різні функції треба запускати, інколи явно треба зробити приведення типів. При цьому існує два способи, які внесені в стандарт. Це верхній. Я кастую якесь значення в якийсь конкретний тип.
І існує варіант ось такий в стандарті. Коли ми кастуємо до якогось типу обов'язково рядок. Тобто права частина тут завжди рядочок.
Оці два варіанти є в стандарті. PostgreSQL додає ще один світ, який він використовує всередині, і тому на більшості скріншотів, які пояснюють, що там всередині відбулося, буде саме він. Він більш простий по запису у порівнянні з іншими, тому частіше за все у прикладах використовується.
Дві двокрапки. Все якраз приведення до якогось типу. І в нашому випадку ми могли сказати, Я хочу, щоб дата була в даному випадку не як дата, а як варчар, як рядочок.
Отак порівнювати. Або навпаки явно сказати, та ні, у мене з правого краю стоїть не рядочок, а у мене стоїть дата. Або в нашому прикладі з рядками 2 спів. з половиною на 5, ми могли сказати select, 5 поділити на 2, але ж і тут стоїть ціле число, і з цього стоїть cast. Відверто кажучи, незважаючи на переносимість, Мені варіант з двома двокрапками трошки більше приваблює.
Він простий, його легко записати. Якщо вам дійсно хочеться у цьому випадку отримувати 2,5, приведіть щось до дробного типу, і далі у вас все працюватиме, як і очікувалося отримувати 2,5. А крім цього є ще...
приведення типів за допомогою функцій to chart, to date і так далі, але з ними зберетесь більше на практиці, коли будете вивчати функцію одного рядка. Підкажіть, будь ласка, з цим слайдом зрозуміло, не зрозуміло, як? Зрозуміло.
Ну і нарешті. У нас декілька разів вже сьогодні вони зустрічалися, тому чому б ні, давайте і продовжимо. У нас якраз 12 хвилин до кінця лекції завершилися.
Ми хотіли зробити лайк нечутливим до регістру, і ми сказали, а давай-ка ми ім'я нашого користувача приведемо до верхнього регістра. там якийсь рядок і воно спрацювало і це в принципі для нас абсолютно нормально ми з інших мов програмування знаємо що таке функція про те що у функції може бути декілька аргументів для нас це абсолютно звична концепція те що для нас абсолютно звична концепція в SQL і в реляційних базах даних називається single row function Це обозначає, що ми тут беремо результат і відразу ж його повертаємо. Ні кудись не поєднуємо разом, не шукаємо скрізь різних даних і так далі. Тут взяли, тут обробили, тут і повернули.
В рамках одного рядка. Single row function. Один рядок на вхід, один рядок, одне значення на вихід. В PostgreSQL дуже багато вбудованих функцій.
Вони різні. Вони корисні, їх знайдеться на будь-який випадок життя. Тому абсолютно всі передивляться чи навіть пробувати, сенсу якось немає. Ви завжди можете відкрити, як буду працювати із рядками.
Тоді пост гре SQL String Function. І ось, функція по роботі з рядками. і функції по роботи з рядками версію вибираємо 16 поточну і бачимо що тут і не стільки довжелезний список що саме числа те саме дати і так далі їх достатньо але на деякі все ж таки варто звернути увагу перша група це фундівці які дозволяють знову таки перевернути перевести один тип інший Давайте спробуємо зробити щонебудь ось так от мені треба щоб дата було в форматі 13 01 01 бо так Україні прийнята спрацювала а тут у мене не спрацює мені хочеться щоб у мене рік був, а потім був день, а потім місяць. І насправді з цим неправильним порядком дня і місяця інколи виникають проблеми. Наприклад, у американців і британців якраз порядок, де місяць, а де день, у даті різний.
І от на цей випадок, коли ми знаємо, в якому саме форматі представлена дата, і ми хочемо... перевести, якраз нам до допомоги приходять функції, які займаються Typecasting. Це To Chart, To Date, To Number, To Time Stump. У нас там завжди перше звідки ми будемо переводити, а далі патерн, який розповідає, де там що шукати.
Наприклад, в нашому випадку, коли дата була десь у тестових даних і саме у такому форматі представлена, ми можемо сказати У мене в форматі рік-рік-рік, після цього день-день, після цього місяць-місяць. Так, спрацювало, давайте перевіримо, спрацювало чи не спрацювало, бо щось у мене. День, місяць, тринадцятий. Там трошки раніше був найнятий.
Давайте дванадцятий рік поставимо, щоб точно хоч когось вибрало. Там був у тринадцятому році найнятий, але він був дванадцятого числа найнятий, тому його і не вибрало. Зверніть увагу, будь ласка, в вашому init-скрипті, який створює таблички в другій лабораторній роботі, використана саме функція toDate.
Тому що я не знаю, які саме локальні ваші стандарти встановлені саме на вашому комп'ютері. Це налаштовується в Windows, в регіональні стандарти, якась така налаштування, як представляти дати, як парсити дати і так далі. Там є, і це відрізняється від комп'ютера до комп'ютера. Ці функції to date, to number, ту чарту, штамп і так далі, дозволяють зробити перенесення таких даних абсолютно нечасто.
Кули не пробивним. Ви самі відформатували, ви знаєте дещо, і ви можете його розпарсити фактично. Тому зверніть, будь ласка, увагу на цю функцію. На ці функції.
Шаблони для них і символи, які там можна для підстановки, вони в документації є, вони... якраз дуже схожі між різними СУБД, тому один раз подивилися, і далі вам буде легко адаптуватися. Так, з рядками. На що варто звернути увагу?
Конкатіна це функція конкат. Пам'ятаєте, там хитра поведінка, якщо один із аргументів науки працює. Приведення до верхнього-нижнього регістру. Ну і довжина рядка.
Мабуть, це те, що найчастіше за все використовується. У нас там ще буде вирізання підрядочка. Заміна символів одним іншим, пошук рядка у підрядку.
Це те, що, принаймні, під руками частенько використовується. В лабораторці буде зустрічатися ще функція LPAD-RPAD. Це добивання до потрібної ширини справа чи зліва пробілими.
У мене видалено в табличці 5 символів, а прийшов тільки один. Мені хочеться, щоб... повністю заповненим було, з якого сторони заповнювати і чим.
Це якраз LPAD, RPAD. Із цими функціями є найгірше, що я зустрічав у PostgreSQL, за що можна його тихесенько ненавидіти. Але у порівнянні з тими потужними можливостями, які є, це дріб'язок. З якогось неймовірного дива розробники подбрайс-квєй вирішили, що деякі функції варто, щоб були більш легкими для читання, і напихали всередину них англійських слів. Не так, як ми звикли, споставили кому і кому ми розділили аргументи, а прямо напихали всередину англійських слів.
Пазище це… позиція під строки в рядку на що вони туди інваткнули не знаю і от про ці слова які чомусь там виникли сабстрінг підрядок з до якого символу навіщо вони туди фром і пол їх не запам'ятаєш от Як не запам'ятаєш, так біжиш в документацію, швиденько у пам'яті відновлюєш, використав, побіг далі. Або вам ідеєш, вам СКІ-клієнт підказав, що там за аргументи треба написати. Незручно, але до цього можна звикнути, тим більше, що для найбільш розповсюджених функцій якраз є обидва варіанти.
І з оцими... словами незрозумілими які чомусь там посеред функції виникли і з комами тому згладжується і так щоб починає вругатися а на що вони туди відкликнули виникає не так часто Ну просто відверто кажучи не так часто і треба щось таке не сильно розповсюджено використати на додачу до функцій як наприклад є чудова функція рогет сплайк яку притягнули із оракла колись у якийсь прекрасний момент розробники подрайскіль додали можливість створювати свої оператори і з тих пір їх стало Інколи це зручно, як в RegExpli, в якому ми можемо написати тільда і зірочка, і всі тільда і зірочка і пишуть в більшості випадків, а не довжелезна назва. Але і всілякого іншого там теж понакопичувалося.
І є функція «дай мені абсолютне значення», тобто замість «мінус один одиничка», «мінус два двійка» і так далі. А можна написати з оператором «add». Можна асоціаторне відділення знайти за допомогою функції mod, а можна за допомогою оператора відсоток.
З коренем квадратним взагалі такий дивнуватий оператор. Вони є, але якщо ви їх не використовуєте, то не використовуйте далі. Бо сама функція своїм ім'ям більш промовисто пояснює, що відбувається. Тому чому б ні. На ваш вибір.
Операторів різних постгре достатньо. Для різних типів даних вони перегружені. Потім з JSON розбиратись і з усім іншим. І зовсім фінальна на сьогодні функція, без якої у вас навряд чи обійдеться.
Ну, третина запитів у останніх якихось лабораторних роботах. У нас є значення null, яке позначає, хто з нас скільки. І коли ми придумуємо про його існування, нам завжди треба написати якийсь страшний умови, який враховує, там може бути хороше значення, а може бути значення null.
І щоб кожного разу не писати і не ламати собі голову, ми можемо... просто замінити нау на щось хороше. Давайте спробуємо так.
Мені треба люди, яка у них премія і чудова функція коліс, яка приймає перше, та скільки завгодно аргументів йде по цьому переліку до першого непустого. Подивись, будь ласка, на премію. Як вона є? Молодець її виводить.
Я, як її немає, я знаю, як премія не встановлена, то вона дорівнює нулю. І всі наші запити, які там морочилися з інеєм, чи можна до зарплати премію додати, стали на порядок легшими. Бо ми тепер знаємо, не було премії, я спокійно її заміню на нулю і піду з цим далі. І тому тут зарплата.
Плюс премія буде, як ПВЗ, а тут зарплата плюс, як не було премії, заміни на нуль. Якщо ви звернули увагу на підказку, яку видавав нам Датагрід, поки ми Коаліз писали, він підказував, що в Коалізі може бути скільки завгодно аргументів. Йдемо по списку до першого непорожнього.
Всі порожні, це нормально. Іначе всі порожні, нічого страшного, буде NAL це теж хороше значення. Тому коалізм стає вашим незамінним другом.
Знаємо, що в колонці може бути значення NAL, то або за допомогою із NAL і з NOT NAL його обробляємо, або коалізм заміняємо на щось, що більше підійде. Зверніть на нього увагу, він в лабораторній роботі по функціям одного рядка буде з'являтися достатньо часто. Не сьогодні з цим достатньо. Наступного разу ми з вами поговоримо про двох монстрів, яких звуть кейс, і перейдемо до підзапитів.
Вже будемо занурюватися все глибше і глибше внутрішній сквілі. Якщо у вас зараз є питання, я з радістю на них відповім. Як ні, до практики, до лекцій.