Какую сделать структуру базы (фирмы и товары) и как выводить?

Тема в разделе "Базы данных", создана пользователем danneo, 7 янв 2013.

Статус темы:
Закрыта.
Модераторы: latteo
  1. danneo

    danneo Честный

    Регистр.:
    13 ноя 2007
    Сообщения:
    1.418
    Симпатии:
    109
    Есть категории. Нужно сделать у фирм товары, которые создаются в этих категориях. Но товары не любые, а только те, что создал админ. Админ создал категории (одна таблица) и прикрепил к ним товары (товары другая таблица).
    А фирмы выбирают категории (отмечают их чекбоксом, чтобы быстрее), далее отмечают какие товары у них на фирме есть, и ставят им цену (пара полей).
    Далее на странице фирмы выводятся категории и товары в этих категориях (которые они отметили) с ценой. При желании фирма открывает страницу и может изменять галочки, цены, когда товар продаст или изменится цена. А также админ должен иметь возможность редактировать категории, список в них товаров (удалять неактуальные, переносить, добавлять), поэтому данные фирм должны как-то зависеть от списка админа, а не сами по себе.
    Вот такая вот задача. Проблема в том, что есть массивы, которые не знаю как хранить, как правильно. Поиск по массивам я плохо знаю, точнее сказать, вообще не знаю. И возникают проблемы на функциях то с одной стороны (у компании), то с другой (у админа). Думал много, придумал разное, но ничего окончательного...
    Например, как вывести фирме ее товары для правки, в каком виде хранить все товары фирмы.

    Категории фирмы, как я понимаю, можно или через массив (сериализованный массив), записав его в поле фирмы или сделать отдельную таблицу (id, id_company, catid) и в нее пихать по отдельной записи для каждой категории все категории фирмы и всех фирм. Но будет много записей. Например, 30 категорий х 5000 фирм 150 000 записей. И это минимум. С массивами вроде как меньше будет 5000 всего.

    Далее, как товары хранить. То ли отдельную таблицу, как в обычных интернет-магазинах, то ли в массиве. Мысль такая, что завести таблицу (id, catid, price, desc, active), и запихать также все отмеченные фирмой товары в нее, каждый товар, как отдельная запись. Но возникает снова проблема - много записей. Например, 100 товаров х 5000 фирм = 500 000 записей вместо 5000 массивов.

    Пример известный - маркет яндекса, где выводятся фирмы, которые продают тот же товар.

    Что делать, не знаю даже. Подскажите, пожалуйста, кто умеет строить структуры баз.
     
  2. recasher2k12

    recasher2k12

    Регистр.:
    19 фев 2012
    Сообщения:
    156
    Симпатии:
    78
    На какой платформе это будет реализовываться и какая БД используется?
    Количество строк в таблицах (млн. или более) не имеет большого влияния на нагрузку, если правильно спланировать индексы. Для этого нужно сначала составить все запросы к БД (чтобы именно под эти запросы создавать индексы). Каждый индекс тормозит работу сервера БД на запись и ускоряет на выборку.
    Большие таблицы важно создавать таблицы с фиксированной длиной строки.
    Иногда, чтобы все это работало и не тормозило при нагрузках, лучше загрузить данные в оперативную память (можно использовать memcached), разместить ссылки (в си указатели) между объектами вместо id.
    Используя python memcached использовать не обязательно.
    Я же использовал бы node.js.
     
  3. danneo

    danneo Честный

    Регистр.:
    13 ноя 2007
    Сообщения:
    1.418
    Симпатии:
    109
    MySQL + PHP
    похоже на яндекс.маркет не нужно, т.к. не будет такого поиска по параметрам. Нужно сделать более простой функционал - показ предложений фирм, которые размещены в категории и имеют данный товар.
     
  4. ruslod

    ruslod Писатель

    Заблокирован
    Регистр.:
    23 дек 2012
    Сообщения:
    25
    Симпатии:
    0
    Самое простое и правильное решение - создание таблицы категорий и таблицы товаров. Совеременные СУБД типа MySQL прекрасно справляются с огромными таблицами. Естественно, при большом количестве полей нужно в базе расставить индексы на полях. Поиск в отдельных массивах будет дольше.
     
  5. chiief

    chiief Писатель

    Регистр.:
    1 ноя 2011
    Сообщения:
    8
    Симпатии:
    3
    может я что не допонял, как-то сумбурно изложена задача ))), но все же таблицы отдельной с минимальными полями типа ИдТовара, ИдМагазина, Прайс не избежать
    поскольку это составной уникальный ключ конкретного предложения продавца.
    бояться большого количества записей в таблицах подобных структур нет смысла

    вдогонку
    категории это внешняя таблица к товарам, на задачу саму это не влияет, поскольку как вы пишете, все равно будут чекбоксы по конкретным товарам, так что категория будет задействована просто для удобства выбора
     
  6. Андрей Шпак

    Андрей Шпак Создатель

    Регистр.:
    11 фев 2013
    Сообщения:
    43
    Симпатии:
    7
    Сразу вопрсо - сколько категорий будет?
    Категория - это только название или еще чтото? в любом случае - лучше в таблицу-справочник каких-нибудь простых характеристик . пусть там поле еще дополнительное будет - типа инт и смысла - что за характеристика - например 1 - категориии товара, 2- виды лояльности покупателей (к примеру-может нужно :))
    товары-конечно же в таблицу! А может даже и не в одну- смотря какие у них свойства требуются и намечающийся учет.
    а также в таблицу покупателей и заказы. причем в разные таблицы и в несколько их!
    это позволит потом как оперировать данными, так и вести аналитику и учет какой-то.
     
  7. kinhead

    kinhead Создатель

    Регистр.:
    23 фев 2013
    Сообщения:
    40
    Симпатии:
    11
    вы что-то перемудрили. про какие массивы вы говорите? большинство веб-сайтов используют таблицы mysql. Данные хранятся в таблицах. Создайте таблицу категорий товаров, таблицу фирм и таблицу товаров. Данные по ценам и наличию у разных фирм я бы хранил в дополнительной таблице - одна запись - одна цена (ид товара, ид фирмы, цена).
    И не пугайтесь 150к записей это не так уж и много.
     
  8. Шумадан

    Шумадан Хабарра!!11

    Регистр.:
    6 фев 2008
    Сообщения:
    1.722
    Симпатии:
    2.097
Статус темы:
Закрыта.