Все технические форумы на одном сайте Удобный поиск информации с популярных форумов в одном месте
Вопрос: Избитый вопрос - реализация каталога товаров

Всем доброго времени суток!
Никогда раньше не занимался проектированием базы для крупных проектов, поэтому столкнулся с проблемой выбора структуры бд.

Задача проста(?) как три копейки - структура базы каталога товаров. С реализацией вложенных категорий все понятно - nested sets (или уже придумали что-то получше?).

Вопрос в хранении товаров и их характеристик. Кол-во товаров несколько миллионов, кол-во характеристик к каждому из них - от 20 до 100 (а может и больше). Из функционала ничего сверхъестественного - поиск, вставка, сравнение товаров, поиск схожих.

Наиболее реальной кажется такая структура:

Справочник
id
название

Значения справочника
id
id справочника
Название

Параметры
Id
id категории
название параметра
тип параметра (строка, число, дата, список)
id справочника

Товар
id
id категории
название, цена и прочее

параметры товаров
id
id параметра
id товара
значение

Насколько удачно такое решение? В плане скорости выборок (вывод категории, поиск по параметрам)?
Ответ:
Dimitry Sibiryakov
Digital God
как видно из рассуждений - не только EAV подходит

Очевидно, мне нужно было выделить слово "работоспособная" жирным крупным шрифтом... Но кто
я такой, чтобы охранять Ваши яйца от граблей?..

Никто не отрицал EAV, просто рассматриваем варианты реализация и все за и против.

alexeyvg
Digital God
Интересно, как яндекс маркет хранит данные?
EAV используют.
Я делал (не один, конечно) проект Подбери.ру, его купил яндекс и так появился яндекс маркет :-)
Конечно, наверняка код они за эти 10 лет переписали, но вряд ли принцип поменялся.

Я где-то так и думал что это EAV с модификациями.

В общем буду развивать тему EAV.
Вопрос: Каталог товаров с фильтрами по характеристикам товара — выбор БД

Стоит вопрос про выбор базы данных для большого каталога товаров: 50 млн. товаров; 30 000 категорий. В каждой категории 3-15 фильтров по характеристикам товара.

Особенность каталога:
- многоязычность
- каждый товар привязан к определенной GEO зоне (выделенной на карте) и показывается только если клиент находиться в этой зоне
- динамическое ценообразование от различных каналов и факторов

Нужно быстродействие, удобство и отказоустойчивость.

Что посоветуете, какую базу данных выбрать? Вероятно какую-то связку баз данных? Как бы Вы для себя сделали такой проект?
Ответ:
Сообщение от jfinister
для большого каталога товаров
50 млн строк в одной таблице - это не шибко много. Практически любая нормальная СУБД потянет: Oracle, MS SQL, MySQL.
Вопрос: Как организовать обновление каталога товаров?

Доброго всем времени суток,

Я написал скрипт каталога товаров (PHP + MySQL), сейчас задумался над возможностью обновления цен из csv-файла. Опыта в подобных делах у меня нет. Хочу спросить в частности следующее, может ли имя товара выступать в качестве уникального идентификатора? т.е. можно ли обновлять цены из CSV-файла с двумя колонками: имя, цена.

Вообще был бы благодарен за любую информацию по теме, ссылки на интересные статьи.
Ответ:
poiuytrewq
Доброго всем времени суток,

Я написал скрипт каталога товаров (PHP + MySQL), сейчас задумался над возможностью обновления цен из csv-файла. Опыта в подобных делах у меня нет. Хочу спросить в частности следующее, может ли имя товара выступать в качестве уникального идентификатора? т.е. можно ли обновлять цены из CSV-файла с двумя колонками: имя, цена.

Вообще был бы благодарен за любую информацию по теме, ссылки на интересные статьи.


В этой теме рассматриваете интересный интерфейс, как создать . Я так понимаю его потом можно закачать на сайт.
Вопрос: Каталог товаров с фильтрами по характеристикам товара (выбор БД)

Стоит вопрос про выбор базы данных для большого каталога товаров: 50 млн. товаров; 30 000 категорий. В каждой категории 3-15 фильтров по характеристикам товара.

Особенность каталога:
- многоязычность
- каждый товар привязан к определенной GEO зоне (выделенной на карте) и показывается только если клиент находиться в этой зоне
- динамическое ценообразование от различных каналов и факторов

Нужно быстродействие, удобство и отказоустойчивость.

Что посоветуете, какую базу данных выбрать? Вероятно какую-то связку баз данных? Как бы Вы для себя сделали такой проект?
Ответ:
автор
Что посоветуете, какую базу данных выбрать? Вероятно какую-то связку баз данных? Как бы Вы для себя сделали такой проект?

