Вопросы на собеседовании / Java

ReSQL.ru

Мобильная версия Контакт Правила FAQ Помощь

Гость

Войти | Регистрация | Профиль | Очистить

Новые сообщения | Избранное

Форумы | Пользователи | Статистика | Мод. лог | Поиск

Цитировать

Написать

Автор*:

Ввести пароль для входа

Тема*:

Сообщение

Данное сообщение тематическое

Сообщение содержит картинки или видео 18+

Автор:

ВНИМАНИЕ! На данном подфоруме действуют строгие правила. Удостоверьтесь, что ваше сообщение соответствует им!

Форум или тема закрыты для гостей. Необходима авторизация!

Загрузить последнюю сохраненную версию

Вложение:

Вставить как галерею

Максимальный размер вложений: 4,0 МБ, аудио/видео: 8,0 МБ. Картинки большего размера ужимаются, если возможно.

Введите код, изображенный на картинке. Если код нечитаемый, кликните картинку, чтобы загрузить другой вариант.

Отправляя сообщение, я выражаю свое согласие с правилами форума и принимаю пользовательское соглашение.

Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр

Форумы / Java [игнор отключен] [закрыт для гостей] / Вопросы на собеседовании

24 сообщений из 149, страница 6 из 6

все

Вопросы на собеседовании

#39760598

niteshade

Гость

ОзверинniteshadeОзверин,
Пожалуйста, посмотрите на запрос на удаление дубликатов в самом первом посте темы.
Он правильный. Зачем уже четвёртую страницу вы его неправильно переписываете?

не, он неправильный.

Можно по шагам разобрать:

Код: sql

SELECT max(id) FROM table GROUP BY name HAVING count(id)>1

выбрать записи с максимальным id, если эти записи имеют более 1го дупликата по полю name

Код: sql

1.
2.

DELETE FROM table
WHERE id NOT IN(...)

удалить все остальные записи.

То есть те записи, которые НЕ дублируются, будут удалены, останутся только дубликаты с максимальным айди - все наоборот же.
да, был невнимателен
правильный:

Код: sql

1.
2.

DELETE FROM table
WHERE id NOT IN (SELECT max(id) FROM table GROUP BY name, surname)

определение оригинала, как записи с минимальным id - это ваше домысливание
тем не менее, в такой постановке заменяем max на min

...

Рейтинг:

0 / 0

17.01.2019, 06:00

| Ответить | Цитировать | Написать

Вопросы на собеседовании

#39760600

niteshade

Гость

Андрей ПанфиловniteshadeОн правильный.Нет, там еще фамилия же. Вообщем в лоб (без всяких group by, аналитических функций и пр):

Код: sql

1.
2.
3.
4.
5.
6.
7.

delete table t1
where exists (
 select * from table t2
 where t1.name=t2.name
 and t1.surname=t2.surname
 and t1.id > t2.id
)

PS. кто
есть типовой запрос:

Код: sql

1.
2.

DELETE FROM table
WHERE id NOT IN (SELECT max(id) FROM table GROUP BY name, surname)

он просто и эффективен
зачем переписывать его в более сложной и менее эффективной форме?

...

Рейтинг:

0 / 0

17.01.2019, 06:05

| Ответить | Цитировать | Написать

Вопросы на собеседовании

#39760602

Андрей Панфилов

Участник

Откуда: Москва > Melbourne

Сообщения: 3 331

Рейтинг: 0 / 0

niteshadeесть типовой запрос:

Код: sql

1.
2.

DELETE FROM table
WHERE id NOT IN (SELECT max(id) FROM table GROUP BY name, surname)

он просто и эффективен
зачем переписывать его в более сложной и менее эффективной форме?

Ну для начала, попробуйте найти ошибку в "типовом" запросе - она там есть и довольно существенная. Во вторых с "эффективностью" там так себе:

Код: sql

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.

SQL> DELETE task1 t1
 WHERE id NOT IN (  SELECT MAX (id)
                      FROM task1 t2
                  GROUP BY name);  2    3    4


Execution Plan
----------------------------------------------------------
Plan hash value: 1998126981

