Ошибки в разработке баз данных, сделанные разработчиками приложений [закрыто]

1. Не использование соответствующих индексов

Это - относительно легкое, но тем не менее это происходит все время. Внешние ключи должны иметь индексы на них. Если Вы используете поле в a WHERE у Вас должен (вероятно), быть индекс на нем. Такие индексы должны часто покрывать несколько столбцов на основе запросов, которые необходимо выполнить.

2. Не осуществление ссылочной целостности

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

Довольно распространено видеть этот отказ на базах данных MySQL. Я не полагаю, что MyISAM поддерживает его. InnoDB делает. Вы найдете людей, которые используют MyISAM или тех, которые используют InnoDB, но не используют его так или иначе.

Больше здесь:

• Как важный похожи на ограничения NOT NULL и FOREIGN KEY, если я буду всегда управлять своим входом базы данных с php?
• Внешние ключи действительно необходимы в проектировании баз данных?
• Внешние ключи действительно необходимы в проектировании баз данных?

3. Используя естественные а не суррогатные (технические) первичные ключи

Естественные ключи являются ключами на основе внешне значимых данных, которые (якобы) уникальны. Типичными примерами являются коды продуктов, двухбуквенные коды состояния (США), номера социального страхования и так далее. Суррогатные или технические первичные ключи - те, которые не имеют абсолютно никакого значения вне системы. Они изобретены просто для идентификации объекта и обычно автоувеличивают поля (SQL Server, MySQL, другие) или последовательности (прежде всего Oracle).

По-моему, необходимо всегда использовать суррогатные ключи. Эта проблема подошла в этих вопросах:

• Как Вам нравятся Ваши первичные ключи?
• Какова лучшая практика для первичных ключей в таблицах?
• Который формат первичного ключа был бы Вы использовать в этой ситуации.
• Суррогат по сравнению с естественными/бизнес-ключами
• У меня должно быть специализированное поле первичного ключа?

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

Помните, даже страны могут прекратить существование (например, Югославия).

4. Запись запрашивает, которые требуют DISTINCT работать

Вы часто видите это в ORM-сгенерированных запросах. Посмотрите на вывод журнала от, в спящем режиме, и Вы будете видеть, что все запросы начинаются:

SELECT DISTINCT ...

Это - что-то вроде ярлыка на обеспечение, Вы не возвращаете дублирующиеся строки и таким образом получаете дублирующиеся объекты. Вы будете иногда видеть, что люди делают это также. Если Вы видите его слишком много, это - реальный красный флаг. Не то, чтобы DISTINCT плохо или не имеет действительных приложений. Это делает (на обоих количествах), но это не суррогат или временная мера для записи корректных запросов.

От того, почему я ненавижу ОТЛИЧНЫЙ:

Где вещи начинают идти на спад, по-моему, когда разработчик создает существенный запрос, присоединяясь к таблицам вместе, и внезапно он понимает, что похоже, что он получает дубликат (или еще больше) строки и его непосредственный ответ... его "решение" этой "проблемы" состоит в том, чтобы бросить на ОТЛИЧНОЕ ключевое слово, и ПУФ все его проблемы уходят.

5. Одобрение агрегирования по соединениям

Другая частая ошибка разработчиками приложения базы данных не состоит в том, чтобы понять сколько еще дорогое агрегирование (т.е. GROUP BY пункт), может сравниться с соединениями.

Для давания Вам общее представление о том, насколько широко распространенный это я несколько раз писал по этой теме здесь и был downvoted много для него. Например:

От SQL-оператора - “присоединяются” по сравнению с “группой и наличием”:

Первый запрос:

SELECT userid
FROM userrole
WHERE roleid IN (1, 2, 3)
GROUP by userid
HAVING COUNT(1) = 3

Время запроса: 0,312 с

Второй запрос:

SELECT t1.userid
FROM userrole t1
JOIN userrole t2 ON t1.userid = t2.userid AND t2.roleid = 2
JOIN userrole t3 ON t2.userid = t3.userid AND t3.roleid = 3
AND t1.roleid = 1

