Форум MySQL

Кто о чем, а вшивый о бане :)
Другой вопрос-уточнение о разрабатываемой мною БД.

Итак, напомню, что есть база данных, назовем ее calories. Она содержит несколько таблиц, в том числе таблицу products (продукты) и таблицу users (пользователи). Таблица products содержит в себе список основных(!) продуктов питания, значений калорийности, белка, углеводов и жиров. Таблица содержит начальный список примерно из 20 наиболее употребляемых продуктов. Пользователи могут самостоятельно добавлять в эту таблицу свои продукты.

Ни один из основных продуктов данного списка нежелательно удалять. Как это можно реализовать?

Я предполагаю так: в таблицу products добавляется новый столбец с типом данных ENUM и значениями 0 и 1. По умолчанию значение 1 - то есть удалять запись с таким признаком можно. При этом для продуктов основного списка администратор заранее устанавливает значение в этом столбце 0 - то есть удалять нельзя.

Жизнеспособен ли такой вариант или есть другие варианты?
Спасибо.

>Пользователи могут самостоятельно добавлять в эту таблицу свои продукты.

У пользователей прямой доступ к SQL-интерфейсу БД?
Если пользователь так или иначе может менять лишь собствненные строки - проще ориентироваться на поле userid в строке продукта.

Нет, через Web-интерфейс. Предположим, на странице отображается список продуктов. Пользователь видит, что нужный ему продукт отсутствует. Он добавляет его в список. А какой-то продукт он хочет из этого списка исключить. Соответственно, выбирает продукт в списке, нажимает кнопку "Удалить". У меня на этот случай будет прописана процедура на PHP, с помощью которой и будет осуществляться запрос к БД.
Или вы о другом спрашивали, а я по не опытности не понял?

То есть, в таблицу products добавить новый столбец userid (который является внешним ключом к таблице user (userid = PK) и добавлять к каждому продукту (записи) номер этого пользвоателя?
Тогда я не совсем представляю себе, как быть, если пользователей несколько? Каким образом добавлять userid...

как это несколько?
Конкретный продукт-то добавил конкретный пользователь?
Значит он за него и отвечает?

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


Если надо несколько - вводите таблицу связи многие-ко-многим (продукт,пользователь)

Понял, значит это у меня несуразность в таблицах и их организации, а значит и в голове. Буду дальше думать.
Спасибо.

Если позволить пользователю удалять продукты, даже добавленные самим пользователем, то это приведет к хаосу.
Представим, что первый пользователь добавил "Молоко топленое". Этот продукт был внесен в общую таблицу продуктов.
Второй пользователь увидел наличие в таблице этого продукта и выбрал его себе (анпример, поместил в свою таблицу потребленных калорий за текущий день).
Если потом первый пользователь захочет удалить это "Молоко", то нарушится ссылочная целостность. Этого допустить нельзя.
Таким образом, пользователь вообще не должен иметь возможность на удаление продуктов из таблицы. Но он может скрыть их из списка продуктов, которые отображаются для данного пользователя.
В этом случае получается все корректно, на мой взгляд.

и пометку такую он может стаить лишь на своих строках.
Иначе один другому наотмечает.

Точно.
Но тут возникает другой вопрос - если будут связанные таблицы, то насколько критичен их объем?
Поясню: есть таблица products и таблица пользователей users. Создаем связанную таблицу prod_user, в которой три столбца (или поля): id, id_user, id_product. Для каждого нового пользователя в эту связанную таблицу заносится id_product с основными продуктами. Типа:
ID | ID_USER | ID_PRODUCT
1 | 1 | 1
2 | 1 | 2
...
50 | 1 | 50

Таким образом, получаем уже 50 записей на одного пользователя. Если регистрируется 10 пользователей, это 500 записей, а 100 - 5000!
Так вот, насколько такой объем связанной таблицы критичен для общего быстродействия? Ведь эта таблица может разрастись...

1. Стоп.
Если хозяин у продукта только один - зачем связь многие-ко-многим?
Достаточно чужого ключа, как я и предложил первым ответом.
Вернее, как Вы предложили темой ранее.

>Если хозяин у продукта только один - зачем связь многие-ко-многим?
>Достаточно чужого ключа, как я и предложил первым ответом.

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

Никаких пометок публичная/закрытая не требуется.
(если надо - поставьте пометку "видна/не видна хозяину", но это уже другая тема)

У записей в поле userid будет идентификатор-признак общего продукта.
Например, 0 . Или идентификатор администратора.
Формально это, конечно, несколько нарушает нормальную форму.
Но если Вы не собираетесь заводить группы пользователей-администраторов, либо делать продукты общими для определенных групп пользователей - такое решение представляется мне аккуратным компромиссом.

Ага, начинаю доходить. Таким образом мое видение в последнем моем же ответе соотносится с вашими словами. Для общих продуктов ставим идентификатор, для остальных - id_user.
Спасибо.

Вы предложили:
>PPS. Если еще чуть-чуть подумать, то окажется нелишним таки назначить общим данным конкретный userid.
>Чтобы вытаскивать строки по индексу: А не полным сканированием.
>

"SELECT ... WHERE userid = $public_id OR userid = $user_id"

Таким образом, правильно ли я понимаю, что нужно добавить в таблицу products поле с отметкой (публичная запись или закрытая)? А в таблицу-связки добавлять только новые значения для собственноручно добавленных продуктов?

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

2. Зачем id в таблице-связке?

3. Зачем всем пользователям вносить все продукты?
Смысл связки теряется напрочь.

>2. Зачем id в таблице-связке?

Согласен, лишнее.

>3. Зачем всем пользователям вносить все продукты?
>Смысл связки теряется напрочь.

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

Меня смущает в этой ситуации лишь один момент - наличие общих продуктов.
Действительно, можно организовать таблицу products таким образом, чтобы в ней были три основных столбца: id, name (имя продукта) и id_user (ID пользователя).
Тогда при добавлении нового продукта в поле id_user будет добавлен айди добавившего продукт пользователя. В этом случае и связка не нужна, а достаточно запроса, предложенного Трианоном.

Но я не могу понять, а что заносить в это поле для общих продуктов? Получается, что это поле не будет иметь обязательных значений и может содержать пустую строку, NULL или 0.
Спасибо.

пустую строку оно содержать не может - тип не даст.
не содержать ничего (быть NULL) - может. Но чтоб отыскать такие записи, придется делать полный перебор данных в таблице - индекс не спасет.
А 0 (или другой наперед фиксированный ключ) - решение.

Огромное спасибо за помощь! Потихоньку утрясается и выстраивается структура. Пока рисую на бумаге.