-------------------------------------------------------------------------------------------
| Id  | Operation              | Name     | Rows  | Bytes |TempSpc| Cost (%CPU)| Time     |
-------------------------------------------------------------------------------------------
|   0 | DELETE STATEMENT       |          |  1000K|   133M|       | 32224   (1)| 00:00:02 |
|   1 |  DELETE                | TASK1    |       |       |       |            |          |
|*  2 |   HASH JOIN RIGHT ANTI |          |  1000K|   133M|    23M| 32224   (1)| 00:00:02 |
|   3 |    VIEW                | VW_NSO_1 |   989K|    12M|       | 19252   (1)| 00:00:01 |
|   4 |     SORT GROUP BY      |          |   989K|   119M|   130M| 19252   (1)| 00:00:01 |
|   5 |      INDEX FULL SCAN   | T1_X     |  1000K|   121M|       | 19252   (1)| 00:00:01 |
|   6 |    INDEX FAST FULL SCAN| T1_X     |  1000K|   121M|       |  5219   (1)| 00:00:01 |
-------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   2 - access("ID"="MAX(ID)")


Statistics
----------------------------------------------------------
        135  recursive calls
        876  db block gets
      38625  consistent gets
      17248  physical reads
     333084  redo size
        867  bytes sent via SQL*Net to client
       1041  bytes received via SQL*Net from client
          3  SQL*Net roundtrips to/from client
          1  sorts (memory)
          1  sorts (disk)

Код: sql

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.

SQL> DELETE task1 t1
 WHERE EXISTS
          (SELECT *
             FROM task1 t2
            WHERE t1.name = t2.name AND t1.id > t2.id);  2    3    4    5


Execution Plan
----------------------------------------------------------
Plan hash value: 2072444764

----------------------------------------------------------------------------------------
| Id  | Operation              | Name  | Rows  | Bytes |TempSpc| Cost (%CPU)| Time     |
----------------------------------------------------------------------------------------
|   0 | DELETE STATEMENT       |       |   506K|   122M|       | 23598   (1)| 00:00:01 |
|   1 |  DELETE                | TASK1 |       |       |       |            |          |
|*  2 |   HASH JOIN SEMI       |       |   506K|   122M|   132M| 23598   (1)| 00:00:01 |
|   3 |    INDEX FAST FULL SCAN| T1_X  |  1000K|   121M|       |  5219   (1)| 00:00:01 |
|   4 |    INDEX FAST FULL SCAN| T1_X  |  1000K|   121M|       |  5219   (1)| 00:00:01 |
----------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   2 - access("T1"."NAME"="T2"."NAME")
       filter("T1"."ID">"T2"."ID")


Statistics
----------------------------------------------------------
          0  recursive calls
        805  db block gets
      38781  consistent gets
          0  physical reads
     315792  redo size
        867  bytes sent via SQL*Net to client
       1052  bytes received via SQL*Net from client
          3  SQL*Net roundtrips to/from client
          1  sorts (memory)
          0  sorts (disk)

...

Рейтинг:

0 / 0

17.01.2019, 07:00

| Ответить | Цитировать | Написать

Вопросы на собеседовании

#39760612

Озверин

Участник

Откуда: Ростов-на-Дону

Сообщения: 3 646

Рейтинг: 0 / 0

niteshade, он правильный только для данного набора данных, вроде уже обсудили.

...

Рейтинг:

0 / 0

17.01.2019, 08:24

| Ответить | Цитировать | Написать

Вопросы на собеседовании

#39760629

Озверин

Участник

Откуда: Ростов-на-Дону

Сообщения: 3 646

Рейтинг: 0 / 0

Андрей Панфилов, а почему во втором случае 0 physical reads?

...

Рейтинг:

0 / 0

17.01.2019, 09:33

| Ответить | Цитировать | Написать

Вопросы на собеседовании

#39760643

Озверин

Участник

Откуда: Ростов-на-Дону

Сообщения: 3 646

Рейтинг: 0 / 0

Озверин,

Код: sql

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.

