Зачем появляются новые языки программирования? Сколько их и каких на самом деле нужно?

[zVlad]

А может кто-нибудь из знатоков программирования объяснить почему байт код и виртуальная машина интерпретирующая его?

[Flash-04]

что почему? скорее для чего?
"Write Once Run Anywhere"
К примеру Java приложение может в теории без перекомпиляции выполняться на MF и внутри smart card.
"В теории" - потому что реальное приложение зависит от наличия базовых frameworks, которые будут разные в Java SE и Java Card. Но сам байт код будет действительно выполняться и там, и там.
При использовании JIT (just in time compiler) потери в производительности минимальны.
Но C++ как правило будет быстрее. При "промышленной" разработке софта необходимо учитывать, сколько потом усилий уйдет на отладку и вылавливание блох. С++ требует недюжей дисциплинированности программиста, потому цена разработки на С++ будет выше.
https://benchmarksgame-team.pages.debia ... /java.html

[zVlad]

что почему? скорее для чего?
"Write Once Run Anywhere"
К примеру Java приложение может в теории без перекомпиляции выполняться на MF и внутри smart card.
"В теории" - потому что реальное приложение зависит от наличия базовых frameworks, которые будут разные в Java SE и Java Card. Но сам байт код будет действительно выполняться и там, и там.
При использовании JIT (just in time compiler) потери в производительности минимальны.
Но C++ как правило будет быстрее. При "промышленной" разработке софта необходимо учитывать, сколько потом усилий уйдет на отладку и вылавливание блох. С++ требует недюжей дисциплинированности программиста, потому цена разработки на С++ будет выше.
https://benchmarksgame-team.pages.debia ... /java.html

Это здорово что ответили именно Вы. Тогда скажите как называется процесс выполнения байт кода?
Ну и чтобы два раза не вставать скажите почему все таки нельзя обойтись без байт кода даже если не нужна переносимость?

[sp123]

Упростим для ясности безо всяких rowid.

select * from my_table;

id name
1 aaa
2 aaa
3 aaa
4 aaa
5 bbb
6 bbb
7 ccc

1) По каждой записи в таблице найдем минимальный id с тем же name:

select t.id,
t.name,
(select min(id) from my_table where name = t.name) as min_id
from my_table t;

id name min_id
1 aaa 1
2 aaa 1
3 aaa 1
4 aaa 1
5 bbb 5
6 bbb 5
7 ccc 7

Если не отвлекаться на оптимальность запроса, никаких противоречий и багов тут нет.

Теперь сравниваем 1-ю и 3-ю колонку.

2) Вот эти записи мы хотим оставить:

select t.id,
t.name
from my_table t
where t.id = (select min(id) from my_table where name = t.name) ;

id name
1 aaa
5 bbb
7 ccc

3) А вот эти записи мы хотим удалить:

select t.id,
t.name
from my_table t
where t.id > (select min(id) from my_table where name = t.name)

id name
2 aaa
3 aaa
4 aaa
6 bbb

Вместо ">" можно поставить "!=", не важно.

[Flash-04]

Это здорово что ответили именно Вы. Тогда скажите как называется процесс выполнения байт кода?
Ну и чтобы два раза не вставать скажите почему все таки нельзя обойтись без байт кода даже если не нужна переносимость?

процесс исполнения байт кода по сути ничем не отличается от исполнения процессорного кода. Не верите? SUN даже разработал picoJava - hardware implementation Java машины, можно сделать на базе FPGA к примеру.
Современные процессоры тоже не исполняют свои инструкции "as is", внутри их есть ещё один уровень - "микрокод".
"Microcode is a technique that interposes a layer of computer organization between the CPU hardware and the programmer-visible instruction set architecture of the computer"

Обойтись можно, но Java была создана именно как готовый "виртуальный процессор" который можно испольнять on-top других систем.
Кстати, чего вы решили что переносимость не нужна? Немало приложений которые могут испольняться под управлением Windows или Linux, но достигать этого можно по разному. Java - один из возможных способов.

