Здравствуйте. Возникла необходимость доработать Virtuemart, а именно... Нужно сделать список значений товара. Этот список должен быть редактируемым. Сразу оговорюсь, что стандартный функционал не подходит. Примерно так я себе это представляю: Заходим в Вирт, там есть уже добавленная дополнительная ссылочка "Свойства товара". Переходя по этой ссылке мы видим перечень свойств, который можем отредактировать, удалить или добавить новое свойство (вес, высота, глубина, ширина, степень идиотизма и т.д...). Отредактировать можно название свойства и степень измерения (кг., мм, см и т.д). Добавляем, к примеру, свойства: Вес и Ширина. Далее открываем любой товар и на заранее созданной дополнительной вкладке видим перечень добавленных свойств и можем указать свои значения. Сама реализация более-менее ясна. Вопрос стал в том, как правильно организовать структуру БД, если можно так выразиться. Я рассматривал такие варианты: Вариант 1. Создаём таблицу jos_vm_param, такого вида: param_id | param_name | param_izm ------1------|----------Вес----|-------кг ------2------|--------Длина--|-------мм И вторую табличку, например jos_vm_param_prod куда пишем значения: param_id | prod_id | param_atr -----1-------|-----138--|-----1.5 -----2-------|-----138--|-----400 Ну и так далее. Приемлем ли такой метод? Вариант 2. Писать всё в одну таблицу jos_vm_product_param, например так: prod_id | param_ves | param_dlina | param_stepen_idiotizma ---138----|-----1.5 кг---|-----400 мм--|---------------10% ----24-----|-------3 кг.--|-----1.5 м-----|--------------- 40% Т.е в данном случае при добавлении нового свойства мы просто добавляем столбец в данную таблицу, a когда заполняем данные для продукта, то эти столбцы, соответственно заполняем. Каким путём будет правильней пойти? Вторым? UPD: Сейчас сижу, читаю что написал и понимаю, что второй вариант не подходит... Куда я буду писАть наименование параметра?
Привет, woojin, давно не виделись )) А как думаешь, не сильно нагрузит БД? ведь если параметров будет 10, к примеру, то для каждого продукта нужно будет сделать 10 записей. Если продуктов 500, то это уже 5000 записей в БД. Потом же нужно будет их все перебрать, чтобы вывести для каждого продукта свои значения во flypage
привет!! а работу VM анализировал? там знаешь сколько перекрёстных таблиц?! так что не парься с этим, ну увеличится у тебя запрос на 0.0005 секунды и будет так увеличиваться какждые к примеру 1000 записей - сильно ты таким сервер не нагрузишь, у него всё равно минимум время ожидания отклика 60 секунд, а у VM (с его перегруженными запросами) время обращения к БД примерно 3-5 секунд МАКСИМУМ я такую нагрузку видел не на очень хорошем (но дешевом) хостинге при условии что в БД было порядка 8-9 тысяч товаров, а эти самые товары импортировались из 1С примерно 2.5 секунды так что делай и не мучайся
Есть 3й, мене поворотливый вариант. param_name|param_izm|prod_id |param_atr ---------Вес-----|-------кг-------|-----138--|-----1.5----- --------Длина--|-------мм-----|-----138--|-----400---- Не думаю, что его можно рассматривать как серьёзный.
gft, о кстати у Legolazzzzz, хорошее предложение, кстати можешь попробовать это возможно будет лучшим вариантом
Рассматривал. В варианте Legolazzzzz придётся каждый раз писать в базу param_name и param_izm. И потом, как добавлять новые параметры? Сразу прописывать для продукта, с нулевыми значениями? Мне кажется, это чересчур громоздко. Уже практически сделал всё, остался один момент. Как отследить нулевое значение отправляемое из input? Есть поле для ввода значения параметра. Если в поле введены данные, то записать их в базу. Если данные не введены, то удалить имеющуюся запись. Завис именно на условии if и else. НЕ могу сообразить что прописать для "if".
Нет. Я не сторонник того, чтобы хранить пустые, неиспользуемые записи в базе. Например, если в одном товаре будут использоваться параметры Вес, Длина и Ширина, а в другом они не будут использоваться вообще никогда, то в случае Legolazzzzz всё равно придётся их хранить в базе со значением NULL. Это, конечно, не сыграет большой роли, но тем не менее это неправильно ))
в БД вообще много в каких таблицах храниться NULL и ничего!!! его вариант менее затратен на дисковое пространство и на процессорное время для поиска и "выцепляния" нужных данных, нежели если сделать две таблицы и потом их соединять запросом ну думать тебе - но мнения ты слышал!!!
Мог бы поспорить. Дисковое пространство тут вообще роли никакой не играет, т.к. база занимает минимум пространства по сравнению с файлами. А по времени - две таблицы используются только в админке, когда мы добавляем параметры для товара. Соответственно нагрузка здесь кратковременная и тоже не страшна, по сути - любой хостинг справится. Как вариант - имеет место быть, возможно кто-то бы сделал именно так, но мне, после обдумывания и рисования схемы на бумаге, показался более удобным именно первый вариант. Согласен, я и не говорю что это критично. Но более правильно - не хранить пустые значения. Просто потому, что они не нужны и нигде не используются...
Вариант Legolazzzzz может иметь место. Создается поле params (на примере таблицы jos_users) и там перечисляются нужные параметры. В ядре есть методы специально сделанные для создания и разбора этих полей. Сейчас не вспомню, но что-то вроде setParams и getParams. Но не считаю этот вариант правильным, т.к. если после заполнения 10 000 товаров захочется поменять название параметра с Степень Идиотизма на Степень Дебилизма, придется переписывать всю таблицу. А во втором варианте нужно будет изменить всего лишь одну запись.
В первом варианте нужно сменить лишь одну запись, чтобы поменять имя параметра. Собственно, по нему и было сделано ))
