|
Все не так. Начинается все с проектирования базы данных и если говорить даже только о стеновых панелях, то они есть: фасадные, для кухонь и ванных, металл, МДФ, ДВП, характеризуются по ширине, высоте, толщине, различных текстур, производитель, и т.д., и т.п., и конечно же имеют цену.
Если все это многообразие описывать так как вы приводите, то с расширением номенклатуры с такой базой и умереть не долго. Если все описывать в одной таблице, то в базе неизбежно будут дублирующие на все 99% друг друга записи. А должно быть:
Таблица материалов, в которую всегда легко добавить новый, и каждая запись в ней не под "sm" и "sp", а под уникальным идентификатором который формируется автоматически средствами самой базы. И это число, по которому SQL сделает выборку, отфильтрует или отсортирует данные гораздо проворнее, нежели копаясь с "sm", "sp" и еще бог весь чем.
Есть таблица в которой содержатся текстуры и также под уникальным идентификатором. Вот только если бы текстура была чисто ею, рисунок которой можно было бы смешать с любым цветом (это вообще-то сделать можно), тогда был бы резон хранить изображения текстуры отдельно, а какие-то картинки с цветом (не понятно какие и зачем). В противном случае выгоднее конечные изображения одной текстуры различных цветов, только разделяя их по плотности/тону от светлых до темных.
Цена панели вряд ли зависит от текстуры и цвета, а значит выгоднее имеющиеся цветовые наборы хранить не отдельной таблице, а сводной таблице полем типа ENUM, которое имея строковые значения во внутреннем представлении являются числами, и которые можно расположить от светлых до темных значений цвета.
Есть таблица производителей, брендов, которых можно группировать по стране производителя, и это также по уникальными идентификаторами. Могут быть и еще таблицы описывающие другие характеристики, например тип соединения и прочее.
И есть сводная таблица, в которой собственно перечислены идентификаторы таблиц характеристик определяя таким образом какие наборы панелей имеются в наличии. В этой таблице указывается цена панели, которая может зависеть от размеров, которые также можно описывать полем типа ENUM.
Выбор пользователя при этом будет возвращать значения полей формы как идентификаторы наборов и под именами/ключами, которые указывают на поле SQL таблицы, которым принадлежат эти идентификаторы. А это значит, что данные на клиенте должны представлять собой объект не с массивами (как в примере, что вы пытаетесь использовать), а с объектами, или в случае последовательного получения различных характеристик панелей, каждый ответ сервера, это объект на клиенте, из которого строится очередной список.
Даже в случае небольшого объема данных с небольшим набором характеристик, что еще как то можно описать одной таблицей, в которой выгодно будет использование ENUM, возвращение только одной характеристики описываемой таким полем, это объект, где внутреннее представление (число) это свойство, а текст его значение.
Если вам кажется, что это сложно и слишком громоздко, а проще "sm", "sp" и так мне удобнее ибо легче запомнить, то это заблуждение. Одно понятие "человеческий фактор" может превратить эту кажущуюся простоту в причину мучений.
И только тогда, когда будет разработана база данных отвечающая всем задачам, которые требуются для их обслуживания и запросам клиентов, можно решать вопросы интерфейса для клиентов и административного управления.
Вот типа такого.
|