Независимо от того, работаете ли вы с базой данных, содержащей сотни записей или миллионы записей, правильный дизайн базы данных всегда важен. Это не только облегчит получение информации, но и упростит расширение базы данных в будущем. К сожалению, легко попасть в несколько ловушек, которые могут осложнить ситуацию в будущем.
Есть целые книги, написанные на предмет нормализации базы данных, но если вы просто избегаете распространенных ошибок, показанных здесь, вы будете на правильном пути к хорошему дизайну базы данных.
Ошибка базы данных №1: Повторение полей в таблице
Основное правило для хорошего проектирования базы данных - распознать повторяющиеся данные и поместить эти повторяющиеся столбцы в свою собственную таблицу. Повторяющиеся поля в таблице являются общими для тех, кто пришел из мира электронных таблиц, но в то время как таблицы, как правило, плоские по дизайну, базы данных должны быть реляционными. Это похоже на переход от 2D к 3D.
К счастью, повторяющиеся поля обычно легко обнаружить. Просто взгляните на эту таблицу:
| Номер заказа | Product1 | Product2 | Product3 |
| 1 | Плюшевые мишки | Мармеладки | |
| 2 | Мармеладки |
Что происходит, когда заказ содержит четыре продукта? Нам нужно добавить еще одно поле в таблицу для поддержки более трех продуктов. И если мы создали клиентское приложение вокруг таблицы, чтобы помочь нам вводить данные, нам может потребоваться изменить его с новым полем продукта. И как мы находим все заказы с Jellybeans в заказе? Мы будем вынуждены запрашивать каждое поле продукта в таблице с выражением SQL, которое может выглядеть так: SELECT * FROM Products WHERE Product1 = 'Jelly Beans' ИЛИ Product2 = 'Jelly Beans' ИЛИ Product3 = 'Jelly Beans'.
Вместо того, чтобы иметь единую таблицу, которая объединяет всю информацию, мы должны иметь три таблицы, каждая из которых содержит отдельную информацию. В этом примере нам нужна таблица Orders с информацией о самом заказе, таблице продуктов со всеми нашими продуктами и планшетом ProductOrders, который связывает продукты с заказом.
| Номер заказа | Пользовательский ИД | Дата заказа | Всего |
| 1 | 7 | 1/24/17 | 19.99 |
| 2 | 9 | 1/25/17 | 24.99 |
| Код товара | Товар | подсчитывать |
| 1 | Плюшевые мишки | 1 |
| 2 | Мармеладки | 100 |
| ProductOrderID | Код товара | Номер заказа |
| 101 | 1 | 1 |
| 102 | 2 | 1 |
Обратите внимание, как каждая таблица имеет свое собственное уникальное поле идентификатора. Это первичный ключ. Мы связываем таблицы, используя значение первичного ключа в качестве внешнего ключа в другой таблице. Подробнее о первичных ключах и внешних ключах.
Ошибка базы данных №2: вставка таблицы в таблицу
Это еще одна распространенная ошибка, но она не всегда выделяется так же, как повторяющиеся поля. При разработке базы данных вы хотите убедиться, что все данные в таблице связаны с самим собой. Это похоже на игру этого ребенка о том, что отличает. Если у вас есть банан, клубника, персик и телевизор, телевизор, вероятно, принадлежит где-то еще.
В то же время, если у вас есть таблица продавцов, вся информация в этой таблице должна относиться конкретно к этому продавцу. Любая дополнительная информация, которая не является уникальной для этого продавца, может принадлежать где-то еще в вашей базе данных.
| SalesID | Первый | Прошлой | Адрес | Номер телефона | офис | OfficeNumber |
| 1 | Сэм | Эллиот | 118 Main St, Остин, TX | (215) 555-5858 | Остин | (212) 421-2412 |
| 2 | Алиса | кузнец | 504 2nd Street, Нью-Йорк, Нью-Йорк | (211) 122-1821 | Нью-Йорк (восток) | (211) 855-4541 |
| 3 | Джо | приход | 428 Aker St, Austin, TX | (215) 545-5545 | Остин | (212) 421-2412 |
Хотя эта таблица может выглядеть так, как будто все связано с отдельным продавцом, на ней фактически есть таблица, встроенная в таблицу. Обратите внимание, как Office и OfficeNumber повторяются с «Austin Downtown». Что делать, если номер офисного телефона меняется? Вам нужно будет обновить целый набор данных для одного изменения информации, что никогда не будет хорошо. Эти поля должны быть перемещены в их собственную таблицу.
| SalesID | Первый | Прошлой | Адрес | Номер телефона | OfficeID |
| 1 | Сэм | Эллиот | 118 Main St, Остин, TX | (215) 555-5858 | 1 |
| 2 | Алиса | кузнец | 504 2nd Street, Нью-Йорк, Нью-Йорк | (211) 122-1821 | 2 |
| 3 | Джо | приход | 428 Aker St, Austin, TX | (215) 545-5545 | 1 |
| OfficeID | офис | OfficeNumber |
| 1 | Остин | (212) 421-2412 |
| 2 | Нью-Йорк (восток) | (211) 855-4541 |
Этот тип дизайна также дает вам возможность добавлять дополнительную информацию в таблицу Office без создания кошмара беспорядка в таблице продавцов. Представьте себе, сколько работы было бы просто отслеживать адрес улицы, город, штат и почтовый индекс, если бы вся эта информация была в таблице продавцов!
Ошибка базы данных № 3: размещение двух или нескольких частей информации в одном поле
Внедрение офисной информации в таблицу продавцов было не единственной проблемой с этой базой данных. Поле адреса содержало три информации: адрес, город и штат. Каждое поле в базе данных должно содержать только одну единицу информации. Когда у вас есть несколько частей информации в одном поле, может возникнуть трудность запросить базу данных для получения информации.
Например, что, если мы хотим запустить запрос для всех продавцов из Остина? Нам нужно искать в поле адреса, что не только неэффективно, но и может возвращать плохую информацию. В конце концов, что произойдет, если кто-то живет на Остине в Портленде, штат Орегон?
Вот как выглядит таблица:
| SalesID | Первый | Прошлой | Адрес 1 | Адрес 2 | город | государственный | застежка-молния | Телефон |
| 1 | Сэм | Эллиот | 118 Main St | Остин | Техас | 78720 | 2155555858 | |
| 2 | Алиса | кузнец | 504 2nd St | Нью-Йорк | Нью-Йорк | 10022 | 2111221821 | |
| 3 | Джо | приход | 428 Aker St | Apt 304 | Остин | Техас | 78716 | 2155455545 |
Здесь есть пара вещей.Во-первых, «Address1» и «Address2», похоже, попадают под повторяющиеся ошибки полей.
Однако в этом случае они относятся к отдельным частям данных, которые относятся непосредственно к продавцу, а не к повторяющейся группе данных, которые должны идти за ее собственную таблицу.
Кроме того, в качестве бонусной ошибки, которую следует избегать, обратите внимание на то, как форматирование номера телефона было удалено из таблицы. Вы должны избегать хранения формата полей, когда это возможно. В случае телефонных номеров существует несколько способов написать номер телефона: 215-555-5858 или (215) 555-5858. Это сделало бы поиск продавца по номеру телефона или более сложный поиск продавцов в одном и том же региональном коде.
Ошибка базы данных №4: не использование правильного первичного ключа
В большинстве случаев вам нужно будет использовать автоматически увеличивающийся номер или какой-либо другой сгенерированный номер или буквенно-цифровой для вашего первичного ключа. Вы должны избегать использования какой-либо фактической информации для первичного ключа, даже если это звучит так, будто это сделает хороший идентификатор.
Например, у каждого из нас есть собственный индивидуальный номер социального страхования, поэтому использование номера социального страхования для базы данных сотрудников может показаться хорошей идеей. Но, хотя это редко, можно даже изменить номер социального обеспечения, и мы никогда не хотим, чтобы наш первичный ключ менялся.
И в этом проблема заключается в использовании фактической информации в качестве ключевого значения. Это может измениться.
Ошибка базы данных №5: не использование соглашения об именах
Это может показаться неважным, когда вы впервые приступите к разработке своей базы данных, но как только вы доберетесь до написания запросов к базе данных для получения информации, использование соглашения об именах поможет при запоминании имен полей.
Представьте себе, насколько сложнее этот процесс, если имена были сохранены как FirstName, LastName в одной таблице и first_name, last_name в другой таблице.
Два наиболее популярных соглашения об именах включают в себя первую букву каждого слова в поле или разделение слов с помощью подчеркивания. Вы также можете увидеть, что некоторые разработчики заглавные буквы первой буквы каждого слова, кроме первого слова: firstName, lastName.
Вы также захотите принять решение об использовании уникальных имен таблиц или имен множества таблиц. Это таблица заказов или таблица ордеров? Это таблица клиентов или таблица Customers? Опять же, вы не хотите зацикливаться на таблице Order и таблице Customers.
Выбранное вами соглашение об именах не так важно, как процесс фактического выбора и придерживаться соглашения об именах.
Ошибка базы данных №6: неправильная индексация
Индексирование - одна из самых трудных вещей, чтобы получить право, особенно для тех, кто новичок в дизайне базы данных. Все первичные ключи и внешние ключи должны быть проиндексированы. Это те таблицы ссылок вместе, поэтому без индекса вы увидите очень низкую производительность из своей базы данных.
Но то, что слишком часто пропущено, - это другие области. Это поля «WHERE». Если вы часто будете сузить свой поиск, используя поле в предложении WHERE, вы хотите подумать о том, чтобы ввести индекс в это поле. Однако вы не хотите чрезмерно индексировать таблицу, что также может повредить производительность.
Как решить? Это часть дизайна базы данных. Нет жестких ограничений на количество индексов, которые вы должны положить на стол. Прежде всего, вы хотите индексировать любое поле, которое часто используется в предложении WHERE. Подробнее о том, как правильно индексировать вашу базу данных.