"Delete on names  (cost=1081.09..1747.03 rows=15198 width=6) (actual time=31.138..31.138 rows=0 loops=1)"
"  ->  Seq Scan on names  (cost=1081.09..1747.03 rows=15198 width=6) (actual time=26.771..30.621 rows=933 loops=1)"
"        Filter: (NOT (hashed SubPlan 1))"
"        Rows Removed by Filter: 15729"
"        SubPlan 1"
"          ->  HashAggregate  (cost=817.91..1028.45 rows=21054 width=40) (actual time=20.265..22.960 rows=15729 loops=1)"
"                ->  Seq Scan on names names_1  (cost=0.00..589.95 rows=30395 width=40) (actual time=0.004..9.098 rows=16662 loops=1)"
"Total runtime: 31.258 ms"


"Delete on names t1  (cost=681.22..3179.15 rows=5243 width=12) (actual time=38.338..38.338 rows=0 loops=1)"
"  ->  Hash Semi Join  (cost=681.22..3179.15 rows=5243 width=12) (actual time=38.337..38.337 rows=0 loops=1)"
"        Hash Cond: (((t1.f)::text = (t2.f)::text) AND ((t1.s)::text = (t2.s)::text))"
"        Join Filter: (t1.id > t2.id)"
"        Rows Removed by Join Filter: 15729"
"        ->  Seq Scan on names t1  (cost=0.00..445.29 rows=15729 width=46) (actual time=0.004..4.245 rows=15729 loops=1)"
"        ->  Hash  (cost=445.29..445.29 rows=15729 width=46) (actual time=20.473..20.473 rows=15729 loops=1)"
"              Buckets: 2048  Batches: 1  Memory Usage: 1227kB"
"              ->  Seq Scan on names t2  (cost=0.00..445.29 rows=15729 width=46) (actual time=0.002..7.740 rows=15729 loops=1)"
"Total runtime: 38.378 ms"

в моем случае разница не велика в пользу агрегирования(быстрее, чем джоины) на таблице в 15000 записей и при условии, что ни одна из них не будет удалена. В случае, если перейти на выборку по одному текстовому полю, а не по двум - результаты остаются очень похожими.

...

Рейтинг:

0 / 0

17.01.2019, 09:58

| Ответить | Цитировать | Написать

Вопросы на собеседовании

#39760646

Озверин

Участник

Откуда: Ростов-на-Дону

Сообщения: 3 646

Рейтинг: 0 / 0

Озверин,

Код: sql

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.

-- Table: temp.names

-- DROP TABLE temp.names;

CREATE TABLE temp.names
(
  id integer NOT NULL,
  f character varying(150),
  s character varying(150),
  CONSTRAINT pk PRIMARY KEY (id)
)
WITH (
  OIDS=FALSE
);
ALTER TABLE temp.names
  OWNER TO postgres;

-- Index: temp.f_idx

-- DROP INDEX temp.f_idx;

CREATE INDEX f_idx
  ON temp.names
  USING btree
  (f COLLATE pg_catalog."default");

-- Index: temp.s_idx

-- DROP INDEX temp.s_idx;

CREATE INDEX s_idx
  ON temp.names
  USING btree
  (s COLLATE pg_catalog."default");

EXPLAIN ANALYZE DELETE FROM temp.names
WHERE id NOT IN (SELECT max(id) FROM temp.names GROUP BY f)

EXPLAIN ANALYZE  DELETE FROM temp.names t1
 WHERE EXISTS
          (SELECT t2.*
             FROM temp.names t2
            WHERE t1.f = t2.f AND t1.id > t2.id);

...

Рейтинг:

0 / 0

17.01.2019, 09:59

| Ответить | Цитировать | Написать

Вопросы на собеседовании

#39760647

Озверин

Участник

Откуда: Ростов-на-Дону

Сообщения: 3 646

Рейтинг: 0 / 0

Озверин,

и вариант со сравнением по 2м полям:

Код: sql

1.
2.
3.
4.
5.
6.
7.
8.

EXPLAIN ANALYZE DELETE FROM temp.names
WHERE id NOT IN (SELECT max(id) FROM temp.names GROUP BY f, s)

EXPLAIN ANALYZE  DELETE FROM temp.names t1
 WHERE EXISTS
          (SELECT t2.*
             FROM temp.names t2
            WHERE t1.f = t2.f AND t1.s = t2.s AND t1.id > t2.id);

...

Рейтинг:

0 / 0

17.01.2019, 10:00

| Ответить | Цитировать | Написать

Вопросы на собеседовании

#39760653

Озверин

Участник

Откуда: Ростов-на-Дону

