У меня в 1995-ом был pentium 100, 16mb ram, 1gb hdd, sb 16, видеокарта s3 trio64, монитор 15 дюймов, тянул 1024х768. Стоило это в районе 1200 баксов. Когда пошли игры, поддерживающие ускорители, докупил 3dfx, процы менял 100->120->133->166, дальше не помню. Круто было, в общем.
Ваше "определение" не имеет никакого отношения к определению. Мне просто уже было лень рассказывать вам про декартово произведение, раз уж вы стали к нему придираться.
И весь стандарт читать не надо, одну страницу от силы.
В стандарте все описано. Не считаю нужным перепечатывать его тут. Ссылка была дана выше.
Я говорю о том, помогают ли теоретические определения быстрее или правильнее писать SQL-запросы. Потому что это был ваш изначальный тезис. Нет, не помогают.
Ещё как помогают, и ваше определение джоинов и есть этот наглядный пример.
Короче, стандарт не читал и другим не советую. Определение join-ов не знаю, пишу по наитию, главное, что у меня в моей субд работает.
Не говоря уже о том, что никакая база не генерирует сначала все возможные комбинации, потому что места на диске не хватит, а именно присоединяет строки к изначально пустому множеству.
Вы не знаете, что SQL это декларативный язык. Я вам про то, что мы получаем, а вы про то, как мы это получаем.
А вы добавили две непонятные сущности "декартово произведение" и "фильтрация". Что дальше?
У декартова произведения есть определение, в отличие от некоего присоединения. Я попробовал поискать в гугле по фразе "присоединение строк в базах данных" и жестоко обломался.
Фильтрация - ок, сделаем вид, что это непонятно. Тогда словами стандарта - подмножество декартова произведения двух таблиц, удовлетворяющее <join condition>.
Определение из стандарта самое простое и самое понятное. У него не может быть двух трактований или каких-то белых пятен. Ваше определение составлено вами для вас, используя вам понятный набор терминов. Лично для меня оно неочевидное и допускает разные трактования, что недопустимо. А все из-за того, что вы не желаете читать стандарты и изучать теоретические основы и побуждаете других поступать так же!
Если знает, как работает конструкция BLABLABLA JOIN в конкретной базе данных.
JOIN-ы работают везде одинаково, согласно стандарту. Если СУБД не соответствует стандарту, то фактически это не SQL, а какая-то его разновидность.
Очень просто. "Пишешь LEFT JOIN, и к каждой строке таблицы присоединяются все строки из другой таблицы, которые соответствуют условию. Так как в результате таблица, а не дерево объектов, то строка первой таблицы дублируется. INNER JOIN это то же самое, только строки из первой игнорируются, если нет строк во второй".
Вместо путанного определения, добавившего две непонятные сущности - "присоединяются" и "дублируются", в стандарте 92-ого года (взято для примера) inner join двух таблиц определяется как их декартово произведение с дальнейшей фильтрацией по условию. left join - это inner join union all строки из левой таблицы, не попавшие в результат inner join-а. Остальные join-ы выводятся аналогично и очень просто. См. 7.5 <joined table> в стандарте.
Я искренне уверен, что для профессионального написания SQL запросов человек должен уметь читать стандарт и понимать, как это работает не на пальцах и непонятных определениях неизвестно откуда, а согласно первоисточнику.
Тот, кто забивает на основы, каждый раз будет удивляться тому, что разъезжаются данные при джоинах. База запросов - это джоины. Как можно понимать джоины без знания декартово произведения??
Если вы скажете, что вы эксперт SQL и не знаете, что такое декартово произведение, то вы либо обманываете окружающих, либо обманываете себя.
SQL невозможно выучить ни за неделю, ни за месяц, ни за год. Начинать надо с теоретических основ реляционных БД - кортежи, декартовы произведения, нормальные формы и тд, иначе запросы будут писаться наугад и работать на одних данных и выдавать лажу на других.
Если вы в Шенгене, то вы можете ехать в Польшу как хотите и никто вам ничего не скажет. Все выкрутасы поляков относятся к прилёту/приезду в Польшу из стран за границами Шенгена.
На графике отчётливо видно детскую смертность, которая еще в середине 19 века выкашивала треть.
Люди научились бороться с основными причинами детской смертности - малярией, младенческой смертностью и пневмонией - как раз начиная с середины 18 века. Хинин, гигиена в родильных отделениях и антибиотики снизили детскую смертность в развитых странах буквально на порядки.
У меня в 1995-ом был pentium 100, 16mb ram, 1gb hdd, sb 16, видеокарта s3 trio64, монитор 15 дюймов, тянул 1024х768. Стоило это в районе 1200 баксов. Когда пошли игры, поддерживающие ускорители, докупил 3dfx, процы менял 100->120->133->166, дальше не помню. Круто было, в общем.
Ваше "определение" не имеет никакого отношения к определению. Мне просто уже было лень рассказывать вам про декартово произведение, раз уж вы стали к нему придираться.
И весь стандарт читать не надо, одну страницу от силы.
В стандарте все описано. Не считаю нужным перепечатывать его тут. Ссылка была дана выше.
Ещё как помогают, и ваше определение джоинов и есть этот наглядный пример.
Короче, стандарт не читал и другим не советую. Определение join-ов не знаю, пишу по наитию, главное, что у меня в моей субд работает.
Вы не знаете, что SQL это декларативный язык. Я вам про то, что мы получаем, а вы про то, как мы это получаем.
У декартова произведения есть определение, в отличие от некоего присоединения. Я попробовал поискать в гугле по фразе "присоединение строк в базах данных" и жестоко обломался.
Фильтрация - ок, сделаем вид, что это непонятно. Тогда словами стандарта - подмножество декартова произведения двух таблиц, удовлетворяющее <join condition>.
Определение из стандарта самое простое и самое понятное. У него не может быть двух трактований или каких-то белых пятен. Ваше определение составлено вами для вас, используя вам понятный набор терминов. Лично для меня оно неочевидное и допускает разные трактования, что недопустимо. А все из-за того, что вы не желаете читать стандарты и изучать теоретические основы и побуждаете других поступать так же!
JOIN-ы работают везде одинаково, согласно стандарту. Если СУБД не соответствует стандарту, то фактически это не SQL, а какая-то его разновидность.
Вместо путанного определения, добавившего две непонятные сущности - "присоединяются" и "дублируются", в стандарте 92-ого года (взято для примера) inner join двух таблиц определяется как их декартово произведение с дальнейшей фильтрацией по условию. left join - это inner join union all строки из левой таблицы, не попавшие в результат inner join-а. Остальные join-ы выводятся аналогично и очень просто. См. 7.5 <joined table> в стандарте.
Стандарт SQL 1992: https://www.contrib.andrew.cmu.edu/~shadow/sql/sql1992.txt
Я искренне уверен, что для профессионального написания SQL запросов человек должен уметь читать стандарт и понимать, как это работает не на пальцах и непонятных определениях неизвестно откуда, а согласно первоисточнику.
Тот, кто забивает на основы, каждый раз будет удивляться тому, что разъезжаются данные при джоинах. База запросов - это джоины. Как можно понимать джоины без знания декартово произведения??
Если вы скажете, что вы эксперт SQL и не знаете, что такое декартово произведение, то вы либо обманываете окружающих, либо обманываете себя.
SQL невозможно выучить ни за неделю, ни за месяц, ни за год. Начинать надо с теоретических основ реляционных БД - кортежи, декартовы произведения, нормальные формы и тд, иначе запросы будут писаться наугад и работать на одних данных и выдавать лажу на других.
Я помню, когда ya.ru был только строкой поиска и кнопкой. По-моему, можно было на этом остановиться.
Пишут, что эту регистрацию практически невозможно пройти, по сути это белый список блоггеров.
Зачем байты в инт пихать? char (ну или что там ещё, uint8_t или что-то подобное) логичнее, меньше места жрет и & 0xFF не нужен.
Это ж Гора из Игры Престолов
А почему раз в секунду, а не раз в планковское время?
В постгресе можно подкрутить настройки памяти (work_mem), и вместо адского торможения на диске, запрос будет летать в памяти.
Мне кажется, что вселенная не доживет до этого.
Думаю где-то сидят Уиттен и Сасскинд и плачут друг у друга на плече.
В химии тоже далеко не химикам дали. Видать, нобелевский комитет решил, что 2024 - год AI. Осталось ещё по литературе дать премию ChatGPT
День опричника. Сильнейшая вещь. Сорокин описывал возможную реальность, но кто-то использовал его как инструкцию по применению.
Когда я его прочел в том далёком 2006-ом году, я понял, что мы именно туда и катимся и что надо валить.
Если вы в Шенгене, то вы можете ехать в Польшу как хотите и никто вам ничего не скажет. Все выкрутасы поляков относятся к прилёту/приезду в Польшу из стран за границами Шенгена.
Шесть лет до 30 лет осталось, полет нормальный.
На графике отчётливо видно детскую смертность, которая еще в середине 19 века выкашивала треть.
Люди научились бороться с основными причинами детской смертности - малярией, младенческой смертностью и пневмонией - как раз начиная с середины 18 века. Хинин, гигиена в родильных отделениях и антибиотики снизили детскую смертность в развитых странах буквально на порядки.