Хороший пример: Android OS. Приложения написаны на Java и могут испольняться на любом "железе" на котором установлена Android OS. Разработчикам приложений не нужно думать какой процессов будет на телефоне, им остается только волноваться за разрешение экрана, чтобы приложение корректно отображалось на любом из них.

[KinDzaDza]

Фактически, да все дубликаты, кроме одного, будут удалены в первой же итерации на подзапросе, но вместе с ними будут удалены и все остальные строки за той что будет обработана первой.
...
Таким образом результат этого delete будет не предсказуемым. Таблица будет проряжена и транкейтнута случайным образом.

Вы ошибаетесь. Посмотрите план выполнения такого запроса. Из-за того, что в подзапросе есть условие связи на внешнюю таблицу, этот подзапрос будет "выполняться" каждый раз для нового набора значений сравниваемых полей.
В принципе sp123 все уже рассказал выше. У меня под рукой нет Оракла, есть MySQL.

Code: Select all

mysql> select * from t;
+----+------+
| id | name |
+----+------+
|  1 | aaa  |
|  2 | aaa  |
|  3 | aaa  |
|  4 | bbb  |
|  5 | bbb  |
|  6 | ccc  |
|  7 | aaa  |
+----+------+
7 rows in set (0.00 sec)

mysql> select t1.* from t t1 where t1.id > (select min(t2.id) from t t2 where t2.name = t1.name);
+----+------+
| id | name |
+----+------+
|  2 | aaa  |
|  3 | aaa  |
|  5 | bbb  |
|  7 | aaa  |
+----+------+
4 rows in set (0.00 sec)

mysql> explain select t1.* from t t1 where t1.id > (select min(t2.id) from t t2 where t2.name = t1.name);
+----+--------------------+-------+------+---------------+------+---------+------+------+-------------+
| id | select_type        | table | type | possible_keys | key  | key_len | ref  | rows | Extra       |
+----+--------------------+-------+------+---------------+------+---------+------+------+-------------+
|  1 | PRIMARY            | t1    | ALL  | NULL          | NULL | NULL    | NULL |    7 | Using where |
|  2 | DEPENDENT SUBQUERY | t2    | ALL  | NULL          | NULL | NULL    | NULL |    7 | Using where |
+----+--------------------+-------+------+---------------+------+---------+------+------+-------------+
2 rows in set (0.00 sec)

https://dev.mysql.com/doc/refman/8.0/en ... utput.html

PRIMARY is the outermost SELECT
...
For DEPENDENT SUBQUERY, the subquery is re-evaluated only once for each set of different values of the variables from its outer context.

[zVlad]

Это здорово что ответили именно Вы. Тогда скажите как называется процесс выполнения байт кода?
Ну и чтобы два раза не вставать скажите почему все таки нельзя обойтись без байт кода даже если не нужна переносимость?

процесс исполнения байт кода по сути ничем не отличается от исполнения процессорного кода. Не верите? SUN даже разработал picoJava - hardware implementation Java машины, можно сделать на базе FPGA к примеру.
Современные процессоры тоже не исполняют свои инструкции "as is", внутри их есть ещё один уровень - "микрокод".
"Microcode is a technique that interposes a layer of computer organization between the CPU hardware and the programmer-visible instruction set architecture of the computer"

....

Вы мне о микрокоде рассказывать будете?:

http://scihi.org/ibm-system360-microcode/

On April 7, 1964, IBM introduced the IBM System/360, a rather successful family of mainframe computer systems, originally produced between 1965 and 1978 using microcode to implement the instruction set.
........
IBM was the first manufacturer to exploit microcode technology to implement a compatible range of computers of widely differing performance, although the largest, fastest, models had hard-wired logic instead.

[zVlad]

Фактически, да все дубликаты, кроме одного, будут удалены в первой же итерации на подзапросе, но вместе с ними будут удалены и все остальные строки за той что будет обработана первой.
...
Таким образом результат этого delete будет не предсказуемым. Таблица будет проряжена и транкейтнута случайным образом.

