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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

насколько я понял, вы предлагаете сделать товар или услугу (неважно пока) типа "Билет на сеанс 20:00 в кинотеатре "Синема" на фильм "Унесенные ветром""? Вы ничего не поняли. Нет, конечно.
В справочнике "товар" будет всего неск. билетов. Как вариант: Полный билет, детский билет, льготный билет. У них будут внятные названия для чека и некие коэф. для умножения цены.
В документе реализации будет признак "сеанс" со своими коэф. (например с пом. EAV)
При попадании товара в документ согласно коэф. будет формироваться цена. Ряд/место это доп. атрибут строки спецификации (опять таки с пом. EAV).

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

Если типов билетов может быть несколько (н-р в солярий, выставку или аквапарк), то схема усложнится.

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

Нет принципиальных проблем тут же реализовать работу супермаркета, бутика и кафе в одном флаконе.

Речь не идет про специальное билетное ПО.

Кот МатроскинПоэтому каталога товара в классическом понимании тут вообще не нужно , а нужен некий кубик с измерениями "Кинотеатр", "Фильм", "Сеанс" (+, возможно, "категория места" и что-то еще). А что будет в чеке - вообще зависит от учетной политики организации (как выше верно отметили, это может быть не товар, а услуга).повторю: В специализированном ПО действительно не нужно. Но мы его и не обсуждаем.

Стартовый пост четко упоминает про обычные товары и "билет в кино", т.е. задача реализовать продажу обычных товаров и билетов в кино. Или я не так понял стартовый вопрос ?

В моей схеме я не вижу проблем узнать цены на любые сеансы, т.к. они формируются на пересечении Фильм/сеанс.
Печатается по актуальным фильмам элементарный отчет и вывешивается перед кассой. :)
Более точную цену (с учетом различных скидок, в т.ч. персональных) можно узнать лишь на пересечении ПолитикаСкидок/Фильм/Сеанс.

Схема гибкая и позволяет решить практически любые задачи такого класса.
Некоторые неудобства есть, но они вызваны универсальностью подхода к задаче и минимумом доработок в готовом функционале.

Я предложил вполне рабочую и гибкую схему. Господа оппоненты пока не предложили ничего.

1. Практически никакие, Вы хотели сказать ;)
2. Продавать товар (т.е. выстроить удобное для покупателя предложение) - схема не помогает.
3. Получать аналитику по продажам - не помогает.
4. Просто тривиально вести учет чтобы не продать на сеанс билетов больше, чем есть мест в зале - и то не помогает ;)
Что помогает? Печатать чеки.
...
5.То у Вас "Билеты не дотягивают до того чтобы создать отдельную сущность", то "сущность сеанс".
6. То "цены формируются в момент попадания в документ на реализацию", то "цены формируются на пересечении Фильм/сеанс". 1. Все решает. Ваша не решает, потому что ее нет и возможно не будет. :)
2. Что такое удобное предложение ? И о каком товаре речь ?
3. Аналитика как раз прекрасно покажет любые продажи. И по кафе и по кено и по супермаркету.
4. Тут надо просто дописать ф-л на бронирование мест. Где-то отдельно хранить инфу по зал/место/ряд.
5. Да, сущность "сеанс" нужна, причем она сложная (в ней много параметров).
6. Тут нет противоречия. Цена формируется расчетом на пересечении Фильм/сеанс (когда они известны).

Конкретно для продажи билетов нужен ряд вспомогательных таблиц по бронированию и сеансам. Они нужны в любом случае.

А карточка товара "билет" нужна только одна (или парочку). Чтоб ее вставить в унифицированный документ продажи.
В данном случае у карточки товара крайне малая бизнес-нагрузка. Просто наличие строки и ссылки в чеке.

Коллега, ну где ваша универсальная схема ??? Чтоб и билет в кено купить и водочки попить в баре... :)

guest_20040621> Аналитика как раз прекрасно покажет любые продажи.
Нет, конечно. Кот уже рассказал вам достаточно, чтобы рассматривать билет как сущность не товарных категорий.Да пофигу, чо там кто рассматривает. Хоть горшком назови.

Аналитика построится по документам продажи. Там есть кол-во билетов, суммы и ссылки на "сеанс". Этого достаточно для аналитики.

зы: нет никаких билетов, товаров и услуг. А сущности вообще надуманная абстракция. :)
Есть таблицы с записями и бизнес-связи между ними. Больше ничего и не нужно.

SergueiТут подойдет классическая схема "звезда". ИД товара "зародится" в единой для всех таблице и разойдется по своим специфическим. Связи на товары таким образом будут из единой точки- что есть очень хорошо.
Специфические для каждого товара данные будут храниться в своей (своих) таблице.Я примерно о том же говорю уже полдня. :)
Это особенно важно, когда система большая и многофункциональная.

Осталась в общем-то ерунда - понять что ссылка "в чеке" на один единственный обьект для всех фактов продаж самых разных билетов совершенно неинформативна и в нее ровно с тем же успехом можно писать NULL, а следовательно - запись в таблице товаров "билет в кино" не нужна ни для чего.В общем случае "ссылка только на товар" все равно недостаточна.
Кроме ценообразования в самом товаре (допустим "апельсин" или "хлеб") есть еще внешние факторы: различные скидки, зависящие от инфы в документе продажи.
"Билет в кино" это вырожденный случай торговли одним единственным артикулом (одной карточкой, кот. теоретически может быть NULL), для кот. основная инф.нагрузка находится в документе продажи.
Такое бывает. Это нормально.

В чем собственно суть претензии ? В "карточка не нужна" ? Для универсальных отчетов по продаже будет нужна. Тем более карточка может ссылаться на группу товара, кот. может иметь аналитическую нагрузку в отчетах (н-р отчет по группам товара).
Группы могут быть "кинобилеты", "билеты на выставки", "билеты в аквапарк" и т.д. И это будет видно в отчетах.
В общем случае ни в одной системе нельзя сделать все карточки товара равнозначными по логике. Всегда будут какие-то особые карточки, у кот. особая аналитика и логика: основные средства, сырьё, полуфабрикаты, ресурсы, услуги и т.д.
Для этих карточек особая инфа будет находиться в других таблицах. Но источник "ID товара" все равно будет в одной таблице.
Зная тип карточки нет никакой проблемы обработать бизнес-логику индивидуально.

Таблица "Справочник товара" это всего лишь:
* ID,
* Артикул,
* Название(я),
* Тип карточки,
* Группа товара.

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

2 К.М. : Своей схемы для "апельсин, хлеб, билет в кино" ты так и не показал.
Наблюдаю только пустую болтовню и цепляние к терминам.

Как может выглядеть эта "другая схема" - я тоже рассказывал."Кубик" это не рассказ :)

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