Я знаю что такое транзакции

Ну серьезно, такого вопроса бы не возникало. В момент выполнения запроса ты работаешь со слепком данных.

А оно точно прям нужно? Или ты так привык что по другому не умеешь думать?

Нужно или нет другой вопрос. Но на объем кода это точно влияет

@etkee давай в личку

я не могу tcpdump, от слова совсем

дык научись

давай не

спаму много )

Нужно или нет другой вопрос. Но на объем кода это точно влияет

Это все тот же вопрос на самом деле.

спаму много )

Давай всех перебаним. И оставим в группе только тебя одного. Будешь наслаждаться отсутствием спама

Ок, но как это к задаче вычисления суммы относится?

Так, что это, вообще говоря, может зависеть от реализации и уровня изоляции... хотя настолько "весёлую" СУБД надо ещё найти. ;) Короче говоря, например, на READ COMMITTED стандарт не запрещает, чтобы: SELECT (SELECT SUM(x) FROM a WHERE k) AS x1, (SELECT SUM(x) FROM a WHERE k) AS x2. Получалось, что x1 <> x2.

Так, что это, вообще говоря, может зависеть от реализации и уровня изоляции... хотя настолько "весёлую" СУБД надо ещё найти. ;) Короче говоря, например, на READ COMMITTED стандарт не запрещает, чтобы: SELECT (SELECT SUM(x) FROM a WHERE k) AS x1, (SELECT SUM(x) FROM a WHERE k) AS x2. Получалось, что x1 <> x2.

Не зависит. Ты ошибаешься

Не зависит. Ты ошибаешься

No you. С чего бы это?

ну вот тут получается 3 запроса с вложенными, SUM(x) - всегда будет одинакова во всех трёх запросах?

Так, что это, вообще говоря, может зависеть от реализации и уровня изоляции... хотя настолько "весёлую" СУБД надо ещё найти. ;) Короче говоря, например, на READ COMMITTED стандарт не запрещает, чтобы: SELECT (SELECT SUM(x) FROM a WHERE k) AS x1, (SELECT SUM(x) FROM a WHERE k) AS x2. Получалось, что x1 <> x2.

я про это

то есть слепок базы будет один?

С того бы что вычисление агрегатов и прочих выражений в списке вывода не зависит от предикатов, определяющих критерии отбора записей таблицы для обработки.

ну вот тут получается 3 запроса с вложенными, SUM(x) - всегда будет одинакова во всех трёх запросах?

Про MySQL Вам уже ответили — там всё будет хорошо. Это я про теоретическую возможность (можно и на практике на "классическом" блокировочнике продемонстрировать... но к MySQL это всё не относится). > то есть слепок базы будет один? Это неважно. Важно то, что этой проблемы в MySQL нет.

и кстати MVCC в mysql применима не для всех случаев! а для Maria, InnoDB, Falcon, XtraDB, если верить вики

С того бы что вычисление агрегатов и прочих выражений в списке вывода не зависит от предикатов, определяющих критерии отбора записей таблицы для обработки.

Вы мой пример видели? Какой-то engine не обязан считать (SELECT SUM(x) FROM a WHERE k) один раз.

я к этому и веду, что вычисление, к примеру небольшого объема - не принципиален, но если бигдата , то сумму считать 10 раз накладно

Вы мой пример видели? Какой-то engine не обязан считать (SELECT SUM(x) FROM a WHERE k) один раз.

Не видел

Не видел

Короче говоря, например, на READ COMMITTED стандарт не запрещает, чтобы: SELECT (SELECT SUM(x) FROM a WHERE k) AS x1, (SELECT SUM(x) FROM a WHERE k) AS x2. Получалось, что x1 <> x2.

Coздaли ЗакрытоеСообщество?? для свoих. Первые 100 мecт бeсплaтно

Короче говоря, например, на READ COMMITTED стандарт не запрещает, чтобы: SELECT (SELECT SUM(x) FROM a WHERE k) AS x1, (SELECT SUM(x) FROM a WHERE k) AS x2. Получалось, что x1 <> x2.

Никакая СУБД тебе не будет 20 раз считать один и тот же подзапрос ...

я к этому и веду, что вычисление, к примеру небольшого объема - не принципиален, но если бигдата , то сумму считать 10 раз накладно

Ну это Вам MySQL-щики скорее подскажут, вычисляет он или нет... но я надеюсь, что он не настолько тупой.

