Ограничения SQL для нескольких таблиц
У меня возникли трудности с проектированием этой таблицы и ограничений для нее.
У меня есть список пользователей, у каждого пользователя может быть список предпочтительных блюд. Пытаясь определить, какое блюдо будет приготовлено следующим, я присвоил спискам значения.
Yummy <- value 5.
OK <- value 3.
Disgusting <- value 1.
Я только хочу, чтобы каждый пользователь мог отмечать каждое блюдо в одной из категорий.
В настоящее время у меня есть невероятная простая БД, которая:
User(id, name)
Meal(id, name)
Yummy(id, userid, mealid) where userid id and mealid are foreign keys.
OK(id, userid, mealid) where userid id and mealid are foreign keys.
Что я хотел бы сделать, так это сделать так, чтобы если я вставил лазанью в Yummy, я не мог также вставить это значение в 'OK' или 'Disgusting'. Я думаю, что ограничение как для meid, так и для userid, возможно, является правильным подходом, но я немного не в себе.
Любая помощь или предложения будут очень признательны.
@xQbert - да, конечно. это имеет смысл, и вполне может появиться больше столов, которые будет сложно поддерживать. Я не могу представить ответ, опубликованный в данный момент - заканчиваются мозговые циклы: D
Ответы 1
Вам, вероятно, лучше подойдет дизайн базы данных, подобный этому:
user (id, name)
meal (id, name)
rating (id, name, value)
user_meal_rating (user_id, meal_id, rating_id) *primary key on (user_id, meal_id)*
Привет, спасибо, что нашли время ответить! Следуя этой модели, смогу ли я, чтобы несколько пользователей выбирали несколько блюд, но оценивали их по-разному? При этом не имея возможности поесть в «других» рейтингах пользователей. Извините за вопрос, который может показаться глупым, я плохо себе это представляю. Значения, которые я связывал с Yummy и т. д., должны были использоваться программно, а не сохраняться, хотя их сохранение, безусловно, позволило бы изменить их быстрее, так что это также лучший подход. :)
первичный ключ (user_id, food_id) не позволит любому пользователю оценить блюдо дважды, но позволит разным пользователям оценивать блюда по-разному. Одним из способов визуализации user_meal_rating может быть сетка, в которой столбцы — это приемы пищи, строки — это пользователи, а каждая ячейка содержит один рейтинг.
Кроме того, технически вы должны хранить рейтинги в базе данных; они могут быть значениями, ссылающимися на перечисление на стороне клиента (хотя тогда каждая реализация клиента должна была бы отражать перечисление). Другая альтернатива может просто избавиться от концепции «рейтинг-имя-значение» и сделать рейтинг значением от 1 до 10, где чем выше, тем лучше.
Ах, спасибо, это имеет смысл :) Большое вам спасибо
извините, что оживляю это, но у меня есть вопрос, и мне было интересно, не могли бы вы помочь. Есть ли причина, по которой в приведенном выше дизайне не должно быть имени пользователя и названия блюда в таблице user_meal_rating? Я полагаю, что буду использовать его довольно часто, поэтому мог бы извлечь из него все, что мне нужно, вместо того, чтобы затем переходить к пользовательской таблице с идентификатором, чтобы получить имя и т. д.
На самом деле нет особых причин использовать такие вещи, как имена, где-либо, кроме исходной таблицы; и многочисленные причины не делать этого. Если бы вы использовали имя пользователя в user_meal_rating; вы бы: заняли больше места для хранения имени в каждом рейтинге; на самом деле сделать поиск в таблице сложнее (с уникальным идентификатором требуется одно сравнение, чтобы определить, является ли строка той, которую вы ищете, но требуется 4 сравнения, чтобы различить, предназначена ли строка для «Джош» или «Хосе»); усложнить обновление (если кто-то опечатал имя, его нужно было бы изменить везде)... и это игнорирует, что у вас, вероятно, будет более одного «Джона».
Спасибо. Я думаю, я смотрел на это с точки зрения приложения, поскольку мне нужно будет так или иначе извлечь эти данные, и сделать один вызов (к одной таблице) может быть более эффективным, но я понимаю, почему это не так, Спасибо!
Вкуснятина, хорошо, отвратительно - это «Статус», возможно, позже вы захотите SUPERB или не подходит для категорий потребления человеком. вы не хотите добавлять таблицы, поэтому таблица рейтинга имеет смысл. Uueerodo хорошо разбирается в дизайне, чтобы поддержать это. И это гарантирует, что блюдо пользователя может быть оценено только один раз.