Каковы наиболее распространенные анти-паттерны SQL? [закрыто]

Все мы, кто работает с реляционными базами данных, узнали (или изучают), что SQL отличается. Чтобы добиться желаемых результатов и сделать это эффективно, требуется утомительный процесс, отчасти характеризуемый изучением незнакомых парадигм и обнаружением того, что некоторые из наших наиболее знакомых шаблонов программирования здесь не работают. Какие общие антипаттерны вы видели (или сами совершали)?

Меня постоянно разочаровывает тенденция большинства программистов смешивать свою UI-логику на уровне доступа к данным:

SELECT
    FirstName + ' ' + LastName as "Full Name",
    case UserRole
        when 2 then "Admin"
        when 1 then "Moderator"
        else "User"
    end as "User's Role",
    case SignedIn
        when 0 then "Logged in"
        else "Logged out"
    end as "User signed in?",
    Convert(varchar(100), LastSignOn, 101) as "Last Sign On",
    DateDiff('d', LastSignOn, getDate()) as "Days since last sign on",
    AddrLine1 + ' ' + AddrLine2 + ' ' + AddrLine3 + ' ' +
        City + ', ' + State + ' ' + Zip as "Address",
    'XXX-XX-' + Substring(
        Convert(varchar(9), SSN), 6, 4) as "Social Security #"
FROM Users

Обычно программисты делают это, потому что они намерены привязать свой набор данных непосредственно к сетке, и просто удобно иметь формат сервера SQL Server, а не формат на клиенте.

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

Вот мой топ 3.

Номер 1. Невозможность указать список полей. (Изменить: для предотвращения путаницы: это правило производственного кода. Оно не применяется к одноразовым сценариям анализа - если я не автор.)

SELECT *
Insert Into blah SELECT *

должно быть

SELECT fieldlist
Insert Into blah (fieldlist) SELECT fieldlist

Номер 2. Использование курсора и цикла while, когда будет использоваться цикл while с переменной цикла.

DECLARE @LoopVar int

SET @LoopVar = (SELECT MIN(TheKey) FROM TheTable)
WHILE @LoopVar is not null
BEGIN
  -- Do Stuff with current value of @LoopVar
  ...
  --Ok, done, now get the next value
  SET @LoopVar = (SELECT MIN(TheKey) FROM TheTable
    WHERE @LoopVar < TheKey)
END

Номер 3. DateLogic через строковые типы.

--Trim the time
Convert(Convert(theDate, varchar(10), 121), datetime)

Должно быть

--Trim the time
DateAdd(dd, DateDiff(dd, 0, theDate), 0)

Я видел недавний всплеск «Один запрос лучше, чем два, верно?»

SELECT *
FROM blah
WHERE (blah.Name = @name OR @name is null)
  AND (blah.Purpose = @Purpose OR @Purpose is null)

Этот запрос требует двух или трех разных планов выполнения в зависимости от значений параметров. Только один план выполнения генерируется и помещается в кеш для этого текста SQL. Этот план будет использоваться независимо от значения параметров. Это приводит к периодической низкой производительности. Гораздо лучше написать два запроса (по одному на каждый план выполнения).

• Удобочитаемые поля пароля , например. Самоочевидно.

• Использование LIKE против индексированных столбцов, и я почти испытываю желание просто сказать LIKE в целом.

• Переработка сгенерированных SQL значений PK.

• Сюрприз, никто еще не упомянул бог-таблицу . Ничто не говорит «органично», как 100 столбцов битовых флагов, больших строк и целых чисел.

• Затем есть шаблон «Я скучаю по INI-файлам» : хранение CSV- файлов , строк с разделителями каналов или других необходимых для анализа данных в больших текстовых полях.

• А для MS SQL server использование курсоров вообще . Есть лучший способ сделать любую заданную задачу курсора.

Отредактировано потому что так много!

Не нужно копать для этого: не использовать подготовленные заявления.

Используя бессмысленные псевдонимы таблиц:

from employee t1,
department t2,
job t3,
...

Делает чтение большого оператора SQL намного сложнее, чем нужно

