Регистрация
Вход через соцсети
Восстановление пароля

Как лучше сделать свойства

Новый топик
01.05.2012, 17:36
Ответить | Цитировать
Гость
Гость

На примере магазина
надо: товары в одной базе, админимтрирование в одном месте
НО скажем у холодильника и ТВ разные свойства
И есть одинаковые поля: артикул, название, цена
так вот различия хотелось бы реализовать одной какой-то сущностью, которую можно настраивать под конкретный объект
скажем для ТВ размер диагонали, тип: трубка/плазма, 3D|2D и т.д.
Холодильник объем морозильной камеры, мин темпиратура и т.д.
Вот эти различия в объектах как лучше организовать?
Где-то надо хранить данные и где-то надо хранить настройки.
01.05.2012, 17:55
Ответить | Цитировать
Asiat
Аниматика
Asiat

Зарегистрирован:
2005-12-12
Сообщений: 567

Вряд ли есть однозначный ответ, все будет зависеть от нюансов конкретного проекта.
Где-то проще хранить прямо в одном компоненте (это проще в администрировании). Иногда имеет смысл выносить свойства в отдельные списки/компоненты.
Зависеть может от общего количества товаров, удобства работы поиска по параметрам...

Разработка сайтов на Netcat с 2006... хм-м ... или 2005 хммм года. В общем, обращайтесь.
02.05.2012, 23:41
Ответить | Цитировать
DiGGy
DiGGy
DiGGy

Зарегистрирован:
2005-04-04
Сообщений: 1546

Универсальное решение - это наличие следующих компонентов:
1. Каталог товаров.
2. Группы товаров.
3. Св-ва по каждой группе товаров.
4. Возможные справочные значения св-в (не обязательно).
5. Значения св-в с привязкой к товару.

Temet nosce...
03.05.2012, 07:07
Ответить | Цитировать
Гость
Гость

Группы товаров можно реализовать как подразделы, но один минус отсутствие API по добавлению разделов, а руками писать проблематично, после обновления кол-во полей может изменится, можно конечно делать запрос о наличии полей, но опять же придется угадывать со значениями.
03.05.2012, 15:28
Ответить | Цитировать
Asiat
Аниматика
Asiat

Зарегистрирован:
2005-12-12
Сообщений: 567

Цитата:
Универсальное решение - это наличие следующих компонентов:
1. Каталог товаров.
2. Группы товаров.
3. Св-ва по каждой группе товаров.
4. Возможные справочные значения св-в (не обязательно).
5. Значения св-в с привязкой к товару.

По скорости выборки не сравнивали?
Мои личные тесты (как-то раз сам делал, когда было не лень этим заниматься) с искусственно накачанной базой в полмиллиона товаров показали гораздо лучше результаты по выборке, когда она шла по одному компоненту, чем по двум, не говоря уже о большем количестве... Запросы брались почти стандартные, только добавлялись $query_from и т.д., все индексы присутствовали...
Я имею в виду выборку с поиском по параметру.

Разработка сайтов на Netcat с 2006... хм-м ... или 2005 хммм года. В общем, обращайтесь.
03.05.2012, 21:48
Ответить | Цитировать
DiGGy
DiGGy
DiGGy

Зарегистрирован:
2005-04-04
Сообщений: 1546

Скорость выборки на порядок увеличивается, если создать необходимые индексы улыбка
Причем количество записей в таблице на скорость влияют мало, ибо на страницах обычно выводится 1 товар, а не полмиллиона. Сравнение товаров может чуть дольше работает - тут зависит от кол-ва сравниваемых товаров и кол-ва их характеристик - но это на "скорость" особо не влияет.

Temet nosce...
04.05.2012, 08:34
Ответить | Цитировать
Гость
Гость

Код:
Скорость выборки на порядок увеличивается, если создать необходимые индексы

Про индексы можно поподробнее, то что создает неткат этого разве не достаточно?
04.05.2012, 11:09
Ответить | Цитировать
DiGGy
DiGGy
DiGGy

Зарегистрирован:
2005-04-04
Сообщений: 1546

Подробнее про индексы лучше в мануале mysql посмотреть (какие есть индексы, как они работают и т.д.)
Имеющиеся индексы на таблицу можно посмотреть запросом:
Цитата:
show index from {имя_таблицы}


Достаточно этих индексов или нет - это уже решает сам разработчик сайта в конкретной своей задаче. Может быть даже такое, что существующих индексов МНОГО (чем больше индексов, тем дольше время добавления/удаления записи - ибо надо помимо самой записи еще и индексы перестроить).

Если рассматривать пример с решением задачки по свойствам, то таблицы надо связывать между собой. В идеале это лучше делать через создание внешних ключей (foreign key), чтобы более жестко контролировать целостность данных.

Как мимнимум в таблицах надо создать поля для связки товара, свойств, значений свойств и т.д. Соотв-но на эти "связывающие" поля надо создать индексы, ибо в каждом sql-запросе вы будете использовать эти поля в качестве поиска (т.е. select ... from ... where ... {имя_поля}=ХХХ)

Есть еще и другие нюансы в оптимизации самих запросов, как пример можно почитать тут.

Temet nosce...
198 196 2012-05-04 11:09:35 12076
Описание проекта