Аналогичный вопрос обсуждался тут, но мне надо расширить решение:
Есть реализация схемы “товар” -> “параметр” -> “значение”:

tovar
id tovar
1 computer
2 player
3 phone

tovar_param
id tovar_id param
1 3 color
2 1 cpu
3 3 screen
4 3 color

values
id param_id value
1 1(color) blue
2 2(cpu) 2GHz
3 3(screen) 3“
4 4(color) red


Со стороны интерфейса такая схема предполагает ввод значение параметра ручками в текстовое поле.
Вопрос:
1. как к существующей схеме ”прикрутить“ еще параметры, для которых есть ограниченный набор значений и чтобы предоставить пользователю выбрать его из списка.
например добавить параметр ”производитель" со значениями: samsung, sony, iriver, apple
2. или как изменить текущую схему, чтобы получить тот же результат.

Как вариант создать словари значений для параметров:
param value
vendor samsung
vendor sony
vendor iriver
vendor apple
Но это решает только половину проблемы, а именно проблема ввода данных - смогу предоставить пользователю список возможных значений. Остается проблема хранения, получается избыточность данных: в таблицу values буду попадать дублирующиеся строковые данные, а не айдишники

Спасибо.

Для tovar_param нужно еще 2 поле - тип и откуда брать значения подстановки (отдельные таблицы).
В зависимости от типа, из соответствующей таблицы формируем список для выбора и в таблицу values записываем ключи выбранных значений.

У меня в одном приложении есть доп. возможности для формирования списка выбора: перечень полей, форматирование, условия отбора и пр.

Lexander
Для tovar_param нужно еще 2 поле - тип и откуда брать значения подстановки (отдельные таблицы).
В зависимости от типа, из соответствующей таблицы формируем список для выбора и в таблицу values записываем ключи выбранных значений.

В таком случае в поле value таблицы values будут вперемешку и конечные значения параметров, и айдишники ?

Это вариант, интересно получится ли средствами Джанго ОРМ эти данные выгребать или придется писать вручную запросы.

fanat1k
В таком случае в поле value таблицы values будут вперемешку и конечные значения параметров, и айдишники ?

Ну, собственно, к этому ведь и стремились - записывать ID и уменьшить объем таблиц, не так ли? :)

Желательно (но не обязательно) унифицировать тип данных, который будет хранится в values. Как обычно, бесплатно ничего не бывает. :)

ЗЫ
Я видел разные рабочие решения:
1). Заводили несколько таблиц значений - по числу типов хранимых данных. Это нужно было для полностью автоматической работы движка, который умел обрабатывать такую структуру.
2). Хранили значение ID, даты и пр. в виде строки или BLOB - 1 таблица значений. Движок конвертирует данные на лету. Со временем у них начались предсказуемые проблемы с производительностью.
3). Хранили значение, приведенное к типу float (это позволял набор данных, быстрый подвид п.2)
4.) Заводили несколько полей разных типов в таблице значений.

Спасибо за помощь.
Еще не реализовал, но думаю проблем возникнуть не должно.