Время запроса: 0,016 с

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

6. Не упрощение сложных запросов посредством представлений

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

• Сторона: люди и организации;
• Партийная Роль: вещи те стороны сделали, например, Сотрудник и Работодатель;
• Партийные Ролевые Отношения: как те роли, связанные друг с другом.

Пример:

• Ted является Человеком, будучи подтипом Стороны;
• У Ted есть много ролей, одна из которых является Сотрудником;
• Intel является организацией, будучи подтипом Стороны;
• Intel имеет много ролей, одна из которых является Работодателем;
• Intel нанимает Ted, подразумевая, что существуют отношения между их соответствующими ролями.

Таким образом, существует пять таблиц, соединенных для соединения Ted с его работодателем. Вы предполагаете, что все сотрудники являются Людьми (не организации) и обеспечивают это представление помощника:

CREATE VIEW vw_employee AS
SELECT p.title, p.given_names, p.surname, p.date_of_birth, p2.party_name employer_name
FROM person p
JOIN party py ON py.id = p.id
JOIN party_role child ON p.id = child.party_id
JOIN party_role_relationship prr ON child.id = prr.child_id AND prr.type = 'EMPLOYMENT'
JOIN party_role parent ON parent.id = prr.parent_id = parent.id
JOIN party p2 ON parent.party_id = p2.id

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

7. Не очистка входа

Это - огромное. Теперь мне нравится PHP, но если Вы не знаете то, что Вы делаете, действительно легко создать сайты, уязвимые для нападения. Ничто не подводит итог его лучше, чем история маленького Bobby Tables.

Данные, обеспеченные пользователем посредством URL, данных формы и cookie, нужно всегда рассматривать как враждебные и санированные. Удостоверьтесь, что Вы получаете то, что Вы ожидаете.

8. Не использование подготовленных операторов

Подготовленные операторы - при компиляции запроса минус данные, используемые во вставках, обновлениях и WHERE пункты и затем предоставляют это позже. Например:

SELECT * FROM users WHERE username = 'bob'

по сравнению с

SELECT * FROM users WHERE username = ?

или

SELECT * FROM users WHERE username = :username

в зависимости от Вашей платформы.

Я видел базы данных, поставленные на колени путем выполнения этого. В основном каждый раз, когда любая современная база данных встречается с новым запросом, она должна скомпилировать его. Если это встречается с запросом, это замечено прежде, Вы даете базе данных возможность кэшировать скомпилированный запрос и план выполнения. Путем выполнения запроса много Вы даете базе данных возможность понять это и оптимизировать соответственно (например, путем прикрепления скомпилированного запроса в памяти).

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

Подготовленные операторы также лучше защитят Вас от атак с использованием кода на SQL.

9. Не нормализация достаточно

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

Только на этой неделе я натыкался на некоторый код, где кто-то интегрировал массив и вставил его в единственное поле в базе данных. Нормализация, которая должна была бы рассматривать элемент того массива как отдельная строка в дочерней таблице (т.е. связь "один ко многим").

Это также предстало в Лучшем методе перед хранением списка идентификаторов пользователей:

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

Но отсутствие нормализации прибывает во многие формы.

Еще:

• Нормализация: Как далеко достаточно далеко?
• SQL дизайном: почему Вам нужна нормализация базы данных

10. Нормализация слишком много

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

Я когда-то работал над системой, которая имела огромную иерархию для клиентов, которые пошли что-то как:

Licensee ->  Dealer Group -> Company -> Practice -> ...

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

Главное, осторожная и продуманная денормализация может иметь огромные выигрыши в производительности, но необходимо быть действительно осторожными при выполнении этого.

Еще:

• Почему слишком много Нормализации Базы данных может быть Плохой Вещью
• Как далеко взять нормализацию в проектировании баз данных?
• Если не Нормализовать Вашу Базу данных SQL
• Возможно, нормализация не нормальна
• Родительский элемент всех дебатов нормализации базы данных по кодированию ужаса

11. Используя эксклюзивные дуги

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