Coздaли ЗакрытоеСообщество?? для свoих. Первые 100 мecт бeсплaтно

Алекс блин дай мне банхарер я его покараю!

Никакая СУБД тебе не будет 20 раз считать один и тот же подзапрос ...

Он не один и тот же. Это два одинаковых. И много какие СУБД честно будут их считать отдельно.

Один и тот же

Он не один и тот же. Это два одинаковых. И много какие СУБД честно будут их считать отдельно.

Пример давай таких. Чтобы их сразу в утиль списать.

в общем никто не знает будет ли он сумму считать N раз или будет помнить результат первой суммы и юзать его...(

Пример давай таких. Чтобы их сразу в утиль списать.

> Один и тот же Нет. > Пример давай таких. Чтобы их сразу в утиль списать. Ну начинайте списывать: MS SQL, PostgreSQL... кто дополнит? ;)

в общем никто не знает будет ли он сумму считать N раз или будет помнить результат первой суммы и юзать его...(

Я знаю. Будет помнить. Не будет считать.

> Один и тот же Нет. > Пример давай таких. Чтобы их сразу в утиль списать. Ну начинайте списывать: MS SQL, PostgreSQL... кто дополнит? ;)

Ни в одной из вышеперечисленных не будет такого

Ни в одной из вышеперечисленных не будет такого

Ещё раз посмотрите на мой пример. Внимательно. Вам планы показать?

Я знаю. Будет помнить. Не будет считать.

Спасибо, буду проверять

в общем никто не знает будет ли он сумму считать N раз или будет помнить результат первой суммы и юзать его...(

На всякий случай все же дай мне для контроля запрос, чтобы я точно мог сказать

Ещё раз посмотрите на мой пример. Внимательно. Вам планы показать?

Аппни пример пожалуйста

На всякий случай все же дай мне для контроля запрос, чтобы я точно мог сказать

Да вот же он! SELECT (SELECT SUM(x) FROM a WHERE k) AS x1, (SELECT SUM(x) FROM a WHERE k) AS x2. Я утверждаю, что эти СУБД выполнят вычисление x1 и x2 отдельно. Т.е. (SELECT SUM(x) FROM a WHERE k) будет вычислено два раза.

ты путаешь мягкое с теплым

На всякий случай все же дай мне для контроля запрос, чтобы я точно мог сказать

SELECT SUM(visit_amount) AS raws, COUNT(visit_amount) AS uniques, COUNT(visit_amount)/SUM(visit_amount) AS prod

я к этому и веду, что вычисление, к примеру небольшого объема - не принципиален, но если бигдата , то сумму считать 10 раз накладно

Потому данные нужно организовать правильно и сразу. Без разницы биг дата или не биг.

Потому данные нужно организовать правильно и сразу. Без разницы биг дата или не биг.

ага то есть частное писать ещё с плавающей точкой))

ты путаешь мягкое с теплым

Он пытается заместо правильно организованых данных изобрести серебряную пулю для говнокодеров

ага то есть частное писать ещё с плавающей точкой))

Да хоть с летающей точкой или точкой роющей тоннели. Нужно организовывать хранение данных в соответствии с потребностями. А не валить все в кучу в надежде что потом разберем

Тут ты не прав

Да вот же он! SELECT (SELECT SUM(x) FROM a WHERE k) AS x1, (SELECT SUM(x) FROM a WHERE k) AS x2. Я утверждаю, что эти СУБД выполнят вычисление x1 и x2 отдельно. Т.е. (SELECT SUM(x) FROM a WHERE k) будет вычислено два раза.

Нет. Это общее место (одно из) в опримизаторах СУБД, называется либо сабквери кэш либо просто оптимизация выражений. Любое выражение, указанное хоть 200 раз, будет реально считаться только один раз. Любой разраб СУБД про это знает.

SELECT SUM(visit_amount) AS raws, COUNT(visit_amount) AS uniques, COUNT(visit_amount)/SUM(visit_amount) AS prod

Вот зачем Вы влезли... ;) Это же совершенно другой запрос.

Нет. Это общее место (одно из) в опримизаторах СУБД, называется либо сабквери кэш либо просто оптимизация выражений. Любое выражение, указанное хоть 200 раз, будет реально считаться только один раз. Любой разраб СУБД про это знает.

Вы неправы. Сами посмотрите планы или показать?

