Які найпоширеніші антидіаграми 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, коли буде діяти цикл, який змінює цикл.

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. Цей план буде використовуватися незалежно від значення параметрів. Це призводить до переривчастої низької продуктивності. Набагато краще написати два запити (один запит на передбачуваний план виконання).

• Людські поле для читання паролів , наприклад, egad. Пояснення самостійно.

• Використовуючи LIKE проти індексованих стовпців, і я майже спокусився сказати LIKE взагалі.

• Переробка значень ПК, створених SQL.

• Сюрприз ще ніхто не згадав про боговий стіл . Ніщо не говорить "органічно", як 100 стовпців бітових прапорів, великих рядків і цілих чисел.

• Тоді є шаблон "Я сумую за файлами .

• А для MS SQL-сервера взагалі використання курсорів . Є кращий спосіб виконати будь-яке завдання курсору.

Відредаговано, тому що їх так багато!

Не потрібно копати глибоко для цього: Не використовуючи підготовлені заяви.

Використання безглуздих псевдонімів таблиці:

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. Cleartext паролі

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

Зазвичай ця таблиця пошуку виглядає приблизно так:

Ідентифікатор INT,
Ім'я NVARCHAR (132),
IntValue1 INT,
IntValue2 INT,
CharValue1 NVARCHAR (255),
CharValue2 NVARCHAR (255),
Дата1 ДАТЕТИ,
Дата2 ДАТЕТИМ

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

Мені найбільше не подобаються такі

1. Використання пробілів під час створення таблиць, проростів тощо. Я добре вживаю з CamelCase або under_scores та однини чи множини та UPPERCASE або малі регістри, але маю посилатися на таблицю чи стовпчик [з пробілами], особливо якщо [це нерозмірно розміщено] (так, Я наткнувся на це) насправді мене дратує.

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

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

4. Доступ. Чи може програма бути анти-зразком? У мене працює SQL Server, але низка людей користується доступом через її доступність, «простоту використання» та «дружелюбність» для нетехнічних користувачів. Тут занадто багато, щоб зайнятися, але якщо ви були в подібному середовищі, знаєте.

використовуйте SP як префікс назви процедури зберігання, тому що він спочатку шукатиме в місці системних процедур, а не на власні.

Надмірне використання тимчасових таблиць і курсорів.

Для зберігання значень часу слід використовувати лише часовий пояс UTC. Місцевий час не слід використовувати.

використовуючи @@ IDENTITY замість SCOPE_IDENTITY ()

Цитується з цієї відповіді :

• @@ ІДЕНТИЧНІСТЬ повертає останнє значення ідентичності, створене для будь-якої таблиці в поточному сеансі, за всіма областями. Ви повинні бути обережними тут, оскільки це в різних сферах. Ви можете отримати значення за допомогою тригера замість поточного оператора.
• SCOPE_IDENTITY повертає останнє значення ідентичності, створене для будь-якої таблиці в поточному сеансі та поточній області. Взагалі те, що ви хочете використовувати.
• IDENT_CURRENT повертає останнє значення ідентичності, створене для конкретної таблиці в будь-якому сеансі та будь-якій області. Це дозволяє вам вказати, з якої таблиці ви хочете значення, якщо два вище не дуже потрібні (дуже рідко). Ви можете використовувати це, якщо хочете отримати поточне значення IDENTITY для таблиці, в яку ви не вставили запис.

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

select some_column, ...
from some_table
group by 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 () та розділів.

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

Див. O'Reilly SQL Cookbook Додаток A для отримання хорошого огляду функцій вікон.

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

Це стосується:

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

І будь-які тести на нетипові або недостатньо дані не враховуються. Якщо це збережена процедура, покладіть тестову заяву в коментар і збережіть її з результатами. В іншому випадку введіть це в коментар до коду з результатами.

Зловживання тимчасовим столом.

Конкретно такі речі:

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.

Дуже серйозно вважати, що тригери - це бази даних, як обробники подій для OOP. Існує таке уявлення, що будь-яку стару логіку можна ввести в тригери, щоб її зняти, коли транзакція (подія) відбувається на столі.

Неправда. Одна з великих відмінностей полягає в тому, що тригери синхронні - з помстою, оскільки вони синхронні для заданої операції, а не для рядкової операції. З боку ООП - навпаки - події є ефективним способом реалізації асинхронних транзакцій.

Збережені процедури або функції без коментарів ...

1) Я не знаю, що це "офіційний" анти-шаблон, але мені не подобається і намагаюся уникати рядкових літералів як магічних значень у стовпці бази даних.

Приклад таблиці "image" таблиці "MediaWiki":

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, коли платформи дозволяють. Якщо у вашому магазині є DBA, ви, ймовірно, не можете змінити погляди, але всі ваші погляди будуть застарілими або непотрібними в такому випадку.

• Параметр! Параметр - Чи може запит мати кілька цілей? Можливо, але наступна людина, яка прочитає це, не дізнається до глибокої медитації. Навіть якщо вони вам зараз не потрібні, швидше за все, ви хочете, навіть якщо це "просто" налагодження. Додавання параметрів скорочує час технічного обслуговування та зберігає сухість. Якщо у вас є пункт де, ви повинні мати параметри.

• Справа про відсутність СПРАВИ -

  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, мають звичку використовувати тимчасові таблиці. Просто використовуйте вкладені оператори вибору.

Розробники, які пишуть запити, не маючи гарного уявлення про те, що робить SQL-додатки (як окремі запити, так і багатокористувацькі системи) швидкими або повільними. Сюди входить і незнання про:

• фізичні стратегії мінімізації вводу / виводу, враховуючи, що вузьким місцем у більшості запитів є введення / виведення, а не процесор
• перф-вплив різних видів фізичного доступу до пам’яті (наприклад, багато послідовних вводу-виводу будуть швидшими, ніж безліч малих випадкових вводу-виводу, хоча менше, якщо ваш фізичний накопичувач - це SSD!)
• як вручну налаштувати запит, якщо СУБД створює поганий план запитів
• як діагностувати низьку продуктивність бази даних, як "налагодити" повільний запит і як прочитати план запитів (або ПОЯСНІТЬ, залежно від обраної вами СУБД)
• стратегії блокування для оптимізації пропускної здатності та уникнення тупикових ситуацій у багатокористувацьких додатках
• важливість пакетної та інших хитрощів для обробки наборів даних
• дизайн таблиць та індексів для найкращого врівноваження простору та продуктивності (наприклад, охоплення індексів, збереження індексів невеликими, де це можливо, зменшення типів даних до мінімально необхідного розміру тощо)

Використання SQL як прославленого пакету ISAM (індексований метод послідовного доступу). Зокрема, вкладення курсорів замість комбінування заяв 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, оскільки внутрішній цикл закінчується. Це може бути фактором у звітах про перерви контролю.

Крім того, сортування в додатку зазвичай ні-ні.

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