Как разрешить и сохранить подопции в базе данных

Если у вас есть переменное количество вариантов, как кажется, вы делаете следующее:

Создайте таблицу, связывающую пакеты и опции по идентификаторам. Таким образом, у вас будут таблицы packages и options, а затем у вас будет таблица package_options, которая будет иметь только (помимо ее идентификатора и любого времени создания/модификации, которое вы храните) package_id и option_id.

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

Есть несколько способов решить эту проблему. По сути, чем гибче ваше решение, тем оно сложнее. Поскольку вы просите помощи в этом, я дам вам более простое решение.

Составьте такую ​​таблицу:

ID, PackageName, OptionName
1,  Balloons, Red Balloons
2,  Balloons, Blue Balloons
3,  Pizza, Plain
4,  Pizza, Pepperoni
5,  Clown, NULL

Затем, когда вам понадобится список пакетов для выбора, вы можете ВЫБРАТЬ PackageName из tblPackages GROUP BY PackageName. После того, как пользователь выберет пакет, вы можете выбрать SELECT OptionName из tblPackges, где PackageName = 1;

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

Если вы познакомитесь с этой концепцией, вы увидите, что вы могли бы создать таблицу пакетов, а затем таблицу опций и соединить их. Но, честно говоря, для небольшого приложения нет причин делать это с точки зрения производительности. Приведенный выше метод более понятен, чем мешанина идентификаторов, с которой вы сталкиваетесь при большом количестве объединений.

Надеюсь, поможет.

Начните с перечисления объектов, которые вы хотите сохранить, и отношений между ними. Судя по вашему описанию, у вас есть 3 сущности, участвующие в сохранении встречи:

1. встречи
2. выбранные пакеты
3. выбранные параметры

С 2 отношениями:

1. у каждой встречи может быть любое количество пакетов
2. каждый пакет любое количество опций

Сущности — это ваши основные таблицы, а отношения между ними — это внешние ключи:

• Назначения за столом (Id Int, детали встречи...)
• Таблица selected_packages (Id Int, назначение_id Int, сведения о пакете...)
• Таблица selected_options ( selected_package_id Int, подробности опции... )

Обратите внимание, что здесь я тщательно упомянул выбранные пакеты и параметры — у вас вполне могут быть другие таблицы, представляющие доступные пакеты и параметры, и где я написал «сведения о пакете». " и "сведения об опциях", вы можете просто сохранить ссылку внешнего ключа на них (хотя вы можете сделать снимок, особенно таких важных деталей, как цена, чтобы у вас была запись о том, какие детали были во время бронирования).