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

Каковы распространенные ошибки разработки баз данных разработчиками приложений?

Ответ 1

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

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

2. Не применять ссылочную целостность

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

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

Подробнее здесь:

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

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

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

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

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

4. Написание запросов, требующих DISTINCT для работы

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

SELECT DISTINCT ...

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

Из Почему я ненавижу DISTINCT:

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

5. Благоприятное объединение по соединениям

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

Чтобы дать вам представление о том, насколько широко распространено это, я написал здесь эту тему несколько раз здесь и был занижен для этого много. Например:

Из SQL-оператора - "join" vs "group by and having" :

Первый запрос:
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. Это чрезвычайно мощный и гибкий метод моделирования, но может привести к многим объединениям. В этой модели были:

Сторона: люди и организации;
Роль партии: все, что делали эти стороны, например Employee and Employer;
Роль партии: как эти роли связаны друг с другом.

Пример:

Тед - это Человек, являющийся подтипом партии;
Тед имеет много ролей, один из которых - Employee;
Intel - это организация, являющаяся подтипом партии;
Intel имеет много ролей, одним из которых является Employer;
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, но если вы не знаете, что делаете, очень легко создать сайты, уязвимые для атаки. Ничто не суммирует его лучше, чем история маленьких таблиц Бобби.

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

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

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

SELECT * FROM users WHERE username = 'bob'

против

SELECT * FROM users WHERE username = ?

или

SELECT * FROM users WHERE username = :username

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

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

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

Подготовленные утверждения также лучше защитят вас от атак SQL-инъекций.

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

Нормализация базы данных - это в основном процесс оптимизации дизайна базы данных или организации ваших данных в таблицах.

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

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

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

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

Подробнее:

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

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

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

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

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

Более того, тщательная и продуманная денормализация может иметь огромные преимущества в производительности, но при этом вы должны быть очень осторожны при этом.

Подробнее:

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

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

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

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

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

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

13. Чрезмерная зависимость от UNION ALL и особенно конструкций UNION

UNION в терминах SQL просто объединяет конгруэнтные наборы данных, то есть они имеют один и тот же тип и количество столбцов. Разница между ними заключается в том, что UNION ALL является простой конкатенацией и должен быть предпочтительным там, где это возможно, тогда как UNION будет неявно делать DISTINCT для удаления дубликатов кортежей.

СОЮЗЫ, такие как DISTINCT, имеют свое место. Имеются действительные приложения. Но если вы обнаружите, что делаете много их, особенно в подзапросах, то вы, вероятно, делаете что-то неправильно. Это может быть причиной плохой структуры запросов или плохо разработанной модели данных, заставляющей вас делать такие вещи.

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

14. Использование условий OR в запросах

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

Плохо:

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

лучше:

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

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

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

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

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

Преждевременная оптимизация - это корень всех злых

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

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

В идеале самым простым способом добиться этого является то, что весь дизайн системы должен стремиться поддерживать все изменения данных с помощью отдельных инструкций INSERT/UPDATE/DELETE. В этом случае не требуется специальной обработки транзакций, так как ваш механизм базы данных должен делать это автоматически.

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

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

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

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

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

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

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

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

Ответ 2

Основные ошибки в базе данных и ошибки программирования, сделанные разработчиками

Дизайн и использование эгоистичных баз данных. Разработчики часто рассматривают базу данных как свое личное хранилище постоянных объектов, не учитывая потребности других заинтересованных сторон в данных. Это также относится к архитекторам приложений. Плохая конструкция базы данных и целостность данных затрудняют работу третьих сторон с данными и могут существенно увеличить затраты на жизненный цикл системы. Отчетность и MIS имеют тенденцию быть бедным двоюродным братом в дизайне приложений и выполняются только как запоздалая мысль.
Злоупотребление денормализованными данными. Преодоление денормализованных данных и попытка их поддержания в приложении - это рецепт проблем с целостностью данных. Используйте денормализацию экономно. Нежелание добавлять соединение к запросу не является оправданием для денормализации.
Испуган написания SQL. SQL - это не ракетостроение и на самом деле неплохо выполняет свою работу. Уровни отображения O/R неплохо выполняют 95% запросов, которые просты и хорошо вписываются в эту модель. Иногда SQL - лучший способ выполнить эту работу.
Догматическая политика "Нет хранимых процедур". Независимо от того, считаете ли вы, что хранимые процедуры являются злыми, такого рода догматическое отношение не имеет места в программном проекте.
Не понимаю дизайн базы данных. Нормализация - ваш друг, а не ракетостроение. Присоединение и мощность - довольно простые понятия - если вы участвуете в разработке приложений баз данных, на самом деле нет оправдания, чтобы не понимать их.

