#mysql #database-design
#mysql #база данных-дизайн
Вопрос:
Проблема
Я получил небольшой контракт на разработку онлайн-системы котировок для электронного дистрибьютора. У него примерно полмиллиона деталей — один маленький винт считается деталью, один маленький светодиод и т.д. Итак, есть МНОГО частей.
Одно важное замечание: это всего лишь запрос предложения. Нет никаких цен на стороне клиента, или итогов, или чего-либо, что связано с деньгами. Просто собираю список номеров деталей для отправки моему клиенту.
Мне пришлось собирать данные о деталях из нескольких источников (веб-сайт поставщика, каталог отсканированных документов, электронные таблицы Excel, файлы CSV и даже несколько файлов JSON. Это было утомительно, но я справился.
Результаты
Сначала сбивает с толку. У меня были десятки категорий продуктов, и у некоторых продуктов было так много атрибутов, которые не были общими ни для каких других продуктов. Я мог видеть, что этот проект становится очень сложным, и, учитывая тот факт, что я предложил за эту работу даже 900 долларов, я должен был как-то упростить это.
Это то, что я придумал, и получил одобрение клиента.
Текущие столбцы
-------------------------- -------------- ------ ----- --------- -------
| Field | Type | Null | Key | Default | Extra |
-------------------------- -------------- ------ ----- --------- -------
| Datasheets | varchar(128) | YES | | NULL | |
| Image | varchar(85) | YES | | NULL | |
| DigiKey_Part_Number | varchar(46) | YES | | NULL | |
| Manufacturer_Part_Number | varchar(47) | YES | | NULL | |
| Manufacturer | varchar(49) | YES | | NULL | |
| Description | varchar(34) | YES | | NULL | |
| Quantity_Available | int(11) | YES | | NULL | |
| Minimum_Quantity | int(11) | YES | | NULL | |
-------------------------- -------------- ------ ----- --------- -------
таким образом, все продукты будут соответствовать этому шаблону страницы (меню внизу — ошибка на скриншоте).:
Автозаполнение Со стола?
На ранних стадиях разработки я реализовал приятную функцию автозаполнения:
НО … учитывая количество продуктов в таблице, практично ли это вообще сейчас???
КОЛИЧЕСТВО КОНЕЧНОГО ПРОДУКТА: 223 347
Какие изменения мне нужно внести в таблицу ПРОДУКТОВ, чтобы запрос к таблице не занимал вечность?
Это единственные запросы, которые будет выполнять приложение (не уверен, поможет ли эта информация в вашем совете по решению)…
-
Получить все товары по категориям: Выберите * из товаров, где категория = ‘полупроводники’
-
Получить отдельный продукт: Выберите * из продуктов, где Manufacturer_Part_Number = ‘12345’
-
Получить количество товаров по категориям
Я думаю, что эти три действительно охватывают все, что мне нужно сделать. Может быть, еще пара, но не так много.
В заключение…
Есть ли способ «проиндексировать» эту таблицу с 223000 записями, где поиск по одному или нескольким столбцам может быть выполнен эффективно?
Я новичок в проектировании баз данных и знаю, что мне нужно ЧТО-ТО индексировать, но … ЧТО???
Спасибо, что нашли время, чтобы просмотреть этот пост.
С уважением,
Джон
Комментарии:
1. Найдите время, чтобы прочитать об индексации (разделы 1 и 2). 3) периодически генерируйте этот результат, поскольку это длинный запрос, который нельзя оптимизировать..
2. Каков ваш ПЕРВИЧНЫЙ КЛЮЧ?
3. Я согласен, что у вас должен быть первичный ключ (т. Е. Номер продукта). Для этого, вероятно, нельзя использовать Manufacturer_Part_Number, потому что два разных производителя могут использовать один и тот же номер для одного из своих продуктов. Кажется, что Manufacturer_Part_Number уникален только в сочетании с Manufacturer . (Вы должны указать уникальное ограничение для двух столбцов.) Это делает маловероятным, что вы захотите найти продукт только по Manufacturer_Part_Number, вам также придется ограничить по производителю или выполнить поиск по уникальному номеру продукта.
Ответ №1:
Перечисление запросов является обязательным для ответа на ваш вопрос. Спасибо, что включили их.
INDEX(category)
INDEX(Manufacturer_Part_Number)
Но я полагаю, что ваш второй запрос также должен включать Manufacturer . Тогда это было бы лучше:
INDEX(Manufacturer, Manufacturer_Part_Number)
Все NULL ? Кажется маловероятным.
(Я выполнял задания, подобные вашему; я не могу представить, что предложу всего 900 долларов за всю эту очистку.)
Что вы будете делать, когда в одной категории или производителе будет тысяча товаров? Пользовательский интерфейс со списком из тысячи элементов отстой.
Для того, как обрабатывать «так много атрибутов», я рекомендую http://mysql.rjweb.org/doc.php/eav (Я должен взять с вас 899 долларов за исследование, которое вошло в этот документ. Просто шучу.)
Разве им не нужны другие поисковые запросы, такие как «Флэш-накопитель», которые должны соответствовать «FLASH DRV»?
223 Тыс. строк — без проблем. VARCHARs Кажутся слишком короткими; были ли они основаны на данных?
И для таблицы требуется PRIMARY KEY .
Комментарии:
1. Я действительно ценю ответ. Я внес предложенные вами изменения. Были изменены размеры столбцов, а также добавлен новый индекс. Я добавил первичный ключ к номеру детали производителя, поскольку они никогда не должны дублироваться. У меня есть полнотекстовый индекс в описании, чтобы помочь с автозаполнением. Иногда возникает задержка, но в целом все работает нормально. Я также запустил базу данных с помощью утилиты нормализации. Что касается дешевой цены, я согласен, это была отдача. Это для одного из членов церкви, так что я был не против. Я думаю, что многому научился — хотя с индексами трудно увидеть результаты.