Сообщения: 3 646

Рейтинг: 0 / 0

Озверин,

и наконец, корректный вариант дает очень схожу картину мира:

EXPLAIN ANALYZE
DELETE
FROM temp.names t1
WHERE t1.id NOT IN(SELECT min(t2.id) FROM temp.names t2 GROUP BY t2.f, t2.s HAVING count(t2.id)>1 OR count(t2.id)=1);

"Delete on names t1 (cost=742.56..1127.83 rows=8331 width=6) (actual time=35.358..35.358 rows=0 loops=1)"
" -> Seq Scan on names t1 (cost=742.56..1127.83 rows=8331 width=6) (actual time=35.357..35.357 rows=0 loops=1)"
" Filter: (NOT (hashed SubPlan 1))"
" Rows Removed by Filter: 15729"
" SubPlan 1"
" -> HashAggregate (cost=551.89..715.32 rows=10895 width=40) (actual time=23.995..28.049 rows=15729 loops=1)"
" Filter: ((count(t2.id) > 1) OR (count(t2.id) = 1))"
" -> Seq Scan on names t2 (cost=0.00..343.62 rows=16662 width=40) (actual time=0.007..6.850 rows=15729 loops=1)"
"Total runtime: 35.475 ms"

Все это связано с тем, что после 1-2х запросов большинство баз создает свой какой-нить хэш-агрегат и уже работает с ним. Потому, чтобы показать РЕАЛЬНУЮ разницу между по сути очень похожими запросами, надо поработать с базой, поудалять оттуда данные, повставлять новые, повыполнять запросы на удаление, а потом уже анализировать итоги. Как и в java - надо бе разогреться.

...

Рейтинг:

0 / 0

17.01.2019, 10:09

| Ответить | Цитировать | Написать

Вопросы на собеседовании

#39760657

Андрей Панфилов

Участник

Откуда: Москва > Melbourne

Сообщения: 3 331

Рейтинг: 0 / 0

Озверина почему во втором случае 0 physical reads?Потому что табличка с индексом в память легла - оракл может себе позволить, а вопрос скорее всего в том, почему в первом случае (group by) не 0, ответ тут простой: оно сортировку решило не в памяти делать, а на диске (1 sorts (disk)). В случае ваших 15 тыс. смотреть даже нечего, сделайте несколько миллионов и индекс нормальный, типа (дубликат, id).

Ну и еще доводы в пользу exists:
в случае group by возникают краевые эффекты на пустых полях: в данном случае "получится" что null=null, т.е. группируем налы, а удаляем уже по id

из-за NOT IN возникают краевые эффекты на пустых id, т.е. если в таблице есть пустой id, то запрос вообще ничего не удалит

в случае exists я могу базу бомбить несколькими запросами одновременно, просто добавив во внешнее условие name like 'A%', name like 'B%' и пр. В случае group by условие нужно добавлять уже в два места чтобы они коррелировали

...

Рейтинг:

0 / 0

17.01.2019, 10:16

| Ответить | Цитировать | Написать

Вопросы на собеседовании

#39760700

Озверин

Участник

Откуда: Ростов-на-Дону

Сообщения: 3 646

Рейтинг: 0 / 0

Андрей Панфилов, так если сделать 15 млн, то и не ляжет вся она в память, а только - частично. О том и разговор, что первый запрос при всей неэффективности отработал всего на 1 секунду медленее, но НА ДИСКЕ. Короче, на неразогретом оракле. В моем случае он отработал быстрее в обоих случаях.

1. это специфичное для оракла? В пг группировка по null - всегда отдельная группа и никакого сравнения просто нет.
2. пустой primary key? это уже эффект какой-то подозрительный.
3.при like уже под большим вопросом вообще использование индексов, так что делать то вы можете что угодно, но как это повлияет на план запроса - вы не знаете. Правда я вообще не понял, про что этот пункт.

...

Рейтинг:

0 / 0

17.01.2019, 11:10

| Ответить | Цитировать | Написать

Вопросы на собеседовании

#39760702

Озверин

Участник

Откуда: Ростов-на-Дону

Сообщения: 3 646

Рейтинг: 0 / 0

Озверин, единственное, что, для PG - not in менее эффективен в плане работы, чем exists. Потому можно на него перейти, проверить.