Ответ 3

Не использовать управление версиями в схеме базы данных
Работа непосредственно с живой базой данных
Не считывать и понимать более сложные концепции баз данных (индексы, кластерные индексы, ограничения, материализованные представления и т.д.).
Невозможно проверить масштабируемость... тестовые данные из 3 или 4 строк никогда не дадут вам реальной картины реального живого исполнения.

Ответ 4

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

Некоторые разработчики приложений видят хранимые процедуры как прямое расширение кода среднего уровня/интерфейса. Это, по-видимому, является общей чертой в разработчиках стека Microsoft (я один, но я вырос из него) и производит множество хранимых процедур, которые выполняют сложную бизнес-логику и обработку рабочего процесса. Это намного лучше сделано в другом месте.

Хранимые процедуры полезны там, где полностью доказано, что некоторые реальные технические факторы требуют их использования (например, производительность и безопасность). Например, сохранение агрегации/фильтрации больших наборов данных "близко к данным".

Недавно мне пришлось помогать поддерживать и улучшать большое настольное приложение Delphi, из которых 70% бизнес-логики и правил были реализованы в 1400 хранимых процедурах SQL Server (остальная часть в обработчиках событий пользовательского интерфейса). Это был кошмар, прежде всего из-за сложного внедрения эффективного модульного тестирования в TSQL, отсутствия инкапсуляции и слабых инструментов (отладчиков, редакторов).

Работая с командой Java в прошлом, я быстро обнаружил, что в этой среде часто происходит полная противоположность. Один архитектор Java однажды сказал мне: "База данных предназначена для данных, а не для кода".

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

Ответ 5

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

Ответ 6

Не использовать индексы.

Ответ 7

Плохая производительность, вызванная коррелированными подзапросами

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

Простите надуманный пример и синтаксис Oracle, но позвольте сказать, что вы хотели найти всех сотрудников, которые были наняты в любом из ваших магазинов, так как последний раз в магазине производилось менее 10 000 долларов продаж за день.

select e.first_name, e.last_name
from employee e
where e.start_date > 
        (select max(ds.transaction_date)
         from daily_sales ds
         where ds.store_id = e.store_id and
               ds.total < 10000)

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

select e.first_name, e.last_name
from employee e,
     (select ds.store_id,
             max(s.transaction_date) transaction_date
      from daily_sales ds
      where ds.total < 10000
      group by s.store_id) dsx
where e.store_id = dsx.store_id and
      e.start_date > dsx.transaction_date

В этом примере запрос в предложении from теперь представляет собой встроенный просмотр (опять-таки некоторый синтаксис для Oracle) и выполняется только один раз. В зависимости от вашей модели данных этот запрос, вероятно, будет выполняться намного быстрее. Он будет работать лучше, чем первый запрос по мере роста числа сотрудников. Первый запрос мог бы работать лучше, если бы было несколько сотрудников и много магазинов (и, возможно, у многих магазинов не было сотрудников), а таблица daily_sales была проиндексирована на store_id. Это не вероятный сценарий, но показывает, как коррелированный запрос может работать лучше, чем альтернатива.

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

Ответ 8

По моему опыту:
Не взаимодействовать с опытными администраторами баз данных.

Ответ 9

Использование Access вместо "реальной" базы данных. Существует множество больших и даже бесплатных баз данных, таких как SQL Express, MySQL и SQLite, которые будут работать и масштабироваться намного лучше. Приложения часто должны масштабироваться неожиданными способами.

Ответ 10

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

Ответ 11

Я хотел бы добавить: Благодарим "Элегантный" код за высокопроизводительный код. Код, который лучше всего работает с базами данных, часто уродлив для глаз разработчика приложений.

