У меня в 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 невозможно выучить ни за неделю, ни за месяц, ни за год. Начинать надо с теоретических основ реляционных БД - кортежи, декартовы произведения, нормальные формы и тд, иначе запросы будут писаться наугад и работать на одних данных и выдавать лажу на других.
Господа, господа, вы упускаете одно решение (с) Рик и Морти
Задача про варенье, без оконных функций и т.д.
Осталось еще вспомнить всякие убогие *=, =*, (+)
Покупать кофе в старбаксе за четыре евро мне западло - оно того не стоит, а вот сгонять на октоберфест с сыном за штуку - только в путь!
Не очень понял, что вы имели ввиду. Я про
например
А ещё join-ы умеют объединяться вместе с помощью круглых скобочек.
У меня в 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), и вместо адского торможения на диске, запрос будет летать в памяти.
Мне кажется, что вселенная не доживет до этого.
Думаю где-то сидят Уиттен и Сасскинд и плачут друг у друга на плече.