...

Рейтинг:

0 / 0

17.01.2019, 11:13

| Ответить | Цитировать | Написать

Вопросы на собеседовании

#39760733

niteshade

Гость

Андрей Панфиловniteshadeесть типовой запрос:

Код: sql

1.
2.

DELETE FROM table
WHERE id NOT IN (SELECT max(id) FROM table GROUP BY name, surname)

Код: sql

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.

SQL> DELETE task1 t1
 WHERE id NOT IN (  SELECT MAX (id)
                      FROM task1 t2
                  GROUP BY name);  2    3    4


Execution Plan
----------------------------------------------------------
Plan hash value: 1998126981

-------------------------------------------------------------------------------------------
| Id  | Operation              | Name     | Rows  | Bytes |TempSpc| Cost (%CPU)| Time     |
-------------------------------------------------------------------------------------------
|   0 | DELETE STATEMENT       |          |  1000K|   133M|       | 32224   (1)| 00:00:02 |
|   1 |  DELETE                | TASK1    |       |       |       |            |          |
|*  2 |   HASH JOIN RIGHT ANTI |          |  1000K|   133M|    23M| 32224   (1)| 00:00:02 |
|   3 |    VIEW                | VW_NSO_1 |   989K|    12M|       | 19252   (1)| 00:00:01 |
|   4 |     SORT GROUP BY      |          |   989K|   119M|   130M| 19252   (1)| 00:00:01 |
|   5 |      INDEX FULL SCAN   | T1_X     |  1000K|   121M|       | 19252   (1)| 00:00:01 |
|   6 |    INDEX FAST FULL SCAN| T1_X     |  1000K|   121M|       |  5219   (1)| 00:00:01 |
-------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   2 - access("ID"="MAX(ID)")


Statistics
----------------------------------------------------------
        135  recursive calls
        876  db block gets
      38625  consistent gets
      17248  physical reads
     333084  redo size
        867  bytes sent via SQL*Net to client
       1041  bytes received via SQL*Net from client
          3  SQL*Net roundtrips to/from client
          1  sorts (memory)
          1  sorts (disk)

Код: sql

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.

SQL> DELETE task1 t1
 WHERE EXISTS
          (SELECT *
             FROM task1 t2
            WHERE t1.name = t2.name AND t1.id > t2.id);  2    3    4    5


Execution Plan
----------------------------------------------------------
Plan hash value: 2072444764

----------------------------------------------------------------------------------------
| Id  | Operation              | Name  | Rows  | Bytes |TempSpc| Cost (%CPU)| Time     |
----------------------------------------------------------------------------------------
|   0 | DELETE STATEMENT       |       |   506K|   122M|       | 23598   (1)| 00:00:01 |
|   1 |  DELETE                | TASK1 |       |       |       |            |          |
|*  2 |   HASH JOIN SEMI       |       |   506K|   122M|   132M| 23598   (1)| 00:00:01 |
|   3 |    INDEX FAST FULL SCAN| T1_X  |  1000K|   121M|       |  5219   (1)| 00:00:01 |
|   4 |    INDEX FAST FULL SCAN| T1_X  |  1000K|   121M|       |  5219   (1)| 00:00:01 |
----------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   2 - access("T1"."NAME"="T2"."NAME")
       filter("T1"."ID">"T2"."ID")


Statistics
----------------------------------------------------------
          0  recursive calls
        805  db block gets
      38781  consistent gets
          0  physical reads
     315792  redo size
        867  bytes sent via SQL*Net to client
       1052  bytes received via SQL*Net from client
          3  SQL*Net roundtrips to/from client
          1  sorts (memory)
          0  sorts (disk)

индексы откуда появились?
опять домысливания?

...

Рейтинг:

0 / 0

17.01.2019, 11:53

| Ответить | Цитировать | Написать

Вопросы на собеседовании

#39760741

niteshade

Гость

Для Oracle всё ещё проще:

Код: sql

1.
2.

DELETE FROM table
WHERE not rowid IN (SELECT max(rowid) FROM table GROUP BY name, surname)

...

Рейтинг:

0 / 0

17.01.2019, 11:59

| Ответить | Цитировать | Написать

Вопросы на собеседовании

#39760742

