Этапы проектирования базы данных:
- Анализ требований: всестороннее понимание требований к хранилищу для разработки продукта
- Логический дизайн: разработка логической структуры хранения данных.
- Физический дизайн: спроектируйте структуру таблицы в соответствии с характеристиками используемой базы данных.
- Оптимизация обслуживания: оптимизируйте индекс и механизм хранения в соответствии с реальной ситуацией. ### Парадигма базы данных:
- Первая нормальная форма: все поля в базе данных имеют только один атрибут
- Вторая нормальная форма: в условиях первой нормальной формы таблица должна иметь только один бизнес-первичный ключ, и каждая таблица выполняет только одно действие.
- Третья нормальная форма: на основе второй нормальной формы устранить транзитивные зависимости в таблице
1. Анализ требований и логическое проектирование
Пользовательский модуль
- Пользователи должны зарегистрироваться и дождаться, пока система проведет онлайн-транзакции.
- В то же время пользователь может войти в одно место
- Информация о пользователе: {имя пользователя, пароль, номер мобильного телефона, имя, дата регистрации, сетевой статус, дата рождения}
товарный модуль
- Информация о продукте: {название продукта, название издателя, цена книги, описание книги, автор}
- Информация о категории: {название категории, описание категории}
- Информация о классификации продуктов (таблица соответствия): {название продукта, название категории}
модуль поставщика
- Информация поставщика: {имя издателя, адрес, номер телефона, контактное лицо, номер банковского счета}
Модуль онлайн-продаж
- Данные, необходимые для онлайн-продаж: {номер заказа, имя пользователя заказа, дата заказа, сумма заказа, классификация товаров заказа, название товара заказа, цена за единицу товара заказа, количество товара заказа, сумма платежа, номер заказа логистики}
- Таблица заказов: {номер заказа, имя пользователя заказа, дата заказа, сумма платежа, номер заказа логистики}
- Таблица сопоставления позиций заказа: {номер заказа, категория позиции заказа, название позиции заказа, количество позиции}
Учитывайте проблемы с производительностью и изменения цен на товары:
-
Ненормализованный дизайн таблицы информации о продукте:
Информация о продукте: {Название продукта, название категории, название издателя, книга, описания книги, автор}
Информация о категории: {название категории, описание категории}
-
Денормализованный дизайн формы онлайн-продаж:
Форма заказа: {номер заказа, имя пользователя заказа, номер мобильного телефона, дата заказа, сумма платежа, номер заказа логистики, сумма заказа}
Таблица корреляции позиций заказа: {номер заказа, категория позиции заказа, название позиции заказа, количество позиции, цена за единицу позиции}
-
Денормализованный оператор SQL для запроса общей суммы заказов каждого пользователя:
выбрать имя пользователя заказа, сумму (сумму заказа) из группы таблиц заказов по имени пользователя заказа;
-
Денормализованный оператор SQL для запроса пользователя заказа и сведений о заказе:
выберите а) номер заказа, а) имя пользователя, а) номер мобильного телефона, б) название продукта, б) цену за единицу продукта, б) количество продукта из таблицы заказов, а) присоедините таблицу сопоставления продуктов заказа, а) номер заказа = б. номер заказа; ### Плюсы и минусы нормализации
Преимущества нормализации:
- Избыточные данные могут быть сведены к минимуму
- Нормализованные операции обновления выполняются быстрее, чем денормализованные
- Нормализованные таблицы обычно меньше денормализованных.
Недостатки парадигмы:
- Запрос должен быть связан с несколькими таблицами
- Сложнее оптимизировать индекс ###Преимущества и недостатки денормализации
Преимущества денормализации:
- Может быть очень хорошо уменьшить ассоциацию таблицы
- Запросы могут быть оптимизированы для индекса
Недостатки денормализации:
- Существует избыточность данных и неправильное обслуживание данных
- Изменения данных требуют дополнительных затрат
Во-вторых, этап физического проектирования базы данных.
- Определить соглашения об именах для баз данных, таблиц и полей (принцип удобочитаемости, идеографический принцип, принцип длинных имен)
- Выберите правильный механизм хранения
-
Выберите подходящий тип данных для полей в таблице (если для столбца можно выбрать несколько типов данных, следует предпочесть числовой тип, за которым следует тип даты или двоичный тип и, наконец, символьный тип. Для одного и того же уровня типов данных , следует предпочесть выбрать тип данных с небольшой площадью)
Тип целочисленного числа:
tinyint(1个字节)、smallint(2个字节)、 mediumint(3个字节)、int(4个字节)、bigint(8个字节)Реальный тип:
float(4个字节，不为精确类型)、double(8个字节，不为精确类型)、 decimal(每4个字节存9个数字，小数点占一个字节，为精确类型)типы varchar и char:
varchar类型存储特点： 用于存储变长字符串，只占用必要的存储空间； 列的最大长度小于255时则只占用一个额外字节用于记录字符串长度； 列的最大长度大于255则，要占用两个额外字节用于记录字符串长度 如何对varchar列选择合适的宽度： 使用最小的符合需求的长度； varchar(5)和varchar(200)存储MySQL字符串性能不同 varchar的适用场景： 字符串列的最大长度比平均长度大很多； 字符串列很少被更新的字符串的列； 使用了多字符集存储字符串 char类型存储特点： char类型是定长的； 字符串存储在char类型的列中会删除末尾的空格； char类型存储的最大的宽度是255 char类型的适用的场景： 适合存储所长度近似的值（eg:md5的值、手机号、身份证号） 适合存储长度短小的字符串 适合存储存储经常更新的字符串Тип даты:
datatime类型以YYYY-MM-DD HH:MM:SS[.fraction]格式存储数据 datatime类型与时区无关，占用8个字节存储空间 存储的时间范围：1000-01-01 00：00:00到9999-12-31 23:59:59 timestamp类型存储从1970年1月1日到当前的秒数，以YYYY-MM-DD HH:MM:SS[.fraction]显示，占用4个字节存储空间 timestamp类型显示依赖于所指定的时区 timestamp类型在行数据修改时可以自动修改timestamp列的值 timestamp存储的时间范围1970-01-01到2038-01-19 date类型和time类型（mysql5.7之后加入）： date类型占用的字节数比使用字符串、datatime、int存储要少，使用date类型只需要3个字节； date类型使用Date类型还可以利用日期时间函数进行日期之间的计算； date类型存储的日期范围1000-01-01到9999-12-31之间的日期 time类型用于存储时间数据：HH:MM:SS 存储日期时间类型的注意事项： 不要使用字符串类型来存储日期时间数据； 日期时间类型通常比字符串类型所占用的存储空间小； 日期时间类型在进行查找过滤时可以利用日期来进行对比； 日期时间类型有丰富的处理函数，可以方便的对时间类型的进行日期计算 使用Int存储日期时间不如使用Timestamp类型Как InnoDB выбирает первичный ключ: Первичный ключ должен быть как можно меньше; Первичный ключ должен увеличиваться последовательно (для уменьшения случайного ввода-вывода) для повышения эффективности вставки данных; Первичный ключ InnoDB и первичный бизнес-ключ могут отличаться
-
Построить структуру базы данных
-
Поддерживать оптимизированную базу данных