Товарищи, добрый день!

Ситуация такая:
На сайте совершать действия могут как зарегистрированные пользователи, так и гости. В том числе и внесение средств. Средства одного гостя ничем не отличаются от средств любого другого. Типа такой распределённый пользователь.

Скажите пожалуйста, в таком случае надо ли в таблице пользователей Гостя изначально создавать? Просто допустим с флагом "не может быть авторизован", и в коде приложения константой прописать ID этого пользователя (он создаваться в БД будет при начальной генерации базы приложения) и в дальнейшей логике приложения при проверках на Гостя сверять с этим ID.

Просто как я кумекаю, иначе придётся лепить отдельные таблицы под сущности Гостевых платежей и других действий. Поделитесь пожалуйста соображениями и опытом.

Кот МатроскинДумаю что обязательно создавать пользователя "Гость" и, более того, быть готовым начать создавать по отдельному пользователю "гость" на каждый анонимный заход на сайт, сопровождающийся платежом. Т.е. не прописывать константой ID, а проверять свойство пользователя "гость/не гость"
Как так? У меня для разделения уникальных входов на сайт идентификатор сессии есть. И связь идентификатора сессии с авторизованным в ней пользователем. На каждого гостя свою запись в таблице пользователей, это не совсем понятная идея.

softwarerСкорее нет, чем да. Общей логике БД в таком случае больше соответствует простановка null в user_id, что и будет обозначать гостя.
Всё бы так, но я следуя правилу что поля с NULL значениями это плохо, делаю без них всё. Была у меня идея на этот случай учётку Гостя в БД прописать с id=0, тогда и при проверка для IF'ов всяких всё естенственно будет происходить.

Dimitry SibiryakovА ещё придётся придумать что делать с анонимами, заявляющими "я закинул деньги не на тот
счёт, верните их немедленно".
Ну тут установка галочки перед совершением платежа с текстом что я всё осознаю и в добром здравии расстаюсь со средствами, и претензий ни к кому не имею. А если уж совсем упираться, ну тогда информация с IP/UserAgent в БД есть по совершению платежа и должен доказать что эти данные входа действительно его.

Dimitry Sibiryakov , ну для такого случая (в смысле запрос обратно платежа) - это вопрос из юридической плоскости больше чем из технической. Вернуть то платёж думаю не составит уж прямо труда.
Если это юридически будет обязывать площадку сделать, ну значит будет сделано. Гость предоставляет необходимые реквизиты по которым сверяется что с них пришёл платёж или другим образом подтверждает своё авторство платежа, а дальше там уже детали. Главно чтобы учёт поступлений и вся эта внутренняя кухня правильно была организована, потому я и консультируюсь тут по всяким мало мальским вопросам, чтобы фатальных ошибок не наделать и не упереться в тупик невозможности реализовывать дальше идею.

Уважаемые, почитал ваши мнения.

Итого:
На каждого анонима своего юзера, идея неясная. Чем этот юзер по смыслу отличается от сессии непонятно.

C id=0 понял что лучше такой вариант не рассматривать.

Предложение, что Гости это группа не совсем понятно что предлагает. Создавать пользователя на каждого анонима и пихать его в группу Гостей? Это п.1 с ещё одной доп. связью и он не совсем понятен.


Для гостевых пользователей использовать NULL значение. Как же тогда использовать Foreign Key для столбцов таблиц в которых должен лежать этот самый userID? Там-то ведь NULL'а быть не может. Требуется дальнейшее пояснение.

Вариант с предустановленным ID для анонима, никак не прокомментирован общественностью.

Вариант с выделением всех сущностей которые привязываются к юзерам и в то же время доступны гостям (платежи за что-то) в разные таблицы по типу user_pays , guest_pays тоже никак не прокомментирован.

По поводу NULL варианта, я с аргументом "А как же внешние ключи" понял что тупанул. Они нужны ведь только для поддержания целостности, учитывая что из БД записи о пользователях удаляться не будут, можно на userID и просто индекс повесить, чему NULL не помеха.

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

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

полудухесли очень хочется пасти поведение каждого юзера на сайте, то ему нужен его уникальный идентификатор,
Так ведь для отслеживания вполне подходит sessID . У меня просто сессии так организованы:
Человек вошёл на сайт, сгенерировалась новая сессия и её ключ вносится в БД. ID этой записи - sessID , затем есть практически в любой строке в БД которая сгенерирована посетителем. Т.е. условно Гость оставил сообщение - там строка таблицы ( sessID, userID, msgDate, msgText ). Так что в моём случае отслеживание Гостя вполне получается с помощью sessID .

stenfordнеужели гостевой пользователь вообще себя никак не идентифицирует? Email, или может телефон должен ввести? И как платеж-то проходит, с кредитки? Во всех этих случаях он может быть (и должен) индентифицирован, для возможных возвратов платежей, расследований проишествий и прочего. По-сути гостевой пользователь ничем от залогиненного отличаться не должен, залогиненным просто можно дать больше прав, как-то видеть историю транзакций и прочего. У вас явно не продуманы бизнес-правила
Но ведь при платежах через оффициальные каналы (банк, карточка, applePay и т.п.) идёт идентификация клиента. И данные этой идентификации передаются в инициирующее платёж приложение. Разве этого недостаточно? А идентифицировать по e-mail и даже sms, это как мёртвому припарка. Способов сделать липовую регистрацию которая при расследовании ничем не поможет - масса.

Dimitry SibiryakovВ 32 разряда весь живущий народишко уже не влезет, а вот в 64 - вполне.
Ну это-то ясно, я для таких целей BIGINT использую, но просто сама мысль что в таблице с "настоящими" пользователями будет 99% записей равноценных просто списку сессий - мне не понятна.