Да вот же он! SELECT (SELECT SUM(x) FROM a WHERE k) AS x1, (SELECT SUM(x) FROM a WHERE k) AS x2. Я утверждаю, что эти СУБД выполнят вычисление x1 и x2 отдельно. Т.е. (SELECT SUM(x) FROM a WHERE k) будет вычислено два раза.

вот эта херня в мускуле будет посчитана дважды, увы, но посчитана она будет одинаково

SELECT SUM(visit_amount) AS raws, COUNT(visit_amount) AS uniques, COUNT(visit_amount)/SUM(visit_amount) AS prod

Да, тут SUM и COUNT будут считаться по одному разу. Потом вычислится производное выражение SUM/COUNT()

Вот зачем Вы влезли... ;) Это же совершенно другой запрос.

Ну я ж попросил его, вот он и дал.

Да, тут SUM и COUNT будут считаться по одному разу. Потом вычислится производное выражение SUM/COUNT()

Я приводил Вам не этот пример! В четвёртый раз показать?

Вы неправы. Сами посмотрите планы или показать?

Покажи

Тут ты не прав

Эт в чем же я не прав? Даже на свалке мусор сортируют. Так с какого перепуга данные нужно тупо сваливать в кучу и потом пытаться их перебирать изобретая оптимизаторы?

Вы неправы. Сами посмотрите планы или показать?

Главное, план тебе будет тем ещё доказательством, что это вычисляется один раз, или несколько.

вот эта херня в мускуле будет посчитана дважды, увы, но посчитана она будет одинаково

В MySQL-е — да. Но, как я уже писал, это не обязательно (я писал, когда).

В смысле по плану ты это не поймёшь.

В смысле по плану ты это не поймёшь.

а вот по профайлу можно

Покажи

Да вот же он! SELECT (SELECT SUM(x) FROM a WHERE k) AS x1, (SELECT SUM(x) FROM a WHERE k) AS x2. Я утверждаю, что эти СУБД выполнят вычисление x1 и x2 отдельно. Т.е. (SELECT SUM(x) FROM a WHERE k) будет вычислено два раза.

Я приводил Вам не этот пример! В четвёртый раз показать?

Я просил этого лисёнка дать мне его конкретный запрос. ОН дал. Это не относится к поддиалогу с тобой.

В смысле по плану ты это не поймёшь.

Серьёзно? В этих СУБД по плану это видно элементарно, вообще-то. ;)

Серьёзно? В этих СУБД по плану это видно элементарно, вообще-то. ;)

тут ты не прав

тут ты не прав

Ну так покажите пример.

Серьёзно? В этих СУБД по плану это видно элементарно, вообще-то. ;)

Я АБСОЛЮТНО СЕРЬЁЗНО говорю.

Я АБСОЛЮТНО СЕРЬЁЗНО говорю.

И Вы покажите пример.

круговую диаграмму представь, это 100% , теперь разбей на сектора, каждой базе будет свой сектор) где-то больше, где-то меньше..

Есть три двери, за двумя из них mysql, за одной postgres. После того, как ты выбрал наугад одну из них, ведущий открывает одну из двух других - там MySQL - и спрашивает, будешь ли ты менять свой выбор. Поменяешь?

Ну так покажите пример.

по плану ты увидишь только что 2 сабквери скалярных есть, и что использовалось для запроса, а вот сколько из них реально выполнялось - только профайл

Я просил этого лисёнка дать мне его конкретный запрос. ОН дал. Это не относится к поддиалогу с тобой.

Про лисенка.. Я не програмер. Копипащу програмерские умные слова в чатик. А они мне своими програмерскими умными словами отвечают. Это почти как мяукать на кота или гавкать на собаку. Прикольно. Как будто общаемся.

спаму много )

пусть люди на ус мотают

Есть три двери, за двумя из них mysql, за одной postgres. После того, как ты выбрал наугад одну из них, ведущий открывает одну из двух других - там MySQL - и спрашивает, будешь ли ты менять свой выбор. Поменяешь?

это было в фильме, а там сперли из телешоу

по плану ты увидишь только что 2 сабквери скалярных есть, и что использовалось для запроса, а вот сколько из них реально выполнялось - только профайл

Нет. Вы что, актуальных планов в MS SQL не видели? Или EXPLAIN ANALYZE в PostgreSQL?

и кстати MVCC в mysql применима не для всех случаев! а для Maria, InnoDB, Falcon, XtraDB, если верить вики