var query = "select COUNT(*) from Users where UserName = '" 
            + tbUser.Text 
            + "' and Password = '" 
            + tbPassword.Text +"'";

1. Слепо доверяющий пользовательский ввод
2. Не использует параметризованные запросы
3. Открытые пароли

Мои ошибки - это таблицы доступа из 450 столбцов, которые были собраны 8-летним сыном лучшего друга-управляющего собакой-распорядителем и изворотливой справочной таблицы, которая существует только потому, что кто-то не знает, как правильно нормализовать структуру данных.

Как правило, эта таблица соответствия выглядит следующим образом:

ID INT,
Имя NVARCHAR (132),
IntValue1 INT,
IntValue2 INT,
CharValue1 NVARCHAR (255),
CharValue2 NVARCHAR (255),
Date1 DATETIME,
Дата2 Дата

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

Больше всего мне не нравятся

1. Использование пробелов при создании таблиц, sprocs и т. Д. Я в порядке с CamelCase или under_scores, а также в единственном или множественном числе и UPPERCASE или в нижнем регистре, но при этом необходимо ссылаться на таблицу или столбец [с пробелами], особенно если [это странно разделено] (да, Я столкнулся с этим) действительно меня раздражает.

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

3. Злоупотребление либо представлениями, либо курсорами. Представления имеют цель, но когда каждая таблица упакована в представление, это слишком много. Мне приходилось использовать курсоры несколько раз, но обычно вы можете использовать другие механизмы для этого.

4. Доступ. Может ли программа быть анти-паттерном? У меня есть SQL Server в моей работе, но многие люди используют доступ из-за его доступности, «простоты использования» и «дружелюбия» для нетехнических пользователей. Слишком много здесь, чтобы вдаваться, но если вы были в подобной среде, вы знаете.

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

Чрезмерное использование временных таблиц и курсоров.

Для хранения значений времени следует использовать только часовой пояс UTC. Местное время не должно использоваться.

используя @@ IDENTITY вместо SCOPE_IDENTITY ()

Цитируется из этого ответа :

• @@ IDENTITY возвращает последнее значение идентификатора, сгенерированное для любой таблицы в текущем сеансе, во всех областях. Вы должны быть осторожны здесь, так как это выходит за рамки. Вы можете получить значение из триггера вместо текущего оператора.
• SCOPE_IDENTITY возвращает последнее значение идентификатора, сгенерированное для любой таблицы в текущем сеансе и текущей области. Вообще то, что вы хотите использовать.
• IDENT_CURRENT возвращает последнее значение идентификатора, сгенерированное для конкретной таблицы в любом сеансе и любой области видимости. Это позволяет вам указать, из какой таблицы вы хотите получить значение, в случае, если два приведенных выше не совсем то, что вам нужно (очень редко). Вы можете использовать это, если хотите получить текущее значение IDENTITY для таблицы, в которую вы не вставили запись.

Повторное использование «мертвого» поля для чего-то, для чего оно не было предназначено (например, хранение пользовательских данных в поле «Факс») - хотя это очень заманчиво в качестве быстрого решения!

select some_column, ...
from some_table
group by some_column

и предполагая, что результат будет отсортирован по some_column. Я видел это немного с Sybase, где предположение верно (пока).

SELECT FirstName + ' ' + LastName as "Full Name", case UserRole when 2 then "Admin" when 1 then "Moderator" else "User" end as "User's Role", case SignedIn when 0 then "Logged in" else "Logged out" end as "User signed in?", Convert(varchar(100), LastSignOn, 101) as "Last Sign On", DateDiff('d', LastSignOn, getDate()) as "Days since last sign on", AddrLine1 + ' ' + AddrLine2 + ' ' + AddrLine3 + ' ' + City + ', ' + State + ' ' + Zip as "Address", 'XXX-XX-' + Substring(Convert(varchar(9), SSN), 6, 4) as "Social Security #" FROM Users

Или втиснуть все в одну строчку.

• FROM TableA, TableB WHEREСинтаксис JOINS вместоFROM TableA INNER JOIN TableB ON

• Предположение, что запрос будет возвращен, отсортировано определенным образом, без добавления предложения ORDER BY, просто потому, что так оно и было во время тестирования в инструменте запросов.