Полагая, что ерунда о преждевременной оптимизации. Базы данных должны учитывать производительность в исходном проекте и в любой последующей разработке. Производительность составляет 50% от дизайна базы данных (40% - это целостность данных, а последние 10% - безопасность), на мой взгляд. Базы данных, которые не построены снизу вверх для выполнения, будут работать плохо, как только реальные пользователи и реальный трафик будут помещены в базу данных. Преждевременная оптимизация не означает никакой оптимизации! Это не значит, что вы должны писать код, который почти всегда будет выполняться плохо, потому что вам будет легче (например, курсоры, которые никогда не должны допускаться в производственной базе данных, если только все остальные не сработали). Это означает, что вам не нужно смотреть на то, чтобы выжать это последнее немного производительности, пока вам не понадобится. Много известно о том, что будет лучше работать в базах данных, чтобы игнорировать это в дизайне и разработке в лучшем случае близоруко.

Ответ 12

Использование Excel для хранения (огромных объемов) данных.

Я видел, что компании занимают тысячи строк и используют несколько листов (из-за ограничения строки 65535 на предыдущие версии Excel).

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

Ответ 13

Не использовать параметризованные запросы. Они очень удобны в остановке SQL Injection.

Это конкретный пример не дезинфекции входных данных, упомянутых в другом ответе.

Ответ 14

Для баз данных на базе SQL:

Не использовать преимущества CLUSTERED INDEXES или выбрать неправильный столбец (столбцы) для CLUSTER.
Не использовать SERIAL (autonumber) тип данных как PRIMARY KEY, чтобы присоединиться к FOREIGN KEY (INT) в отношении родительского/дочернего стола.
НЕ ОБНОВЛЕНИЕ СТАТИСТИКИ на таблице, когда многие записи были ВСТАВЛЕНЫ или УДАЛЕНЫ.
Не реорганизуйте (то есть выгружайте, свергайте, воссоздавайте, загружайте и переиндексируйте) таблицы, когда многие строки были вставлены или удалены (некоторые из них физически сохраняют удаленные строки в таблице с флагом удаления.)
Не использовать FRAGMENT ON EXPRESSION (если поддерживается) на больших таблицах, которые имеют высокую скорость транзакций.
Выбор неправильного типа данных для столбца!
Невозможно выбрать правильное имя столбца.
Не добавлять новые столбцы в конце таблицы.
Не создавать правильные индексы для поддержки часто используемых запросов.
создание индексов в столбцах с несколькими возможными значениями и создание ненужных индексов.
... еще предстоит добавить.

Ответ 15

Я ненавижу, когда разработчики используют вложенные операторы select или даже функции, возвращающие результат выражения select внутри части запроса SELECT.

Я действительно удивлен, что я не вижу этого нигде здесь, возможно, я его не заметил, хотя @adam имеет аналогичную проблему.

Пример:

SELECT
    (SELECT TOP 1 SomeValue FROM SomeTable WHERE SomeDate = c.Date ORDER BY SomeValue desc) As FirstVal
    ,(SELECT OtherValue FROM SomeOtherTable WHERE SomeOtherCriteria = c.Criteria) As SecondVal
FROM
    MyTable c

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

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

Лучшим (не обязательно идеальным) примером может быть что-то вроде:

SELECT
     s.SomeValue As FirstVal
    ,o.OtherValue As SecondVal
FROM
    MyTable c
    LEFT JOIN (
        SELECT SomeDate, MAX(SomeValue) as SomeValue
        FROM SomeTable 
        GROUP BY SomeDate
     ) s ON c.Date = s.SomeDate
    LEFT JOIN SomeOtherTable o ON c.Criteria = o.SomeOtherCriteria

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

Ответ 16

Не нужно делать резервную копию, прежде чем исправлять некоторые проблемы в производственной базе данных.
Использование DDL-команд для сохраненных объектов (например, таблиц, представлений) в хранимых процедурах.
Страх использования хранимой процедуры или страх использования запросов ORM, где это более эффективно/целесообразно использовать.
Не обращая внимания на использование профайлер базы данных, который может сказать вам точно, что ваш ORM запрос преобразовывается в конце концов, и, следовательно, проверить логику или даже для отладки, когда не используется ORM.

Ответ 17

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

Ответ 18

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

Ответ 19

1 - Ненужно использовать функцию в значении в предложении where, не используя результат этого индекса.

Пример:

where to_char(someDate,'YYYYMMDD') between :fromDate and :toDate

вместо

where someDate >= to_date(:fromDate,'YYYYMMDD') and someDate < to_date(:toDate,'YYYYMMDD')+1

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

