
Новые сообщения [новые:0]
Дайджест
Горячие темы
Избранное [новые:0]
Форумы
Пользователи
Статистика
Статистика нагрузки
Мод. лог
Поиск
|
|
26.02.2015, 15:04
|
|||
|---|---|---|---|
Посоветуйте схему для товаров с различными категориями и параметрами |
|||
|
#18+
Есть выгрузка товаров в XML формате. В ней товары совершенно разных категорий - одежда, обувь, аксессуары. Вполне возможно, что так же будут добавлены и другие категории товаров, как например мобильные телефоны, телевизоры и тому подобное. Вот примерно то что я придумал для структуры базы (будет использоваться MySQL ): Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. Как я упоминал выше товары будут совершенно разных категорий, и по этим категориям планируется сделать поиск/фильтр. Вот пример таких параметров в самой выгрузке для женских валенок: Код: xml 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. вот для мужской обуви Код: xml 1. 2. 3. 4. 5. 6. 7. Для одежды пример приводить не буду, то же самое примерно. Покритируйте базу, может можно, что сделать получше. Задумка такая: product_available_parameters , в ней хранятся все доступные параметры товаров (например "Страна изготовитель", "Пол", итд); products - сами товары category - категории товаров, в ней же есть поле product_parameters (TEXT), в ней думаю хранить все возможные параметры для этой категории в виде JSON или разделенных запятыми. Первый запрос - получаю категорию, вторым запросом выбираю все возможные параметры для этой категории, третьим запросом выгребаю товары для этой категории. product_parameters - тут будут храниться подборки по товарам и их параметрам, думаю тут наверно не хватает связи с таблицей категорий, т.к. на странице категории нужно будет например вывести все женские сапоги черного цвета и такой то коллекции. Как думаете, годная ли структура, нет ли чего лишнего или наоборот может чего то не хватает? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
26.02.2015, 15:16
|
|||
|---|---|---|---|
Посоветуйте схему для товаров с различными категориями и параметрами |
|||
|
#18+
В products не понял зачем Код: sql 1. Если важно хранить, что было в какой то момент на продукте, то нужно добавить версионность. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
26.02.2015, 15:39
|
|||
|---|---|---|---|
|
|||
Посоветуйте схему для товаров с различными категориями и параметрами |
|||
|
#18+
boroff, На мой взгляд, ненужное смешение технологий. Если Вы используете JSON -то зачем городить реляционные параметры, тогда уж храните и значения параметров в JSON-поле в продукте. И наоборот, если Вы хотите построить реляционную модель - то нафига тут JSON, чего бы не сделать связующую таблицу между категориями и параметрами? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
26.02.2015, 15:47
|
|||
|---|---|---|---|
Посоветуйте схему для товаров с различными категориями и параметрами |
|||
|
#18+
ndbnВ products не понял зачем Код: sql 1. Если важно хранить, что было в какой то момент на продукте, то нужно добавить версионность. Название поля MySQL Workbench сгенерил похоже, видимо я связь не в ту сторону показал когда лепил схему. Привязка products к product_parameters, чтобы для каждого продукта хранить список параметров. На версионность наплевать, XML-выгрузки будут загружаться каждый день, при вставке будет обновляться только price, oldprice и категория товара (т.к. товар может быть не распределен на момент загрузки) либо добавляться новый товар, если такого не было. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
26.02.2015, 16:37
|
|||
|---|---|---|---|
Посоветуйте схему для товаров с различными категориями и параметрами |
|||
|
#18+
Ну тогда присоединяюсь к Кот Матроскин. boroffна странице категории нужно будет например вывести все женские сапоги черного цвета и такой то коллекции. Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
26.02.2015, 18:35
|
|||
|---|---|---|---|
Посоветуйте схему для товаров с различными категориями и параметрами |
|||
|
#18+
boroffНа версионность наплевать, XML-выгрузки будут загружаться каждый день Какая то куцая у вас система получится. Почему бы не хранить историю изменения цены- ничего сложного в этом нет. Делаешь отдельную таблицу: продукт, дата начала, дата конца, цена. Все! Ну а хранить процент, на который цена изменилась, это высший пилотаж :) Он же считается очень легко, зачем хранить? boroffКак думаете, годная ли структура, нет ли чего лишнего или наоборот может чего то не хватает? Еще бы еще знать, что вы там задумали (как использовать эти таблицы, кроме как загружать туда данные), вообще было бы отлично )) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
27.02.2015, 00:33
|
|||
|---|---|---|---|
Посоветуйте схему для товаров с различными категориями и параметрами |
|||
|
#18+
SergueiКакая то куцая у вас система получится. Почему бы не хранить историю изменения цены- ничего сложного в этом нет. Делаешь отдельную таблицу: продукт, дата начала, дата конца, цена. Все!Куцая она потому что сайт - это витрина товаров + поиск по ним. В прошлой версии сайта история изменения цен хранилась, сейчас все с нуля переписывается, может потом будет добавлен и такой функционал. История хранилась просто в отдельной таблице с тремя колонками (product_id, price, date). Все товары продаются на других магазинах, поэтому задача стоит в создании различных удобных фильтров и сравнениях товарах, а так же категоризация этих товаров, история изменения цен пока не особо нужна. SergueiНу а хранить процент, на который цена изменилась, это высший пилотаж :) Он же считается очень легко, зачем хранить?А зачем его каждый раз считать при выборках? :) Товаров будет меньше 1 млн., так что одно integer поле в таблице много места на диске не займет :) Например надо вывести женские сапоги со скидкой от 20%, отсортировать по убыванию размера скидки. Имхо проще сразу по этому полю сортировать, а расчет процента происходит после загрузки товаров, одним запросом. SergueiЕще бы еще знать, что вы там задумали (как использовать эти таблицы, кроме как загружать туда данные), вообще было бы отлично )) Вот что-то похожее http://www.thefind.com/search?query=ray ban sunglasses справа там есть фильтр (магазины, цена, бренд, цвет, итд). Кот МатроскинНа мой взгляд, ненужное смешение технологий. Согласен, похоже я тут перемудрил. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
27.02.2015, 06:32
|
|||
|---|---|---|---|
|
|||
Посоветуйте схему для товаров с различными категориями и параметрами |
|||
|
#18+
boroffЕсть выгрузка товаров в XML формате. В ней товары совершенно разных категорий - одежда, обувь, аксессуары. Вполне возможно, что так же будут добавлены и другие категории товаров, как например мобильные телефоны, телевизоры и тому подобное. Вот примерно то что я придумал для структуры базы (будет использоваться MySQL ): Предлагаю лечить головную боль усекновением головы. ;-) Вместо MySQL взять PostgreSQL. В нем есть типы JSON и JOSNb. По полям этого типа можно строить индексы, делать запросы, с учетом структуры JSON. Решение, простое, быстрое и не правильное ;-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
27.02.2015, 10:41
|
|||
|---|---|---|---|
Посоветуйте схему для товаров с различными категориями и параметрами |
|||
|
#18+
Если хотите минимум головной боли при БД-миграциях, то рекомендую для хранения доп. инфы забыть про JSON. В JSON можно хранить только ту инфу, кот. никогда не будут искать с пом. SQL. Например некритичные комментарии, подсказки и т.п. Применяйте EAV. Он одинаков на любой СУБД. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
18.03.2015, 11:59
|
|||
|---|---|---|---|
Посоветуйте схему для товаров с различными категориями и параметрами |
|||
|
#18+
mad_nazgulВместо MySQL взять PostgreSQL. В нем есть типы JSON и JOSNb. По полям этого типа можно строить индексы, делать запросы, с учетом структуры JSON. В общем так и сделал, перенес всю базу на PostgreSQL, только вместо JSON решил использовать hstore для параметров товаров и array для тегов. Как раз и поддержка всего этого прямо в django появилась, безо всяких дополнительных модулей https://docs.djangoproject.com/en/1.8/ref/contrib/postgres/fields/ ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
22.03.2015, 04:10
|
|||
|---|---|---|---|
|
|||
Посоветуйте схему для товаров с различными категориями и параметрами |
|||
|
#18+
LSVЕПрименяйте EAV. Он одинаков на любой СУБД.Согласен см. Entity-Attribute-Value Model ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|

start [/forum/topic.php?fid=32&mobile=1&tid=1540606]: |
0ms |
get settings: |
9ms |
get forum list: |
12ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
28ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
55ms |
get tp. blocked users: |
1ms |
| others: | 39ms |
| total: | 164ms |

| 0 / 0 |

Извините, этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
... ля, ля, ля ...