вы найдите сначала адеквата, до сих пор сидящего на MyISAM

это было в фильме, а там сперли из телешоу

А там из математики

я к этому и веду, что вычисление, к примеру небольшого объема - не принципиален, но если бигдата , то сумму считать 10 раз накладно

мммм бигжата в мускуле

вы найдите сначала адеквата, до сих пор сидящего на MyISAM

мне кажется он это и написал

И Вы покажите пример.

Пример не буду показывать. Но словами скажу. ПЛан выполнения запроса -- это направленный граф. НЕ ДЕРЕВО. Но если его показывать не в виде дерева, будет неудобно его читать. Поэтому люди при показе плана часто делают его имено деревом, ТОЛЬКО для показа. Естественно, чтобы разорвать циклы, некоторые ветки удаляются, а некоротые вершины дублируются. (ТОЛЬКО ПРИ ПОКАЗЕ)

мммм бигжата в мускуле

Дыааа.. все 27 килобайт данных

Нет. Вы что, актуальных планов в MS SQL не видели? Или EXPLAIN ANALYZE в PostgreSQL?

сейчас бы использовать explain analyze в mysql... эх

Про лисенка.. Я не програмер. Копипащу програмерские умные слова в чатик. А они мне своими програмерскими умными словами отвечают. Это почти как мяукать на кота или гавкать на собаку. Прикольно. Как будто общаемся.

Очень жаль что ты не программер, тебе было бы проще...

вы найдите сначала адеквата, до сих пор сидящего на MyISAM

Не ну логи какие-то хранить в MyISAM ок, нет разве?

Не ну логи какие-то хранить в MyISAM ок, нет разве?

вообще не ок

Очень жаль что ты не программер, тебе было бы проще...

Проще что?

Не ну логи какие-то хранить в MyISAM ок, нет разве?

Зачем?

Проще что?

проще понимать больше людей.

вообще не ок

А почему ? Пишется быстрее, коммитов нет, лога нет. А если что там ухнется -- да и насрать...

проще понимать больше людей.

А оно мне точно нужно?

А почему ? Пишется быстрее, коммитов нет, лога нет. А если что там ухнется -- да и насрать...

интересный у вас менеджмент логов

А почему ? Пишется быстрее, коммитов нет, лога нет. А если что там ухнется -- да и насрать...

блокировка уровня таблицы, нифига оно не быстрее

А почему ? Пишется быстрее, коммитов нет, лога нет. А если что там ухнется -- да и насрать...

Если хранить что то на что насрать если оно ухнется. То нахрена оно нужно вообще его хранить?

А оно мне точно нужно?

Не знаю. А по поводу сортировки мусора - ты прав, но повторюсь, что в моём случае результаты элементарных арифметических операций писать в базу - это тупо, когда у меня их может быть очень много...

зачем писать в RDBMS append-only data?

Пример не буду показывать. Но словами скажу. ПЛан выполнения запроса -- это направленный граф. НЕ ДЕРЕВО. Но если его показывать не в виде дерева, будет неудобно его читать. Поэтому люди при показе плана часто делают его имено деревом, ТОЛЬКО для показа. Естественно, чтобы разорвать циклы, некоторые ветки удаляются, а некоротые вершины дублируются. (ТОЛЬКО ПРИ ПОКАЗЕ)

Я прочитал и думаю... причём тут мой конкретный пример и вопрос?!

зачем писать в RDBMS append-only data?

вот тут я соглашусь

блокировка уровня таблицы, нифига оно не быстрее

Так если один клиент только пишет, и нормально

Не знаю. А по поводу сортировки мусора - ты прав, но повторюсь, что в моём случае результаты элементарных арифметических операций писать в базу - это тупо, когда у меня их может быть очень много...

Если чего то у тебя очень много то видимо ты не понимаешь что ты делаешь и зачем.

Так если один клиент только пишет, и нормально

в современных реалиях - обычно вдесятером пытаются натянуть сову на глобус, так что он мало где применим

брякну-ка я тоже умным словом: комбинаторный взрыв

Если чего то у тебя очень много то видимо ты не понимаешь что ты делаешь и зачем.

))) насмешил)

Я прочитал и думаю... причём тут мой конкретный пример и вопрос?!

Ну не понимаешь, и ладно. Мой лимит времени выходит... И так уже перебрал...