Вы ошибаетесь. Посмотрите план выполнения такого запроса. Из-за того, что в подзапросе есть условие связи на внешнюю таблицу, этот подзапрос будет "выполняться" каждый раз для нового набора значений сравниваемых полей.
В принципе sp123 все уже рассказал выше. У меня под рукой нет Оракла, есть MySQL.

Code: Select all

mysql> select * from t;
+----+------+
| id | name |
+----+------+
|  1 | aaa  |
|  2 | aaa  |
|  3 | aaa  |
|  4 | bbb  |
|  5 | bbb  |
|  6 | ccc  |
|  7 | aaa  |
+----+------+
7 rows in set (0.00 sec)

mysql> select t1.* from t t1 where t1.id > (select min(t2.id) from t t2 where t2.name = t1.name);
+----+------+
| id | name |
+----+------+
|  2 | aaa  |
|  3 | aaa  |
|  5 | bbb  |
|  7 | aaa  |
+----+------+
4 rows in set (0.00 sec)

mysql> explain select t1.* from t t1 where t1.id > (select min(t2.id) from t t2 where t2.name = t1.name);
+----+--------------------+-------+------+---------------+------+---------+------+------+-------------+
| id | select_type        | table | type | possible_keys | key  | key_len | ref  | rows | Extra       |
+----+--------------------+-------+------+---------------+------+---------+------+------+-------------+
|  1 | PRIMARY            | t1    | ALL  | NULL          | NULL | NULL    | NULL |    7 | Using where |
|  2 | DEPENDENT SUBQUERY | t2    | ALL  | NULL          | NULL | NULL    | NULL |    7 | Using where |
+----+--------------------+-------+------+---------------+------+---------+------+------+-------------+
2 rows in set (0.00 sec)

https://dev.mysql.com/doc/refman/8.0/en ... utput.html

PRIMARY is the outermost SELECT
...
For DEPENDENT SUBQUERY, the subquery is re-evaluated only once for each set of different values of the variables from its outer context.

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

Но подзаорос выполнятеся автономно и только результат его передается во внешний. В данном случае с функцией min это будет одиночное значение возвращенное этой функцией на множестве строк удовлетворыющих предикату в подзапросе. А Вы, ошибочно, считаете что подзапрас вернет все множество. Это не так. Это было так если бы не было функции min, или подобной ей - sum, например, count(*) и т.п.. Учите теорию.

И слушайте, не надо ссылок.

[KinDzaDza]

А я разве говорю иначе.

Да, говорите и даже настаиваете:

Фактически, да все дубликаты, кроме одного, будут удалены в первой же итерации на подзапросе, но вместе с ними будут удалены и все остальные строки за той что будет обработана первой.
...
Таким образом результат этого delete будет не предсказуемым. Таблица будет проряжена и транкейтнута случайным образом.

Выделенное в Вашей цитате не верно, никаких «всех остальных строк» там не будет.
Что, как видно на приведённых примерах совсем не так и рассматриваемый запрос работает совсем не так как Вы думаете он должен работать. Ничего случайного и непредсказуемого там не будет. Останутся именно записи с минимальными значениями id по своим группам сравнения в единственном экземпляре. Как и просили. Если надо оставить из дубликатов какие-то другие записи - ну флаг в руки, измените/дополните критерий отбора.

В подзапросе всегда есть предикаты связи с внешним по отношению к нему.

Правда что ли? А как же select * from a where id in (select id from b)

В данном случае с функцией min это будет одиночное значение возвращенное этой функцией на множестве строк удовлетворыющих предикату в подзапросе. А Вы, ошибочно, считаете что подзапрас вернет все множество. Это не так. Это было так если бы не было функции min, или подобной ей - sum, например, count(*) и т.п.. Учите теорию.

Вы сначала приписываете мне то, что я не говорил, а потом радостно разоблачаете.

И слушайте, не надо ссылок.

Ссылка была дана исключительно для того, чтобы можно было при желании посмотреть что именно в MySQL explain plan имеется ввиду за всякими словами типа PRIMARY, DEPENDENT SUBQUERY и т.п.

