Худший SQL когда-либо?

выберите из *

Очень плохо.

Конечно, классический xkcd:

WHERE name = ROBERT'); DROP TABLE students;--

Клиент хранил список из трех значений, разделенных запятыми, в поле varchar (классическое приложение ASP), поэтому у него была хранимая процедура, которая выглядела примерно так:

SELECT *
FROM
    SomeTable
WHERE
    Field LIKE @Param + ',%'
    OR
    Field LIKE '%,' + @Param + ',%'
    OR
    Field LIKE '%,' + @Param

Должно быть очевидно, почему это ужасно :)

Недавно я видел (более чем) 4000-строчную хранимую процедуру TSQL, которая представляла собой цепочку статусов IF для сопоставления частей адресов. Его можно сократить до менее чем 50 строк!

Сохраняю код для будущего DailyWTF!

SELECT * FROM some_table;

Что сделало это настолько плохим, так это то, что код полагался на получение результатов в порядке на основе отметки времени. Это, по-видимому, работало какое-то время, прежде чем меня вызвали, чтобы это исправить.

DELETE FROM table

Сразу после того, как я напечатал и выполнил его, я забыл о предложении WHERE. Теперь я всегда сначала запускаю оператор SELECT и меняю SELECT на DELETE после того, как убедился, что это повлияет на правильные строки.

select * from users where clue > 0;
0 results found.

Вероятно, это не самое худшее, но я вижу это слишком часто (Неправильное использование группы by clause):

SELECT
  C.CustomerID, C.CustomerName, C.CustomerType, C.Address1, C.City,   
  C.State, SUM(S.Sales) as TotalSales
FROM
  Customers C
INNER JOIN Sales S
  ON C.CustomerID = S.CustomerID
GROUP BY
  C.CustomerID, C.CustomerName, C.CustomerType, C.Address1, C.City, C.State

Вместо:

SELECT
  C.CustomerID, C.CustomerName,
  C.CustomerType, C.Address1, C.City,
  C.State, S.TotalSales
FROM
  Customers C
INNER JOIN
  (SELECT CustomerID, SUM(Sales) as TotalSales FROM Sales GROUP BY CustomerID) S
ON
  C.CustomerID = S.CustomerID

Мое собственное, о котором еще далеко до публикации - сейчас закрывается на 3500 строках.

Я действительно должен разделить вину с абсолютно ужасной схемой. То, что начиналось как простое упражнение по преобразованию денормализованных данных с помощью некоторых объединений, превратилось в громоздкий кошмар. Сильно требует ремонта.

Второе место занял:

select 
case datepart(mm,getdate())
when 1 then 'Jan'
when 2 then 'Feb'
when 3 then 'March'
when 4 then 'Apr'
when 5 then 'May'
when 6 then 'Jun'
when 7 then 'July'
when 8 then 'Aug'
when 9 then 'Sept'
when 10 then 'Otc'
when 11 then 'Nov'
when 11 then 'Dec'
end

В этом посте нет опечаток - так оно и было написано. Спасибо, консультации долларов!

Я, конечно, реорганизовал с помощью Select left (datename (mm, getdate ()), 3)

прочтите это вслух.

select [select],*,star as [as] from [from],[order] order by [by] 

Когда я впервые получил свою текущую работу, моим первым проектом было создание приложения, которое суммировало бы наши данные об использовании лицензий в наших компьютерных лабораториях. Он настаивал на том, что не хочет нормализовать серверную базу данных, потому что соединения были «слишком дорогими». Это была моя первая неделя, и я не мог спорить.

Теперь, чтобы извлечь какие-либо полезные данные из базы данных, нужно «отменить» денормализацию в каждом запросе, который должен извлекать сводки для удаления дублированных данных в каждой строке. Конечно, это единственные реально используемые запросы. Вы видите множество вложенных выборок, которые были бы совершенно ненужными, если бы данные были нормализованы, например:

select location, sum(login_time) as total_login_time
from
    (select location, session_id, max(login_time) as login_time
     from sessions
     where location in ('lab1','lab2') 
           and session_start >= @start_date 
           and session_end <= @end_date
     group by location, session_id) tbl
group by location

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

