Правильно ли весь этот товар хранить в одной таблице базы или это считаются разные сущности ?Хранить в одной.
Потому что они будут фигурировать в одних и тех же документах (складских, товарных и пр.).

Могут быть доп. признаки. Но это не причина разносить по разным сущностям.

тем не менее, имеет специфический функционал (бизнес-логика совершенно иная). И что ? Для этого у карточки есть признак. У товаров тоже есть разные признаки, но это не повод делать для каждого типа отдельную таблицу.

SergueiLSV Для этого у карточки есть признак.

У какой карточки? Какой признак? Не надо путать визуальную часть приложения со структурой БД.У карточки товара, т.е. у записи в сущности-таблице. У бизнес-сущности (товар/контрагент/пользователь/справочник) в одной из таблиц есть главная запись с ID.

Разные записи могут отличаться признаком: товар/услуга/сырьё/ресурс и пр. Это определяет состав признаков во вспомогательных таблицах. Соотв. определяет внешний вид интерфейса.

Нужно иметь серьезные основания, чтоб создавать отдельную сущность-таблицу.
"Билет в кино" до таких оснований никак не дотягивает. Это товар или услуга.

зы: как-то нестройно получилось объяснить. :(

SergueiДы? А например в какой кинотеатр, на какой фильм, на какой сеанс где хранить?
Жутко интересно,что вы сейчас предложите )))Для товара всегда есть документы реализации (фиск.чек, расх.накладная и т.п.).
Вот там и указывают и фильм и сеанс и место.
Это если реализовывать на базе готового торгового ПО, например в случае внедрения эдакого единого решения для ТРЦ.

В специализированном "билетном" ПО нет необходимости решать, товар это или ч-л еще.

Кот МатроскинВы в кино не ходили никогда, что ли? :)
Цены отличаются в зависимости от сеанса (уж не говоря от кинотеатра) - поэтому это, конечно же, атрибуты товара, а не факта реализации.Ой, да ладно ! Капитан очевидность, да ? :)
Какая проблема подтянуть в документ реализации некие условия для формирования цены ?
Может быть вполне достаточно набора цен и коэффициентов у сущности "сеанс".

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

Конечная цена слабо связана с карточкой товара. Может быть вообще не связана.

Кот Матроскин Напоминаю, Вы начали с того, что "билеты в кино" - это просто товар, от силы с несколькими дополнительными признаками, никаких дополнительных сущностей не надо .
А сейчас мы видим, что уже всплыла дополнительная сущность "сеанс", у нее наборы цен и коэффициентов - и кто знает, что всплывет еще.
Не такой уж, оказывается, "просто товар"? ;)Включил дурачка ?
Мой 5-й сверху пост: "Могут быть доп. признаки".
Эти признаки могут быть где угодно. В куче доп. таблиц.

SergueiLSVЭти признаки могут быть где угодно. В куче доп. таблиц.
Бугагага )) Никогда не понимал людей, которые противоречат сами себе.
LSVНужно иметь серьезные основания, чтоб создавать отдельную сущность-таблицу.
"Билет в кино" до таких оснований никак не дотягивает.Юноша, у Вас слишком мало постов, чтоб что-то тут утверждать... :)

Ты видимо перепутал главную таблицу для хранения собственно сущности с ее ID и вспомогательные таблицы.

Например сущность "накладная" может состоять из десятка таблиц: главной таблицы с ID и вспомогательных таблиц (обычно это спецификации).
Только простые сущности могут уложиться в одной таблице.
Некот.таблицы могут хранить данные для совершенно разных сущностей (н-р тот же EAV).

В нашей дискуссии есть проблема с терминами. Вот и всё.
Для начала вспомните стартовый пост и ответьте на его вопрос.