chpasha

Участник

Сообщения: 10 713

Рейтинг: 0 / 0

Озвериндля PG
для PG кстати работает еще такой запрос (не знаю, пробегал ли - не читал топик целиком)

Код: sql

1.
2.
3.
4.

DELETE   FROM table_with_dups T1
  USING       table_with_dups T2
WHERE  T1.ctid    < T2.ctid     
  AND  T1.name    = T2.name

...

Рейтинг:

0 / 0

17.01.2019, 11:59

| Ответить | Цитировать | Написать

Вопросы на собеседовании

#39760743

Озверин

Участник

Откуда: Ростов-на-Дону

Сообщения: 3 646

Рейтинг: 0 / 0

niteshadeиндексы откуда появились?
опять домысливания?

не откуда, а какие - полнотекстовые какие-нибудь.

...

Рейтинг:

0 / 0

17.01.2019, 11:59

| Ответить | Цитировать | Написать

Вопросы на собеседовании

#39760752

niteshade

Гость

Озверин,
это уже какая-то яростная дичь)
в первом сообщении топика есть условия
исходя из них необходимо решить задачу
может, хватит уже натягивать сову на глобус?))

...

Рейтинг:

0 / 0

17.01.2019, 12:12

| Ответить | Цитировать | Написать

Вопросы на собеседовании

#39760756

Озверин

Участник

Откуда: Ростов-на-Дону

Сообщения: 3 646

Рейтинг: 0 / 0

chpashaОзвериндля PG
для PG кстати работает еще такой запрос (не знаю, пробегал ли - не читал топик целиком)

Код: sql

1.
2.
3.
4.

DELETE   FROM table_with_dups T1
  USING       table_with_dups T2
WHERE  T1.ctid    < T2.ctid     
  AND  T1.name    = T2.name

я как-то с сомнением, если развернуть запрос похоже на :

Код: sql

1.
2.

DELETE FROM table_with_dups T1
WHERE T1.ctid IN(SELECT T2.ctid FROM table_with_dups T2 WHERE  T1.ctid < T2.ctid AND T1.name = T2.name)

то есть похоже, что он сделает ровно обратное. Я не прав?

p.s. в данном случае USING -специфичен для базы.

...

Рейтинг:

0 / 0

17.01.2019, 12:17

| Ответить | Цитировать | Написать

Вопросы на собеседовании

#39760758

Озверин

Участник

Откуда: Ростов-на-Дону

Сообщения: 3 646

Рейтинг: 0 / 0

niteshadeОзверин,
это уже какая-то яростная дичь)
в первом сообщении топика есть условия
исходя из них необходимо решить задачу
может, хватит уже натягивать сову на глобус?))

вопрос пошел немного дальше. Правильные запросы уже были. Что вам не нравится? Не хотите - не обсуждайте.

...

Рейтинг:

0 / 0

17.01.2019, 12:18

| Ответить | Цитировать | Написать

Вопросы на собеседовании

#39760760

Озверин

Участник

Откуда: Ростов-на-Дону

Сообщения: 3 646

Рейтинг: 0 / 0

Озверинchpashaпропущено...

для PG кстати работает еще такой запрос (не знаю, пробегал ли - не читал топик целиком)

Код: sql

1.
2.
3.
4.

DELETE   FROM table_with_dups T1
  USING       table_with_dups T2
WHERE  T1.ctid    < T2.ctid     
  AND  T1.name    = T2.name

я как-то с сомнением, если развернуть запрос похоже на :

Код: sql

1.
2.

DELETE FROM table_with_dups T1
WHERE T1.ctid IN(SELECT T2.ctid FROM table_with_dups T2 WHERE  T1.ctid < T2.ctid AND T1.name = T2.name)

то есть похоже, что он сделает ровно обратное. Я не прав?

p.s. в данном случае USING -специфичен для базы.

а не, вроде все ок.

...

Рейтинг:

0 / 0

17.01.2019, 12:22

| Ответить | Цитировать | Написать

Вопросы на собеседовании

#39760919

mayton

Участник

Откуда: loopback

Сообщения: 53 422

Рейтинг: 2 / 0

Execution plan будем смотреть?

Потому-что для некоторых dbms существует т.н. аналитические функции которые тоже
позволяют решать данную задачу.