От практического руководства по дизайну реляционной базы данных:

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

12. Не выполнение анализа производительности запросов вообще

Прагматизм безраздельно властвует, особенно в мире базы данных. Если Вы придерживаетесь принципов до такой степени, что они стали догмой затем, Вы вполне, вероятно, сделали ошибки. Возьмите пример агрегатных запросов сверху. Совокупная версия могла бы выглядеть "хорошей", но ее производительность является горестной. Сравнение производительности должно было закончить дебаты (но это не сделало), но главный: извержение таких неосведомленных представлений во-первых не осведомлено, даже опасно.

13. Чрезмерная зависимость от ОБЪЕДИНЕНИЯ ВСЕ и особенно конструкции ОБЪЕДИНЕНИЯ

ОБЪЕДИНЕНИЕ в терминах SQL просто связывает конгруэнтные наборы данных, означая, что у них есть тот же тип и число столбцов. Различие между ними - то, что ОБЪЕДИНЕНИЕ ВСЕ - простая конкатенация и должно быть предпочтено везде, где возможный, тогда как ОБЪЕДИНЕНИЕ неявно сделает ОТЛИЧНОЕ для удаления дублирующихся кортежей.

ОБЪЕДИНЕНИЯ, как ОТЛИЧНЫЙ, имеют свое место. Существуют действительные приложения. Но если Вы делаете многие из них, особенно в подзапросах, затем Вы, вероятно, делаете что-то не так. Это могло бы быть случаем плохой конструкции запроса или плохо разработанной модели данных, вынуждающей Вас сделать такие вещи.

ОБЪЕДИНЕНИЯ, особенно при использовании в соединениях или зависимых подзапросах могут нанести вред базе данных. Старайтесь избегать их, когда это возможно.

14. Используя ИЛИ условия в запросах

Это могло бы казаться безопасным. В конце концов, ANDs в порядке. ИЛИ должен быть в порядке слишком правильный? Неправильно. В основном И условие ограничивает набор данных, тогда как ИЛИ условие выращивает его, но не способом, который предоставляет себя оптимизации. Особенно, когда различное ИЛИ условия могли бы пересечь таким образом принуждение оптимизатора к эффективно к ОТЛИЧНОЙ операции на результате.

Плохо:

... WHERE a = 2 OR a = 5 OR a = 11

Лучше:

... WHERE a IN (2, 5, 11)

Теперь Ваш оптимизатор SQL может эффективно превратить первый запрос во второе. Но это не могло бы. Просто не делайте этого.

15. Не разработка их модели данных для кредитования себя высокопроизводительным решениям

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

До некоторой степени эта точка суммирует все более ранние, но это - больше назидательной истории, что выполнение вещей как оптимизация запросов часто делается сначала, когда это должно быть сделано второе. Прежде всего необходимо удостовериться, чтобы у Вас была хорошая модель данных прежде, чем попытаться оптимизировать производительность. Как сказанный Knuth:

Преждевременная оптимизация является корнем всего зла

16. Неправильное использование Транзакций базы данных

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

Идеально, самый простой способ достигнуть этого состоит в том, что все проектирование системы должно стремиться поддерживать все изменения данных через сингл, ВСТАВЛЯТЬ/ОБНОВЛЯТЬ/ОПЕРАТОРЫ УДАЛЕНИЯ. В этом случае никакая специальная обработка транзакции не необходима, как Ваш механизм базы данных должен сделать так автоматически.

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

• Начните Транзакцию перед первым оператором.
• Фиксируйте Транзакцию после последнего оператора.
• На любой ошибке, Откат Транзакция. И очень NB! Не забывайте пропускать/прерывать все операторы, которые следуют после ошибки.

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

17. Не понимание 'основанной на наборе' парадигмы

Язык SQL следует за определенной парадигмой, подходящей для определенных видов проблем. Различные определенные для поставщика расширения, несмотря на это, язык изо всех сил пытается иметь дело с проблемами, которые тривиальны в языках как Java, C#, Delphi и т.д.

Это отсутствие понимания проявляется несколькими способами.

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

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