Сейчас босса нет, а переписывать некогда ...

УДАЛИТЬ ИЗ some_table WHERE some_thing IN (ВЫБЕРИТЕ some_column_from_wrong_table ИЗ правильной_таблицы, ГДЕ some_id = something).

В some_column_from_wrong_table есть столбец, которого даже не было в таблице, но он был в другой таблице. Проблема заключалась в том, что правильная_таблица была названа «Событие», и каким-то образом она вернула ВСЕ строки вместо НЕТ строк (или, что более важно, ошибку!).

Два извлеченных урока: НИКОГДА и ни при каких обстоятельствах не называйте таблицу после формы имени системы любой. Во-вторых, сначала нужно запустить операторы выбора, а затем изменить на удаление.

Между прочим, это был SqlServer 2005. Я все еще злюсь, что это не привело к ошибке.

В базе данных Access был запрос, подобный следующему:

SELECT *
FROM Bad_2 INNER JOIN Bad_1 ON Bad_2.Bad_1_id = Bad_1.ID;

и в обеих таблицах было поле с тем же именем. Когда Access встречает имя поля во второй раз, он создает для него новое имя. Предыдущий парень использовал сгенерированное имя поля в коде.

В свое время видел много прискорбных кусков SQL. Один, который приходит на ум, имеет форму

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

Кажется нормальным в тестовых системах с 10 или около того строками, 100 000–1 миллион = неприятно даже для первичной ключевые поиски.

Кстати, решение состоит в том, чтобы загрузить данные в базу данных и думать наборами.

- Выберите свой любимый язык, например. perl, питон ...

загрузить файл в структуру данных (например, массив)

for (1 .. n) loop
myid := array[n];
select * from table where id = myid;
if the row exists update table set ... where id = myid;
end loop;

Худший ИСПОЛЬЗОВАТЬ SQL-запроса каждые:

Запрос SELECT, который подсчитывает количество строк, соответствующих определенному условию, вызываемый в условии остановки цикла for. Что-то вроде этого:

for(int i = 0; i < query("SELECT COUNT .... WHERE ..."); i++)
{

}

И нет, результат запроса не меняется на каждой итерации. Да, я понимаю, что сервер будет кэшировать результат.

В сообщении в группу новостей comp.databases.informix - настоящая рабочая таблица Informix (которую я не рекомендую использовать):

CREATE TABLE VIEW
(
    DECIMAL     CHAR(30),
    NOT         INTEGER NOT NULL,
    SERIAL      DATE NOT NULL,
    NULL        CHAR(1) NOT NULL,
    INTEGER     DECIMAL(13,6) NOT NULL
);

Помогает (незначительно), если вы знаете, что SERIAL - это тип в базах данных Informix - по сути, один из типов для последовательной генерации автоматически назначаемых номеров.

Мне понравился репостен недавно на dailywtf, история, которая идет с ним, тоже замечательна.

Хранимая процедура PL / SQL (Oracle), которая сортирует набор результатов с помощью Пузырьковая сортировка. Это было обнаружено, когда меня и администратора базы данных попросили выяснить серьезную проблему с производительностью. Разработчик, «эксперт» Oracle, работал над этим больше недели. Он объяснил с невозмутимым видом, что узнал о пузырьковой сортировке на уроке информатики. Алгоритм обычно используется для иллюстрации низкой производительности.

Заменил весь беспорядок предложением ORDER BY. Производительность улучшилась на несколько порядков.

Думаю, это худшее (особенно после болезненного и нулевого отката):

DROP DATABASE;
ROLLBACK;

SUBSTRING(
(SUBSTRING(LastName, 0, CHARINDEX(' ', LastName)) + ', ' + FirstName),
0,
CHARINDEX(' ', (SUBSTRING(LastName, 0, CHARINDEX(' ', LastName)) + ', ' + 
FirstName), LEN(LastName) + 3)
)

Очевидно, они не были знакомы с RTRIM;

RTRIM(LastName) + ', ' + RTRIM(FirstName)

SELECT name FROM categories WHERE id IN (".implode(",",corrected_cats($ad->id)).") ORDER BY name ASC

Да, вы правильно прочитали ... поля в поле, разделенные запятыми.