[SQL] Записи о товарах в одной таблице, их описания - в других (разных) - как правильно?

Таблица свойств.
Каждому item'у может соответствовать от 0 до много свойств, для этого можно использовать промежуточную таблицу, где будут item_id, идентификатор свойства и значение.

Я бы сделал как-то так, но в SQL опыта практически нет.

Если бы все товары были одинаковые и обладали бы одинаковым набором свойств, то вопроса бы не было. А вот как мне записать, что «банан» надо искать по такому-то id в таблице с бананами, а «напильник» - по такому-то id в таблице с напильниками?

Можно не расписывать, а дать ссылку.

Если бы все товары были одинаковые и обладали бы одинаковым набором свойств,

А таблица со свойствами ничего и не знает про то, какие поля должны быть у каждого конкретного продукта

в таблице items у тебя есть item_id item_name item_price 1 banan 100

и в другой таблице item_properties item_id prop_name prop_value ..... 1 цвет звеленый

И не нужно никаких отдельных таблиц для бананов и напильников, просто select prop_name, prop_value from item_properties where item_id = 1

Блин, а действительно же.

Это при том, что аналогичные конструкции у меня уже есть. Замылился, похоже. Спасибо.

1) Можно делать table inheritance

2) В СУБД может быть тип данных, позволяющий хранить произвольные данные (например, hstore или json в PostgreSQL)

В идеале хотелось бы, чтобы схема работала и для SQLite+Tcl/Tk, и для Postgresql+морды на Perl. Так что на всякие специфичные для СУБД вещи полагаться не приходится.

Но всё равно, конечно, спасибо.

А по этому json потом искать удобно ли? Сортировку бананов по спелости там, если припрёт?

посмотри в сторону entity-attribute-value model или в сторону content repository (напр. JCR)

А по этому json потом искать удобно ли? Сортировку бананов по спелости там, если припрёт?

Да, удобно (и индексами тоже поддерживается). (Жаль, что json будет в PG 9.2).

EAV - то, что нужно! В википедии отличная вводная статья на эту тему, наверное, несколько мест в базе переделаю под такой подход, и это позволит добавлять описания «на лету».

Статья, в частности, похоже, сэкономила мне много времени и нервов - конечно же я сразу ломанулся совать метаданные в ту же таблицу, что плохо.

EAV - то, что нужно!

Я бы советовал держаться подалье от EAV, если есть такая возможность. Например, при использовании EAV достаточно неудобно делать запросы к БД; неудобно задавать ограничения; все надо приводить к одному типу.

Ох, бида-пичаль, что-то про него действительно много плохого говорят (store all, query nothing). А такое прекрасное описание.

Ладно, у меня тут VPS нарисовался с гигабайтом оперативы, так что постгрес на нём должен себя нормально чувствовать, попробую, так сказать, придерживаться классики. Может быть, действительно в json всё упихаю, а может быть воткну костыль на уровне контроллера. Учиться-то надо.

Ещё я, честно говоря, надеялся найти модули для работы с такими таблицами на CPAN, учитывая, что их применяют биохимики, а Perl вроде в биохимии используется, но фиг там.

В Postgresql есть наследование таблиц. А страну производителя надо знать для всех товаров

Остановился, после изучения сложных революционных техник хранения информации и постгресоспецифических фич на самом дубовом подходе, который объясняется в пособиях ещё раньше, чем join - одна «каталожная» таблица и отдельные таблицы для каждой группы товаров, вот так:

CREATE TABLE main_catalogue (
    item_id SERIAL PRIMARY KEY,
    purchasing_price NUMERIC(2, 8) NOT NULL,
    selling_price NUMERIC(2, 8) NOT NULL,
    origin VARCHAR(60) NOT NULL
);

CREATE TABLE bananas (
    catalogue_number INTEGER NOT NULL REFERENCES main_catalogue(item_id)
        ON UPDATE CASCADE ON DELETE RESTRICT,
    size INTEGER NOT NULL,
    ripeness VARCHAR(20)
);

CREATE TABLE hammers (
    catalogue_number INTEGER NOT NULL REFERENCES main_catalogue(item_id)
        ON UPDATE CASCADE ON DELETE RESTRICT,
    handle_material VARCHAR(20) NOT NULL,
    hammer_material VARCHAR(20) NOT NULL,
    claw BOOLEAN NOT NULL DEFAULT 'f'
);

Подробнее здесь: onlamp.com/onlamp/2001/03/20/aboutSQL.html

А я конечно дурак, хорошо что хоть ленивый.