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

← на Главную / Разработчикам / Форум / Разработка сайта

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

		01.05.2012, 17:36
	Гость Гость	На примере магазина надо: товары в одной базе, админимтрирование в одном месте НО скажем у холодильника и ТВ разные свойства И есть одинаковые поля: артикул, название, цена так вот различия хотелось бы реализовать одной какой-то сущностью, которую можно настраивать под конкретный объект скажем для ТВ размер диагонали, тип: трубка/плазма, 3D\|2D и т.д. Холодильник объем морозильной камеры, мин темпиратура и т.д. Вот эти различия в объектах как лучше организовать? Где-то надо хранить данные и где-то надо хранить настройки.
		01.05.2012, 17:55
	Asiat Аниматика Зарегистрирован: 2005-12-12 Сообщений: 576	Вряд ли есть однозначный ответ, все будет зависеть от нюансов конкретного проекта. Где-то проще хранить прямо в одном компоненте (это проще в администрировании). Иногда имеет смысл выносить свойства в отдельные списки/компоненты. Зависеть может от общего количества товаров, удобства работы поиска по параметрам... Разработка сайтов на Netcat с 2006... хм-м ... или 2005 года. В общем, обращайтесь.
		02.05.2012, 23:41
	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 Аниматика Зарегистрирован: 2005-12-12 Сообщений: 576	Цитата: Универсальное решение - это наличие следующих компонентов: 1. Каталог товаров. 2. Группы товаров. 3. Св-ва по каждой группе товаров. 4. Возможные справочные значения св-в (не обязательно). 5. Значения св-в с привязкой к товару. По скорости выборки не сравнивали? Мои личные тесты (как-то раз сам делал, когда было не лень этим заниматься) с искусственно накачанной базой в полмиллиона товаров показали гораздо лучше результаты по выборке, когда она шла по одному компоненту, чем по двум, не говоря уже о большем количестве... Запросы брались почти стандартные, только добавлялись $query_from и т.д., все индексы присутствовали... Я имею в виду выборку с поиском по параметру. Разработка сайтов на Netcat с 2006... хм-м ... или 2005 года. В общем, обращайтесь.
		03.05.2012, 21:48
	DiGGy DiGGy Зарегистрирован: 2005-04-04 Сообщений: 1546	Скорость выборки на порядок увеличивается, если создать необходимые индексы Причем количество записей в таблице на скорость влияют мало, ибо на страницах обычно выводится 1 товар, а не полмиллиона. Сравнение товаров может чуть дольше работает - тут зависит от кол-ва сравниваемых товаров и кол-ва их характеристик - но это на "скорость" особо не влияет. Temet nosce...
		04.05.2012, 08:34
	Гость Гость	Код: Скорость выборки на порядок увеличивается, если создать необходимые индексы Про индексы можно поподробнее, то что создает неткат этого разве не достаточно?
		04.05.2012, 11:09
	DiGGy DiGGy Зарегистрирован: 2005-04-04 Сообщений: 1546	Подробнее про индексы лучше в мануале mysql посмотреть (какие есть индексы, как они работают и т.д.) Имеющиеся индексы на таблицу можно посмотреть запросом: Цитата: show index from {имя_таблицы} Достаточно этих индексов или нет - это уже решает сам разработчик сайта в конкретной своей задаче. Может быть даже такое, что существующих индексов МНОГО (чем больше индексов, тем дольше время добавления/удаления записи - ибо надо помимо самой записи еще и индексы перестроить). Если рассматривать пример с решением задачки по свойствам, то таблицы надо связывать между собой. В идеале это лучше делать через создание внешних ключей (foreign key), чтобы более жестко контролировать целостность данных. Как мимнимум в таблицах надо создать поля для связки товара, свойств, значений свойств и т.д. Соотв-но на эти "связывающие" поля надо создать индексы, ибо в каждом sql-запросе вы будете использовать эти поля в качестве поиска (т.е. select ... from ... where ... {имя_поля}=ХХХ) Есть еще и другие нюансы в оптимизации самих запросов, как пример можно почитать тут. Temet nosce...