Вы можете использовать агрегацию. Я бы рекомендовал передавать ингредиенты в виде списка VALUES()
, а не строк. Однако, с вашей конструкцией:
SELECT r.Name, r.Preperation_Time, r.Author
FROM recipes r LEFT JOIN
RecipeIngredients ri
ON ri.Recipe_ID = r.Recipe_ID LEFT JOIN
Ingredients i
ON i.Ingredient_ID = ri.Ingredient_ID AND
i.Name IN (" + ingredientString + ")"
GROUP BY r.Name, r.Preperation_Time, r.Author
HAVING COUNT(*) = COUNT(i.Ingredient_Id); -- all match
Нормально хранить Объекты Значения в отдельной таблице по самым причинам, которые Вы описали. Однако я думаю, что Вы неправильно понимаете Объекты по сравнению с VOs - это не связанное с персистентностью беспокойство.
Вот пример:
Предположите, что у Компании и Человека оба есть тот же почтовый Адрес. Какой из этих операторов действительно считает допустимыми?
Если 1 верно, Адрес должен быть Объектом и поэтому имеет свою собственную таблицу
Если 2 верно, Адрес должен быть Объектом Значения. Это могло быть сохранено как компонент в таблице родительского Объекта, или это могло иметь свою собственную таблицу (лучшая нормализация базы данных).
Как Вы видите, как Адрес сохраняется, не имеет никакого отношения к семантике Entity/VO.