Худший SQL когда-либо [закрывается]

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

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

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

УДАЛИТЕ ИЗ some_table, ГДЕ some_thing В (ВЫБИРАЮТ some_column_from_wrong_table ИЗ correct_table ГДЕ some_id=something).

some_column_from_wrong_table имеет столбец, который не был даже в таблице, но это было в другой таблице. Проблемой был correct_table, был назван 'Событием', и так или иначе это возвратило ВСЕ строки вместо НИКАКИХ строк (или что еще более важно, ошибка!).

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

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

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

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

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

SELECT * FROM some_table;

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

Замеченный много горестных частей SQL в мое время. Тот, который приходит на ум, имеет форму

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

Кажется хорошо в системах тестирования приблизительно с 10 строками, 100K-1million = противным даже для поисков первичного ключа.

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

- Выберите своего фаворита lang, например, жемчуг, Python...

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

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;

считайте его вслух.

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

Недавно, я видел (больше, чем) 4 000 строк хранимая процедура TSQL, которая была цепочкой ЕСЛИ statments для соответствия частям адресов. Это могло быть уменьшено меньше чем до 50 строк!

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

Я думаю, что это хуже (особенно сопровождаемый болезненным и пустым откатом):

DROP DATABASE;
ROLLBACK;

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

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

В регистрации на 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
);

Помогает (незначительно), если Вы знаете, что ПОСЛЕДОВАТЕЛЬНЫЙ тип в базах данных Informix - в основном, один из типов для генерации автоматически выделенных чисел последовательно.

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

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

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

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

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

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

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

Теперь босс ушел, но у меня нет времени для перезаписи его...

Мое собственное, которое далеко к долго для регистрации здесь - закрывающийся теперь на 3 500 строках

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

Бегун - это:

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

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

Я, конечно, осуществил рефакторинг с оставленным Выбором (datename (мм, getdate ()), 3)

МН / SQL (Oracle) сохранили proc, который отсортировал набор результатов с помощью Пузырьковой сортировки. Было обнаружено, когда меня и DBA попросили выяснить серьезную проблему производительности. Разработчик, Oracle "эксперт", работал над ним больше недели. Он объяснил с невозмутимым видом, что узнал о Пузырьковой сортировке в своем классе информатики. Алгоритм является наиболее часто используемым для иллюстрирования низкой производительности.

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

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

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

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

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

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

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

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

}

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

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

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

выберите * из *

Очень плохо.