Я вам рекомендю MYSQL, +граммотное техническое задание, тогда вы сэкономите время, и можно будет от описательной части и части рассуждений переходить к конкретики. А так это задача из области фантастики. А что вы будете если ассортимент товаров расшириться от 50 млн до 100 млн? Или измениться номенклатура товара?
Вопрос: Каталог товаров/услуг 1600 категорий

Доброго времени суток! Собираюсь делать проект. Доска объявлений. 1600 категорий (дерево). Товар в каждой категории может иметь собственные атрибуты. Новые категории/атрибуты могут добавляться, но это редко. Нужен полнотекстовый поиск (заголовок. описание товара) а также фасетный, по атрибутам в конкретной категории. Базу думаю взять MySQL + Sphinx для поиска. С EAV работал, но не нравится, сложные запросы, получается какая-то БД внутри БД. Однако, если идти по пути наследования (Class Table Inheritance), придется создать около 1600 таблиц, чего я пока что никогда не делал и меня это смущает. Кто-нибудь создавал/поддерживал столько таблиц для таких целей? Это правильный путь или нет?

Для облегчения задачи хочу взять ORM (Doctrine 2), получится около 1600 классов сущностей. Работу с таблицами доктрина возьмет на себя.
Ответ:
Anton5577
Еще вопрос про наследование таблиц. У категорий должна быть своя таблица, хранящая древовидную структуру (NestedSet, например), или же нужно исходить из того, что товары/услуги и так организованы иерархически (наследование таблиц) и в качестве идентификатора категории нужно использовать идентификатор типа (дискриминатор)?


В PostgreSQL есть [url=] таблиц[/url].
Вопрос: Связка ID категории - ID товара

По какому принципу делается связка ID категории - ID товара, если товаров и категорий много (в таблице 120 млн записей)? Товар может быть в нескольких категориях. Была идея привлечь патрициев, в принципе скорость немного увеличилась, но сделать нормальное партиционирование не удалось (пришлось делать PARTITION BY HASH), так как категорий у меня 40 тыс, а партиций MySQL максимум поддерживает 8192. Собственно проблема пока в COUNT(*) для фильтра на странице каталога товаров, чем больше товаров в категории, тем больше тупит COUNT(*), с небольшим количеством просто летает, а с 200 тыс товаров в категории уже жуёт секунд по 8. Индексы, избыточные индексы над primary key и прочие танцы с бубном пока ни к чему не привели. Может разбить по таблицам, одна категория = одна таблица? 40 тыс таблиц в базе насоздавать и джойнить затем в выборках необходимый раздел, хм...
Ответ:
st_st
бд занимает примерно пол терабайта (с данными и индексами), а ОЗУ на сервере намного меньше.
Надо бы стремить одно к другому.
БД хорошо бы пересмотреть на предмет уменьшения, как, например, с таблицей выше.
А в innodb_buffer_pool_size надо уместить хотя бы "горячую" часть БД.
Вопрос: Мучает вопрос названия таблиц

На ночь глядя столкнулся с таким вопросом - вот его суть:

Например есть табличка items (пусть будет каталог товаров - не суть)
У этой таблички (items) есть категории. Я бы назвал ее просто categories, но категории встречаются уже в моей базе в тикетах tickets, по этому в названии таблички categories мы должны указать к каким категориям она относится. Получается общая структура выглядит так:

items
items_categories
tickets
tickets_categories

Но это не все. Каждая связка должна иметь связь многие ко многим, в результате получается.

items
items_categories
items_items_categories
tickets
tickets_categories
tickets_tickets_categories

Получается не очень компактно и красиво. Очень длинные названия таблицы в базе, очень длинные переменные в коде. Конечно хочется чтобы с этим продуктом кто-то другой мог дальше работать. Разнести по разным базам (items и tickets) не вариант, хочется сохранить целостность.
Ответ:
babona
еще раз настаиваю - называйте таблицы международными наименованиями, Яндекс-переводчик в помощь, а еще лучше словарь по предметной области найти.

Автор молодец, если задумывается над наименованиями.

Представьте, схему вашей базы данных , тексты запросов под микроскопом пристально будут рассматривать зарубежные маститые специалисты. Если будет понятно и западным аналитикам и бизнесАм, то будете на коне. Не слушайте местных программистов
В конце концов база велозавода - отправной пример


называйте таблицы МЕЖДУНАРОДНЫМИ наименованиями, ЯНДЕКС-ПЕРЕВОДЧИК в помощь.

Считаю данное предложение абсурдом )))
Вопрос: Nosql посоветуйте для организации каталога

доброго времени суток.