[zVlad]

А я разве говорю иначе.

Да, говорите и даже настаиваете:

Фактически, да все дубликаты, кроме одного, будут удалены в первой же итерации на подзапросе, но вместе с ними будут удалены и все остальные строки за той что будет обработана первой.
...
Таким образом результат этого delete будет не предсказуемым. Таблица будет проряжена и транкейтнута случайным образом.

Выделенное в Вашей цитате не верно, никаких «всех остальных строк» там не будет.
Что, как видно на приведённых примерах совсем не так и рассматриваемый запрос работает совсем не так как Вы думаете он должен работать. Ничего случайного и непредсказуемого там не будет. Останутся именно записи с минимальными значениями id по своим группам сравнения в единственном экземпляре. Как и просили. Если надо оставить из дубликатов какие-то другие записи - ну флаг в руки, измените/дополните критерий отбора.

В подзапросе всегда есть предикаты связи с внешним по отношению к нему.

Правда что ли? А как же select * from a where id in (select id from b)

В данном случае с функцией min это будет одиночное значение возвращенное этой функцией на множестве строк удовлетворыющих предикату в подзапросе. А Вы, ошибочно, считаете что подзапрас вернет все множество. Это не так. Это было так если бы не было функции min, или подобной ей - sum, например, count(*) и т.п.. Учите теорию.

Вы сначала приписываете мне то, что я не говорил, а потом радостно разоблачаете.

И слушайте, не надо ссылок.

Ссылка была дана исключительно для того, чтобы можно было при желании посмотреть что именно в MySQL explain plan имеется ввиду за всякими словами типа PRIMARY, DEPENDENT SUBQUERY и т.п.

Приведите доказательство что Вы правы. Загоните в ВАш MySQL данные и выполните запрос, т.е. материализуйте пример sp123.

[sp123]

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


Sent from my iPhone using Tapatalk Pro

[KinDzaDza]

Приведите доказательство что Вы правы. Загоните в ВАш MySQL данные и выполните запрос, т.е. материализуйте пример sp123.

Так уже - Вы же как раз это и цитировали: viewtopic.php?p=7512216#p7512216
Там между тэгами CODE результаты выполнения запроса в MySQL, это окошко скроллируемо.
Если бы Вы были правы, второй запрос вернул бы все записи кроме первой с самым маленьким id в этой таблице.

[zVlad]

Приведите доказательство что Вы правы. Загоните в ВАш MySQL данные и выполните запрос, т.е. материализуйте пример sp123.

Так уже - Вы же как раз это и цитировали: viewtopic.php?p=7512216#p7512216
Там между тэгами CODE результаты выполнения запроса в MySQL, это окошко скроллируемо.
Если бы Вы были правы, второй запрос вернул бы все записи кроме первой с самым маленьким id в этой таблице.

Хорошо. Проверю на DB2.

[KinDzaDza]

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

Вот, PostgreSql за нас!
Там правда у iDesperado на Оракле что-то не получилось, но он ROWNUM использовал а не ROWID, видимо из-за этого и не вышло.
У меня нет сейчас доступа к Ораклу, а качать и ставить дома в лом.

[zVlad]

Приведите доказательство что Вы правы. Загоните в ВАш MySQL данные и выполните запрос, т.е. материализуйте пример sp123.

Так уже - Вы же как раз это и цитировали: viewtopic.php?p=7512216#p7512216
Там между тэгами CODE результаты выполнения запроса в MySQL, это окошко скроллируемо.
Если бы Вы были правы, второй запрос вернул бы все записи кроме первой с самым маленьким id в этой таблице.

Отвез соседа на берег и без проверки в ДБ2 соглашаюсь в том что был не прав. Я недоучел что условие связи работает в обе стороны, не только в подзапросе но и в основном запросе тоже.
Извиняюсь если что не так.
P.S. Правильнее будет сказать что основной запрос выполняет подзапрос для каждой строки таблицы по всей таблице. Или иначе scope основного запроса - строка, подзапроса вся таблица.