Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Java Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 5 [6]      все
 Re: Вопросы на собеседовании  [new]
niteshade
Member

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


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

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

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

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

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

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

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

да, был невнимателен
правильный:
DELETE FROM table
WHERE id NOT IN (SELECT max(id) FROM table GROUP BY name, surname)

определение оригинала, как записи с минимальным id - это ваше домысливание
тем не менее, в такой постановке заменяем max на min
17 янв 19, 06:00    [21787447]     Ответить | Цитировать Сообщить модератору
 Re: Вопросы на собеседовании  [new]
niteshade
Member

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

есть типовой запрос:
DELETE FROM table
WHERE id NOT IN (SELECT max(id) FROM table GROUP BY name, surname)

он просто и эффективен
зачем переписывать его в более сложной и менее эффективной форме?
17 янв 19, 06:05    [21787449]     Ответить | Цитировать Сообщить модератору
 Re: Вопросы на собеседовании  [new]
Андрей Панфилов
Member

Откуда: Москва > Melbourne
Сообщений: 3249
niteshade
есть типовой запрос:
DELETE FROM table
WHERE id NOT IN (SELECT max(id) FROM table GROUP BY name, surname)

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


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

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> 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)
17 янв 19, 07:00    [21787455]     Ответить | Цитировать Сообщить модератору
 Re: Вопросы на собеседовании  [new]
Озверин
Member

Откуда: Ростов-на-Дону
Сообщений: 5183
niteshade, он правильный только для данного набора данных, вроде уже обсудили.
17 янв 19, 08:24    [21787466]     Ответить | Цитировать Сообщить модератору
 Re: Вопросы на собеседовании  [new]
Озверин
Member

Откуда: Ростов-на-Дону
Сообщений: 5183
Андрей Панфилов, а почему во втором случае 0 physical reads?
17 янв 19, 09:33    [21787492]     Ответить | Цитировать Сообщить модератору
 Re: Вопросы на собеседовании  [new]
Озверин
Member

Откуда: Ростов-на-Дону
Сообщений: 5183
Озверин,

"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 записей и при условии, что ни одна из них не будет удалена. В случае, если перейти на выборку по одному текстовому полю, а не по двум - результаты остаются очень похожими.
17 янв 19, 09:58    [21787515]     Ответить | Цитировать Сообщить модератору
 Re: Вопросы на собеседовании  [new]
Озверин
Member

Откуда: Ростов-на-Дону
Сообщений: 5183
Озверин,


-- 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);
17 янв 19, 09:59    [21787519]     Ответить | Цитировать Сообщить модератору
 Re: Вопросы на собеседовании  [new]
Озверин
Member

Откуда: Ростов-на-Дону
Сообщений: 5183
Озверин,

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

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);
17 янв 19, 10:00    [21787520]     Ответить | Цитировать Сообщить модератору
 Re: Вопросы на собеседовании  [new]
Озверин
Member

Откуда: Ростов-на-Дону
Сообщений: 5183
Озверин,

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

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 - надо бе разогреться.
17 янв 19, 10:09    [21787530]     Ответить | Цитировать Сообщить модератору
 Re: Вопросы на собеседовании  [new]
Андрей Панфилов
Member