Посоветуйте плиз базу Nosql для организации сложного каталога товара с множеством параметров и поддержкой php
Ответ:
Понятие очень размытое, например MongoDB относится к noSQL, но там нельзя выполнять запросы на SQL. То есть в данном случае NO в буквальном смысле.
Вопрос: Организация продаж не с фиксированным товаром

Здравствуйте.

Ищу человека, который сможет реализовать простую базу данных с дополнительным функционалом.
Вот в чем смысл:
Заходим в БД, открывается окно, где можно выбрать: новый заказ, заказы, клиенты, ввести курс валюты на текущую дату

открываем форму добавления заказов, заказу присваивается номер заказа, дата заказа, заполняем данные продавца, с возможностью автоматического ввода из базы данных уже ранее размещавших свой заказ, переходим к заполнению самого заказа, вместо названия товара желательно чтобы загружалась маленькая картинка, далее столбцы: размер, цвет, кол-во, цена (в иностранной валюте), ems, стоимость (в рублях, считает по формуле: (кол-во*цена+ems)*курс, курс проставляется автоматом при начале работы с базой, но можно его изменить, чтобы не загромождать таблицу, курс вынести одним значением в верхней части заказа), так же посчитать итоговую стоимость всех товаров. После сохранения заказа или его заполнения возможность выгрузить данный заказ в формате pdf для предоставления клиенту и возможностью распечатать.

С таблицей и формой клиент думаю все ясно.

Далее после подтверждения клиентом готовность выкупить данный товар, мы его оплачиваем, продавец высылает его, а нам предоставляется номера накладных и трекеры посылок, так как в одном заказе может быть много продавцов, но у одного продавца может быть несколько товаров, отправляя он дает их нам, необходимо вводить эти данные к заказу и это уже начинается складской учет по виду:

номер заказа - товар - товарная накладная - трекер

Дальше клиент начианет названивать и спрашивать де его товар, войдя с главной страницы в заказы, спрашиваем у него номер заказа, смотрим там по номеру заказа номер ттн, связываемся с продавцом, узнаем где это, клиент спокоен (таблицы с продавцами не нужны, поставщиков не надо).

Пришел товар, открывает заказы, по номеру трекера определяем чей заказ, отмечаем этот товар как пришедший (товары приходят постепенно с заказа, не разом), распечатываем товарную накладную на базе того самого заказника, который могли выгрузить в pdf, где отмеченные позиции написаны черным. либо выделены, а те что не отмечены тусклые (серым цветом), распечатываем, отдаем клиенту, где он расписывается именно за полученный товар.

Клиент звонит снова с вопросом где его товар, мы повторяем по кругу, открываем заказы с главной страницы, по номеру заказа находим его заказ (либо по клиенту, либо по контактному телефону или емейлу), смотрим и видим. что из 5 позиций, клиент за 3 расписался, напоминаем ему какие позиции он забрал, а с 2 другими работаем уже вне базы.

После получения последних товаров, так же клиенту отдаем его недостающие товары, отмечаем все позиции как выданные и товар меняет статус с активного на выданный (можно даже сделать. дополнительную графу, где пользователь сам будет выбирать статус заказа из: тестовый, оплаченный, выкупленный, выданный или закрытый).

Вроде бы и все, но есть еще свои небольшие нюансы, которые уже обсудим лично.

Прошу сообщение не оставлять без внимания, помощь не безвозмездная, для Вас займет несколько часов, для меня пару жизней.
Ответ: kaasin, что-то слишком много написали. Можно по порядку и выложить ваш пример (то, что уже есть и желательно с некоторыми данными. Или просто перейдите во фриланс (там за определенную плату могут помоч тоже). Если изложете мысль яснее может получится и бесплатно.
Вопрос: Цена реализации товара

Есть таблица - реализация товар (там содержится номенклатура и цена товара), Таблица Реализация - там сведения о клиенте.
На основании этих таблиц сделаны формы.
Форма Реализация содержит подчиненную форму реализация-товар.

не получается: сделать цену реализации ((цена закупки (из таблицы закупка-товар) * 25%)).

т.е при заполнении формы реализация подставлялась цена реализации и считалась стоимость и чтобы все это записывалось в таблицы реализация и реализация-товар
Ответ:
Сообщение от Robert
А как это сделать я не знаю
Написано же - по средней стоимости остатка. По FIFO распределяете остаток по закупкам, считаете среднюю закупочную стоимость.
Другой вариант (для учебных сгодится) - продавать товар из закупок. Добавить в таблицы Закупка-товар и Реализация-товар новые поля - счетчики, старые ключевые удалить, в Реализация-товар ссылаться на это новое поле, а счетчик в ней будет нужен, т.к. товары могут повторяться из-за того, что они могут быть из разных закупок с разными закупочными ценами. Тогда проблем с ценой не будет - закупочная вытаскивается по ключу из Закупка-товар.