2 - Не добавлять контрольные ограничения для обеспечения достоверности данных. Ограничения могут использоваться оптимизатором запросов, и они ДЕЙСТВИТЕЛЬНО помогают гарантировать, что вы можете доверять своим инвариантам. Там просто нет причин не использовать их.

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

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

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

Ответ 20

Отключение ORM, например Hibernate, из-за таких причин, как "слишком магическая" или "не в моей базе данных".
Опираясь слишком сильно на ORM, как Hibernate, и пытайтесь обучить его там, где это не подходит.

Ответ 21

Это было сказано ранее, но: индексы, индексы, индексы. Я видел так много случаев плохо работающих корпоративных веб-приложений, которые были исправлены, просто сделав небольшое профилирование (чтобы увидеть, какие таблицы сильно пострадали), а затем добавив индекс в эти таблицы. Это даже не требует большого количества знаний о написании SQL, и выигрыш огромен.

Избегайте дублирования данных, таких как чума. Некоторые люди выступают за то, что небольшое дублирование не повредит и улучшит производительность. Эй, я не говорю, что вы должны пытать свою схему в Третьей нормальной форме, пока она не станет настолько абстрактной, что даже администратор не знает, что происходит. Просто имейте в виду, что всякий раз, когда вы дублируете набор имен, или почтовые индексы, или коды доставки, копии будут выходить из строя друг с другом в конце концов. Это произойдет. И тогда вы будете пинать себя, когда вы запускаете еженедельное обслуживание script.

И, наконец, используйте четкое, последовательное, интуитивное соглашение об именах. Точно так же, как хорошо написанная часть кода должна быть удобочитаемой, хорошая SQL-схема или запрос должны быть читаемыми и фактически сообщать вам, что она делает, даже без комментариев. Вы будете благодарить себя через шесть месяцев, когда вам придется обслуживать столы. "SELECT account_number, billing_date FROM national_accounts" бесконечно проще работать, чем "SELECT ACCNTNBR, BILLDAT FROM NTNLACCTS".

Ответ 22

Не выполняется соответствующий запрос SELECT перед запуском запроса DELETE (особенно в производственных базах данных)!

Ответ 23

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

Ответ 24

a) Значения запроса жесткого кодирования в строке b) Ввод кода запроса базы данных в действие "OnButtonPress" в приложении Windows Forms

Я видел оба.

Ответ 25

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

Ответ 26

Мысль о том, что они являются администраторами баз данных и модельерами/дизайнерами данных, когда у них нет формальной идеологической обработки в этих областях.
Думая, что их проект не требует DBA, потому что все это просто/тривиально.
Невозможно правильно распознать работу, которая должна быть выполнена в базе данных, и работу, которая должна быть выполнена в приложении.
Не выполняется проверка резервных копий или резервное копирование.
Встраивание исходного кода SQL в свой код.

Ответ 27

Вот ссылка на видео под названием Классические ошибки разработки баз данных и пять способов их преодоления Скоттом Уолцем

Ответ 28

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

Ответ 29

Не понимаю, как СУБД работает под капотом.

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

В частности:

Знаете ли вы, что такое кластерный индекс? Вы думали об этом, когда разрабатывали схему?
Вы знаете, как правильно использовать индексы? Как повторно использовать индекс? Знаете ли вы, что такое Индекс покрытия?
Итак, у вас есть индексы. Насколько велика одна строка в вашем индексе? Насколько большой будет индекс, когда у вас много данных? Будет ли это легко вписываться в память? Если это будет бесполезно, как индекс.
Вы когда-нибудь использовали EXPLAIN в MySQL? Отлично. Теперь будьте честны с самим собой: вы поняли даже половину того, что видели? Нет, вы, вероятно, этого не сделали. Исправьте это.
Вы понимаете кеш запросов? Вы знаете, что делает запрос недоступным?
Используете ли вы MyISAM? Если вам нужен полнотекстовый поиск, MyISAM все равно. Используйте Сфинкс. Затем переключитесь на Inno.

Ответ 30

Использование ORM для массовых обновлений
Выбор большего количества данных, чем необходимо. Опять же, обычно это делается при использовании ORM
Запуск sqls в цикле.
Отсутствие хороших тестовых данных и замедление производительности только для живых данных.