Изучать SQL в первые шесть месяцев своей карьеры и никогда больше ничего не изучать в течение следующих 10 лет. В частности, не учиться или эффективно использовать оконные / аналитические функции SQL. В частности использование over () и разделение по.

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

См. Приложение A O'Reilly SQL Cookbook для хорошего обзора оконных функций.

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

Это относится, когда:

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

И любые тесты, выполненные против нетипичных или недостаточных данных, не учитываются. Если это хранимая процедура, поместите оператор test в комментарий и сохраните его с результатами. В противном случае поместите это в комментарий в коде с результатами.

Временная таблица злоупотреблений.

Именно такие вещи:

SELECT personid, firstname, lastname, age
INTO #tmpPeople
FROM People
WHERE lastname like 's%'

DELETE FROM #tmpPeople
WHERE firstname = 'John'

DELETE FROM #tmpPeople
WHERE firstname = 'Jon'

DELETE FROM #tmpPeople
WHERE age > 35

UPDATE People
SET firstname = 'Fred'
WHERE personid IN (SELECT personid from #tmpPeople)

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

И да, я видел страницы кода в этой форме в производственных БД.

Противоположный взгляд: чрезмерная одержимость нормализацией.

Большинство систем SQL / RBDB предоставляют множество функций (транзакции, репликация), которые весьма полезны даже для ненормализованных данных. Дисковое пространство дешево, и иногда может быть проще (более простой код, более быстрое время разработки) манипулировать / фильтровать / искать извлеченные данные, чем написать схему 1NF и справиться со всеми возникающими в ней трудностями (сложные объединения, неприятные подвыборы). , и т.д).

Я обнаружил, что чрезмерно нормализованные системы часто преждевременно оптимизируются, особенно на ранних стадиях разработки.

(больше мыслей об этом ... http://writeonly.wordpress.com/2008/12/05/simple-object-db-using-json-and-python-sqlite/ )

Я просто собрал это, основываясь на некоторых ответах SQL здесь, на SO.

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

Не правда. Одно из больших отличий состоит в том, что триггеры синхронны - с удвоенной силой, потому что они синхронны в операции набора, а не в операции строки. Со стороны ООП события с точностью до наоборот - эффективный способ реализации асинхронных транзакций.

Хранимые процедуры или функции без каких-либо комментариев ...

1) Я не знаю, что это «официальный» анти-шаблон, но мне не нравится и стараюсь избегать строковых литералов как магических значений в столбце базы данных.

Пример из таблицы MediaWiki 'image':

img_media_type ENUM("UNKNOWN", "BITMAP", "DRAWING", "AUDIO", "VIDEO", 
    "MULTIMEDIA", "OFFICE", "TEXT", "EXECUTABLE", "ARCHIVE") default NULL,
img_major_mime ENUM("unknown", "application", "audio", "image", "text", 
    "video", "message", "model", "multipart") NOT NULL default "unknown",

(Я просто замечаю другой корпус, еще одну вещь, чтобы избежать)

Я разрабатываю такие случаи, как поиск int в таблицах ImageMediaType и ImageMajorMime с первичными ключами int.

2) преобразование даты / строки, основанное на определенных настройках NLS

CONVERT(NVARCHAR, GETDATE())

без идентификатора формата

Идентичные подзапросы в запросе.

• Измененное представление - представление, которое изменяется слишком часто и без уведомления или причины. Изменение будет замечено в самое неподходящее время или, что еще хуже, будет ошибочным и никогда не будет замечено. Возможно, ваше приложение сломается, потому что кто-то придумал более подходящее название для этого столбца. Как правило, представления должны расширять полезность базовых таблиц при сохранении договора с потребителями. Исправляйте проблемы, но не добавляйте функции или не изменяйте поведение, для этого создайте новый вид. Для смягчения не делитесь представлениями с другими проектами и используйте CTE, когда платформы позволяют. Если в вашем магазине есть администратор базы данных, вы, вероятно, не сможете изменить представления, но в этом случае все ваши представления будут устаревшими и бесполезными.

