насколько я понял, вы предлагаете сделать товар или услугу (неважно пока) типа "Билет на сеанс 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 К.М. : Своей схемы для "апельсин, хлеб, билет в кино" ты так и не показал.
Наблюдаю только пустую болтовню и цепляние к терминам.

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

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