Откуда: Москва > Melbourne
Сообщений: 3249
Озверин
а почему во втором случае 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 условие нужно добавлять уже в два места чтобы они коррелировали
  • 17 янв 19, 10:16    [21787540]     Ответить | Цитировать Сообщить модератору
     Re: Вопросы на собеседовании  [new]
    Озверин
    Member

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

    1. это специфичное для оракла? В пг группировка по null - всегда отдельная группа и никакого сравнения просто нет.
    2. пустой primary key? это уже эффект какой-то подозрительный.
    3.при like уже под большим вопросом вообще использование индексов, так что делать то вы можете что угодно, но как это повлияет на план запроса - вы не знаете. Правда я вообще не понял, про что этот пункт.
    17 янв 19, 11:10    [21787600]     Ответить | Цитировать Сообщить модератору
     Re: Вопросы на собеседовании  [new]
    Озверин
    Member

    Откуда: Ростов-на-Дону
    Сообщений: 5183
    Озверин, единственное, что, для PG - not in менее эффективен в плане работы, чем exists. Потому можно на него перейти, проверить.
    17 янв 19, 11:13    [21787603]     Ответить | Цитировать Сообщить модератору
     Re: Вопросы на собеседовании  [new]
    niteshade
    Member

    Откуда:
    Сообщений: 10
    Андрей Панфилов
    niteshade
    есть типовой запрос:
    DELETE FROM table
    WHERE id NOT IN (SELECT max(id) FROM table GROUP BY name, surname)
    

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


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

    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> 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)
    

    индексы откуда появились?
    опять домысливания?
    17 янв 19, 11:53    [21787659]     Ответить | Цитировать Сообщить модератору
     Re: Вопросы на собеседовании  [new]
    niteshade
    Member

    Откуда:
    Сообщений: 10
    Для Oracle всё ещё проще:
    DELETE FROM table
    WHERE not rowid IN (SELECT max(rowid) FROM table GROUP BY name, surname)
    
    17 янв 19, 11:59    [21787671]     Ответить | Цитировать Сообщить модератору
     Re: Вопросы на собеседовании  [new]
    chpasha
    Member

    Откуда:
    Сообщений: 7991
    Озверин
    для PG

    для PG кстати работает еще такой запрос (не знаю, пробегал ли - не читал топик целиком)
    DELETE   FROM table_with_dups T1
      USING       table_with_dups T2
    WHERE  T1.ctid    < T2.ctid     
      AND  T1.name    = T2.name 
    
    17 янв 19, 11:59    [21787673]     Ответить | Цитировать Сообщить модератору
     Re: Вопросы на собеседовании  [new]
    Озверин
    Member

    Откуда: Ростов-на-Дону
    Сообщений: 5183
    niteshade
    индексы откуда появились?
    опять домысливания?


    не откуда, а какие - полнотекстовые какие-нибудь.
    17 янв 19, 11:59    [21787674]     Ответить | Цитировать Сообщить модератору
     Re: Вопросы на собеседовании  [new]
    niteshade
    Member

    Откуда:
    Сообщений: 10
    Озверин,
    это уже какая-то яростная дичь)
    в первом сообщении топика есть условия
    исходя из них необходимо решить задачу
    может, хватит уже натягивать сову на глобус?))
    17 янв 19, 12:12    [21787692]     Ответить | Цитировать Сообщить модератору
     Re: Вопросы на собеседовании  [new]
    Озверин
    Member

    Откуда: Ростов-на-Дону
    Сообщений: 5183
    chpasha
    Озверин
    для PG

    для PG кстати работает еще такой запрос (не знаю, пробегал ли - не читал топик целиком)
    DELETE   FROM table_with_dups T1
      USING       table_with_dups T2
    WHERE  T1.ctid    < T2.ctid     
      AND  T1.name    = T2.name 
    


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

    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 -специфичен для базы.
    17 янв 19, 12:17    [21787697]     Ответить | Цитировать Сообщить модератору
     Re: Вопросы на собеседовании  [new]
    Озверин
    Member

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


    вопрос пошел немного дальше. Правильные запросы уже были. Что вам не нравится? Не хотите - не обсуждайте.
    17 янв 19, 12:18    [21787700]     Ответить | Цитировать Сообщить модератору
     Re: Вопросы на собеседовании  [new]
    Озверин
    Member

    Откуда: Ростов-на-Дону
    Сообщений: 5183
    Озверин
    chpasha
    пропущено...

    для PG кстати работает еще такой запрос (не знаю, пробегал ли - не читал топик целиком)
    DELETE   FROM table_with_dups T1
      USING       table_with_dups T2
    WHERE  T1.ctid    < T2.ctid     
      AND  T1.name    = T2.name 
    


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

    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 -специфичен для базы.


    а не, вроде все ок.
    17 янв 19, 12:22    [21787702]     Ответить | Цитировать Сообщить модератору
     Re: Вопросы на собеседовании  [new]
    mayton
    Member

    Откуда: loopback
    Сообщений: 41035
    Execution plan будем смотреть?

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

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

    И зачем мы это мурыжым?
    17 янв 19, 14:57    [21787949]     Ответить | Цитировать Сообщить модератору
     Re: Вопросы на собеседовании  [new]
    Озверин
    Member

    Откуда: Ростов-на-Дону
    Сообщений: 5183
    Я ждал выступления начальника транспортного цеха и вади...
    17 янв 19, 15:14    [21787976]     Ответить | Цитировать Сообщить модератору
     Re: Вопросы на собеседовании  [new]
    Андрей Панфилов
    Member

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

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

    idname
    1null
    2null

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

    idname
    2null

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

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

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

    В целом же, любая логика, основанная на отрицании - она априори неправильная, потому что заставляет думать в четыре раза больше, так что если можно писать прямо, то нужно так и делать.
    17 янв 19, 16:09    [21788086]     Ответить | Цитировать Сообщить модератору
     Re: Вопросы на собеседовании  [new]
    Озверин
    Member

    Откуда: Ростов-на-Дону
    Сообщений: 5183
    Андрей Панфилов,

    0. Изначальный поинт был про сложно воспринимаемый (человеком для быстрого осмысления) запрос, где много джоинов по текстовым полям. Не знаю, причем тут exist.
    1. это странно считать, что за счет доп операции алгоритм будет менее эффективным. Если бы запросы были абсолютно идентичными и в один из них мы вставили доп операцию - это высказывание хотя бы логику имело.
    2. Я не знаю, являются ли для постановщика задачи null равными между собой или нет. Спросите у постановщика.
    3. Если домысливать нельзя, то изначально дискуссия не имеет смысла и подходит любой запрос для 5 строк. Если бы нельзя было "домысливать", то зачем вы сделали индексы для таблицы, а потом по ним план запроса построили?
    4. Если у меня будет триллион записей и этот запрос не будет справляться, я буду смотреть какой запрос лучше справиться с триллионом записей, как я буду смотреть, какой запрос лучше справиться с миллионом записей.
    17 янв 19, 17:33    [21788167]     Ответить | Цитировать Сообщить модератору
    Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 5 [6]      все
    Все форумы / Java Ответить