Евгений Вольф: скорее первое, потому что контентщик наполнять это не будет. Эти данные будет собирать скрипт. Грубо говоря. Есть магазин автозапчастей. У любой запчасти есть понятие каталожного номера (артикула), бренда, описания и так далее. Многие артикулы являются аналогами или заменами друг друга. Есть такая БД как TecDoc в которой можно все это дело искать. Но... Не все в текдоке есть. Многих производителей с их предложениями там нет, особенно отечественных. Надо все это дело как то искать. Поэтому есть идея по предложениям от поставщиков в автоматическом режиме собирать данные по аналогам. Но как реализовать их хранение, чтобы потом всем этим безобразием было удобно пользоваться...
А если совместить первый и второй вариант? Ну например. Заводим линковочную талицу, где поля id и уникальный_линк. И заводим другую таблицу. И в случае "сложной линковки" брать данные из нее?
diamond: как понять "Уровень кроссирования"? Возьмем к примеру два масляных фильтра на один авто. Какой у них уровень кроссирования? единица? А вторым уровнем кроссирования будут составные части фильтра? А третьим составные части составных частей? Я правильно понимаю? И как тогда сделать базу с таким уровнем?
Макс: Думаю, такого быть не должно, поэтому скорее всего данное решение и использую. А как лучше связывать, не подскажете? Через отдельную линковочную таблицу, или прямо в таблице товара поле для линка завести?
AlikDex: Вот именно. Что это нормально. Зачем для рядового проекта миллион лишних строчек кода, которые заведомо никогда не будут использованы в данном проекте?
Фиксированное позиционирование мне кажется плохое решение. Высота футера 170px все таки. И это 170px будут контент постоянно перекрывать...
Да тут опять этот самый ScrollTop. Не работает он в хроме если у хтмл и боди высота в 100%
OR это ИЛИ. А мне надо И. И тот и другой параметр. А возможно и третий и пятый и десятый.
В общем то я нашел решение через IN. Выглядит это примерно так WHERE ps.`id_category`=1 AND ps.`id_param_value` IN(a. b, c) AND ps.`id_param_name` IN (x, y, z) GROUP BY 1 HAVING COUNT(*)=3
где a, b, c - id Значений параметров из таблицы param_values, x, y, z - id самих параметров. 3 - количество аргументов в IN(). Но как это работает и по какой логике - сам не пойму.
Кирилл: Данных много. Одна бд по грубым прикидкам будет 50гб занимать. Хостинг столько места не предоставляет. А еще же и изображения где то надо хранить
Кирилл: скрипт на php за данными ходит - я пхпшник-говнокодер:). Магазин сейчас крутится на обычном хотсинге он спайсвеба. Предложения по товарам мне отдает поставщик через веб-сервисы. Но он отдает только наименование товара, цену, остаток по складу. Люди приходят, но им надо соотвественно фоточки посмотреть, описание почитать, характеристики сравнить. У поставщика вся эта информация есть, ее можно получить. Но только всю и сразу а не по отдельному товару. Я рассчитывал сделать так: покупаю сервер. Перегоняю инфу по товарам в MySQL или др базу данных. На серваке будет крутится скрипт, который по запросу например "Флешка кингстон 8гб" выберет из базы информацию по этой флешке и отдаст ее. Скрипт магазина будет обращаться к серверу по... да хотя бы через те же веб-сервисы.
Реально это сделать? И какие мощности нужны?
Сейчас вот на виртуальной машине с БД играюсь, на таблице с 2м позиций, если позиции под индексами, ответ занимает 0.2 секунды
Спасибо. Всерьез задумался, что же все таки делать... 50гб - объем базы. 4 миллиона позиций + таблицы характеристик, сопоставлений. Получается VPS нужен с 100гб диском минимум. (50гб смело уйдет под хранение изображений). Где бы такой найти?
hime2: У меня нет возможности оплачивать VDS/VPS в настоящий момент. Ну не приносит магазин 1500 в месяц на оплату хостинга. И не принесет, если нормальной карточки товара с характеристиками товара не будет. Получается замкнутый круг =) Денег на сервер нет=>данные хранить негде=>нет данных=>нет карточки товара=>нет дохода=>goto пункт 1