Как правильно организовать структуру данных для вебсайта на Питоне + MySQL?
как правильно организовать структуру данных для вебсайта на Питоне + MySQL?
дано: промышленный продукт. Заводское обозначение продукта имеет следующую структуру ABC-XXXX-XXXX-XXXX, где первые три буквы "АВС" у всех продуктов одинаковы. А остальные буквы отображают не связанные друг с другом свойства/аттрибуты продукта и могут принимать 1...8 значений.
Например первый "Х" - это цвет, может принимать значения 1-белый, 2-красный, 3-зеленый, 4-желтый и т.д.
второй "Х" - это клей, которым продукт склеен, может принимать значения 1-клей на полиуретановой основе, 2-клей на эпоксидной основе, 3- клей на керамической основе, и т.д.
третий "Х" - это материал из которого продукт изготовлен, может принимать значения 1-полиамид, 2-оцинкованная сталь, 3-алюминий, 4-нержавейка и так далее
и так далее.
То есть продукт может называться ABC-9871-5235-1258 и в таком же духе в соответствии с возможными для данного икса аттрибутами.
задачи следующие
как правильно организовать структуру хранения данных?
Первый вариант, самый тупой и неэффективный - это создать таблицу и забить в нее все возможные варианты обозначения продукта. Получится таблица с 20.000 - 100.000 записями всех возможных комбинаций продукта.
Нужно учесть два аспекта
1. генерирование sitemap.xml для поисковика. Когда поисковик запросит файл sitemap.xml - сгенерировать ему это файл на основании этой большой таблицы - здесь все ясно. А без нее?
2. Посетитель вводит обозначение продукта в поисковом окошечке на вебсайте. Осуществить поиск на основании этой большой таблицы - здесь все ясно. А без нее?
Подозреваю что можно организовать данные как-то более эффективно чем статическая таблица на 20.000 - 100.000 записей, но не понимаю как.
Поддержите пожста идеей.
Если не делать эту большую таблицу, а при запросе поисковиком sitemap.xml генерировать динамически из отдельных аттрибутов, процесс займет наверное от 5 минут и больше. Поисковик будет ждать столько времени?
Лентюй,
нет, реально гораздо меньше, наверное тыщ 5-10-15. Уже существующих изготовленных. Остальные теоретически возможны по запросу и заказу клиента. Подавляющее количество из указанных конфигураций теоретически и практически возможно, но с технической точки зрения имеет мало смысла. Клиенты смотряд технические брошюры, сами подбирают себе конфигурацию по своему усмотрению, часто бессмыссленную, как я только что написал, а потом подобранный код типа ABC-9871-5235-1258 вводят в поиск. Так как согласно технических документов данный код теоретически и практически возможен, я должен выдать клиенту информацию по данному запросу и только после этого обсуждать с ним насколько его запрос имеет или не имеет смысл.
Кроме того там не так много должно быть. Некоторые аттрибуты имеют 3-4 варианта, некоторые 2-3, а есть некоторые у которых 5-8. Думаю что если перебрать все возможные варианты, то будет не больше 100.000 вариантов
Лентюй,
чтобы мне это сделать, мне нужно вытащить из системы все существующие продукты, это по техническим и организационным причинам нереально. Проще сделать классификатор всех возможных продуктов, даже если их окажется в 10 раз больше, чем реальных.
Дайте какую-то идею пож-ста хотя бы с чего начать.
Уже неделю пытаюсь алгоритм разработать, не укладывается в мозгу.
Спасибо.
Роман Мирр,
а как быть иначе.
Клиент запросил гугл какой-то продукт ABC-9871-5235-1258
Если я этот продукт гуглу в sitemap.xml не покажу, откуда гугл узнает, что этот продукт вообще существует?
я не имею в виду, что сайтмап должен иметь количество записей равное количеству записей в большой таблице, но информация обо всех теоретически/практически возможных комбинациях гуглу каким-то образом должна быть передана на мой взгляд. Сайтмап может иметь десяток или сотню линков, но внутри этих линков должны быть все остальные.
короче пришел к следующему решению.
если взять все возможные варианты, то получается количество записей в таблице порядка с 6 нулями. Что в принципе явно избыточно со всех точек зрения. Остановился на том, что создам около 100.000 тыщ записей, которые покроют минимум процентов 80 (а может и больше) всех вероятных поисковых запросов. На том и остановился. То есть у меня в sitemap.xml будет около 100.000 линков.
Эти 100.000 записей с обозначением продукта можно было генерировать динамически из двух таблиц с 50 записями, - экономия места в таблице (наверное не обязательно) но ресурсозатратно при каждой новой генерации. Поэтому сделал одну статическую таблицу на эти 100.000 записей, из которой за пару секунд автоматически генерится sitemap.xml.
.
То есть изначальный перфекционистский подход - оказался явно избыточным.
