Сложно структурированные данные в MySQL

можно классифицировать информацию о товаре, в этом смысле с точки зрения mysql очень популярен тип tinyint(1) NOT NULL default '0' или по простому boolean. Например, товар - телефоны, телефон может обладать кучей свойств и примочек типа например наличия GPRS, в самом простом случае достаточно создать таблицу состоящую из столбцов а-ля has_gprs, has_wap, и т.д. или просто gprs, wap и т.д. значение 1 (true) будет соответветствовать наличию данной примочки, сообразно 0(false) ее отсутствию, для примочек которые характеризуются вторичными признаками, можно создавать дополнительные табицы, а в качестве самого признака использовать NULL в случае его отсутствия или число-ключ типа int(11) для обозначения внешнего ключа таблицы дополнительных параметров этой примочки(а можно и просто столбцов в таблицу добавить). Вообще SQL (и MySQL в частности) дает огромное многообразие вариантов построения конкретной базы данных, другой вопрос - её функциональность, т.к. сразу необходимо продумать добавление новых, пока не существующих свойств данного товара (для телефонов это очень думаю актуально, т.к. новые примочки появляются каждый день), так же продумать скорость базы данных, если все примочки товара слепить в одну здоровую таблицу она будет реально тормозить, будет много избыточных, пустых полей и т.д. и опять же если разбрасывать примочки по более мелким таблицам нужно продумать грамотную организацию ключей, и не раз все протестить на все операции бд, включая критические ака дамп и воостановление базы в случае сбоя, не стоит при этом думать что все работает по тому что вы добавили одну запись, потом стерли, потом добавили и вроде все нормально, MySQL не поддерживает транзакции! помните это (по крайней мере не поддерживала, сейчас может уже и поддерживает), т.е. всегда есть вероятность того, что база будет делать не то что вы от нее ждете и если вовремя этот момент не пофиксить стрессовым тестированием, то потом когда база заполнится будет очень сложно поймать ошибку и трудоемко ее исправить, т.к. придется работать с уже готовым множеством записей, а оно легко может достигать тысяч и даже миллионов записей даже на проектах со средней посещаемостью.
эээ, что-то я отвлекся от сути, короче админу в результате можно выдать форму html где ему нужно будет только проставлять свойства галочками есть/нет и вводить конкретные числа, если у данного свойства есть уточнения. А хтмл давать или не давать, это уже вопрос личных предпочтений, иногда бывает удобно подчеркнуть какое-нибудь свойство на лету добавив пару тегов, это уже кому как... хотя если этих админов больше 1 шт, то наверное все же лучше ограничить доступ к введению напрямую html, а если пишешь под себя, то почему бы не оставить такую возможность.
з.ы. прошу прощения за ошибки.

т.е. тебе по сути надо хранить то что называется запись или объект с заранее неизвестными свойствами?
посмотрев мануалу, я составил впечатление, что в MYSQL нет достойных структур данных для объектов. **или я их не нашел - т.е. имхо**
можно попробовать деревья, которые нынче очень удобно представлять методом nested sets.

//см. http://detail.phpclub.net/article/db_tree
http://www.codenet.ru/webmast/php/tree.php

так, листьями в дереве будут значения свойств, например 54мм, уровнем выше - сами свойства - например, толщина, а еще уровнем выше - товары. при желании, можно организовывать товары в подкатегории, подкатегории в категории, и т.д., каждый раз добавляя новый уровень к дереву.