Вообще - удаление дубликатов - это страшный боян и в профильных топиках уже на это
не отвечают а просто кидают тебя в Stackoverflow или в какой-то ФАК.

И зачем мы это мурыжым?

...

Рейтинг:

0 / 0

17.01.2019, 14:57

| Ответить | Цитировать | Написать

Вопросы на собеседовании

#39760940

Озверин

Участник

Откуда: Ростов-на-Дону

Сообщения: 3 646

Рейтинг: 0 / 0

Я ждал выступления начальника транспортного цеха и вади...

...

Рейтинг:

0 / 0

17.01.2019, 15:14

| Ответить | Цитировать | Написать

Вопросы на собеседовании

#39761015

Андрей Панфилов

Участник

Откуда: Москва > Melbourne

Сообщения: 3 331

Рейтинг: 0 / 0

Озверинтак если сделать 15 млн, то и не ляжет вся она в память, а только - частично.Ну а какая разница-то? С group by появляется дополнительная операция, как ни крути, она чего-то да и стоит, а изначальный пойнт был в том, что exists - ну это вообще супер сложно и неэффективно, пока автору сего утверждения правоту доказать не удалось.

Озверин1. это специфичное для оракла? В пг группировка по null - всегда отдельная группа и никакого сравнения просто нетну вот есть таблица

idname1null2null
в результате group by с max(id) она превратится в:

idname2null
в итоге delete удалит первую запись, вопрос: это ожидаемое поведение с т.з. постановки задачи или нет? Т.е. когда мы говорим про дубликаты, null = null или нет (когда мы в контексте СУБД, то там все null разные)?

Озверин2. пустой primary key? это уже эффект какой-то подозрительный.ну это вы по названию колонки домыслили уже, а без DDL таблицы что там в действительности - неизвестно.

Озверин3.при like уже под большим вопросом вообще использование индексов, так что делать то вы можете что угодно, но как это повлияет на план запроса - вы не знаете. Правда я вообще не понял, про что этот пункт.ну вот у вас есть PostgreSQL, который не умеет parallel а в базе триллион записей, вопрос: как ускорить удаление?

В целом же, любая логика, основанная на отрицании - она априори неправильная, потому что заставляет думать в четыре раза больше, так что если можно писать прямо, то нужно так и делать.

...

Рейтинг:

0 / 0

17.01.2019, 16:09

| Ответить | Цитировать | Написать

Вопросы на собеседовании

#39761065

Озверин

Участник

Откуда: Ростов-на-Дону

Сообщения: 3 646

Рейтинг: 0 / 0

Андрей Панфилов,

0. Изначальный поинт был про сложно воспринимаемый (человеком для быстрого осмысления) запрос, где много джоинов по текстовым полям. Не знаю, причем тут exist.
1. это странно считать, что за счет доп операции алгоритм будет менее эффективным. Если бы запросы были абсолютно идентичными и в один из них мы вставили доп операцию - это высказывание хотя бы логику имело.
2. Я не знаю, являются ли для постановщика задачи null равными между собой или нет. Спросите у постановщика.
3. Если домысливать нельзя, то изначально дискуссия не имеет смысла и подходит любой запрос для 5 строк. Если бы нельзя было "домысливать", то зачем вы сделали индексы для таблицы, а потом по ним план запроса построили?
4. Если у меня будет триллион записей и этот запрос не будет справляться, я буду смотреть какой запрос лучше справиться с триллионом записей, как я буду смотреть, какой запрос лучше справиться с миллионом записей.

...

Рейтинг:

0 / 0

17.01.2019, 17:33

| Ответить | Цитировать | Написать

24 сообщений из 149, страница 6 из 6

все

Форумы / Java [игнор отключен] [закрыт для гостей] / Вопросы на собеседовании

Читали тему (0):

Читали форум (0):

Пользователи онлайн (0):

start [/forum/topic.php?fid=59&gotonew=1&tid=2121531]:	0ms
get settings:	8ms
get forum list:	16ms
check forum access:	4ms
check topic access:	4ms
track hit:	60ms
get topic data:	10ms
get first new msg:	9ms
get forum data:	3ms
get page messages:	65ms
get tp. blocked users:	1ms
others:	336ms

total:	516ms