• Параметр! - может ли запрос иметь более одной цели? Возможно, но следующий человек, который читает это, не узнает до глубокой медитации. Даже если они вам сейчас не нужны, скорее всего, вы это сделаете, даже если это «просто» для отладки. Добавление параметров сокращает время обслуживания и делает вещи СУХИМЫМИ. Если у вас есть предложение where, у вас должны быть параметры.

• Дело без дела -

  SELECT  
  CASE @problem  
    WHEN 'Need to replace column A with this medium to large collection of strings hanging out in my code.'  
      THEN 'Create a table for lookup and add to your from clause.'  
    WHEN 'Scrubbing values in the result set based on some business rules.'  
      THEN 'Fix the data in the database'  
    WHEN 'Formating dates or numbers.'   
      THEN 'Apply formating in the presentation layer.'  
    WHEN 'Createing a cross tab'  
      THEN 'Good, but in reporting you should probably be using cross tab, matrix or pivot templates'   
  ELSE 'You probably found another case for no CASE but now I have to edit my code instead of enriching the data...' END  

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

• Использование курсоров вместо выражения на основе набора. Я предполагаю, что это происходит часто, когда программист думает правильно.

• Использование коррелированных подзапросов, когда объединение с производной таблицей может выполнить эту работу.

Помещение вещей во временные таблицы, особенно люди, которые переходят с SQL Server на Oracle, имеют привычку чрезмерно использовать временные таблицы. Просто используйте вложенные операторы select.

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

• стратегии минимизации физического ввода / вывода, учитывая, что узким местом большинства запросов является ввод / вывод, а не процессор
• Влияние различных видов физического доступа к хранилищу (например, большое количество последовательных операций ввода-вывода будет быстрее, чем множество небольших случайных операций ввода-вывода, хотя и меньше, если физическое хранилище - это SSD!)
• как вручную настроить запрос, если СУБД выдает плохой план запроса
• как диагностировать низкую производительность базы данных, как «отладить» медленный запрос и как прочитать план запроса (или EXPLAIN, в зависимости от выбранной вами СУБД)
• стратегии блокировки для оптимизации пропускной способности и предотвращения тупиков в многопользовательских приложениях
• важность пакетирования и других приемов для обработки наборов данных
• дизайн таблиц и индексов для наилучшего баланса между пространством и производительностью (например, покрытие индексов, сохранение индексов небольшим, где это возможно, сокращение типов данных до минимально необходимого размера и т. д.)

Использование SQL в качестве прославленного пакета ISAM (Indexed Sequential Access Method). В частности, вложенные курсоры вместо объединения операторов SQL в один, хотя и больший, оператор. Это также считается «злоупотреблением оптимизатором», поскольку на самом деле оптимизатор мало что может сделать. Это может быть объединено с неподготовленными заявлениями для максимальной неэффективности:

DECLARE c1 CURSOR FOR SELECT Col1, Col2, Col3 FROM Table1

FOREACH c1 INTO a.col1, a.col2, a.col3
    DECLARE c2 CURSOR FOR
        SELECT Item1, Item2, Item3
            FROM Table2
            WHERE Table2.Item1 = a.col2
    FOREACH c2 INTO b.item1, b.item2, b.item3
        ...process data from records a and b...
    END FOREACH
END FOREACH

Правильное решение (почти всегда) - объединить два оператора SELECT в один:

DECLARE c1 CURSOR FOR
    SELECT Col1, Col2, Col3, Item1, Item2, Item3
        FROM Table1, Table2
        WHERE Table2.Item1 = Table1.Col2
        -- ORDER BY Table1.Col1, Table2.Item1

FOREACH c1 INTO a.col1, a.col2, a.col3, b.item1, b.item2, b.item3
    ...process data from records a and b...
END FOREACH

Единственное преимущество версии с двойным циклом состоит в том, что вы можете легко определить разрывы между значениями в таблице 1, поскольку внутренний цикл заканчивается. Это может быть фактором в отчетах о нарушениях управления.

Кроме того, сортировка в приложении, как правило, нет-нет.

Использование первичных ключей в качестве суррогата для адресов записей и использование внешних ключей в качестве суррогата для указателей, встроенных в записи.