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

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

Скажите пожалуйста, в таком случае надо ли в таблице пользователей Гостя изначально создавать? Просто допустим с флагом "не может быть авторизован", и в коде приложения константой прописать 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% записей равноценных просто списку сессий - мне не понятна.

Запоздалый комментарий, но просто эту идею которую ты озвучил, чтобы каждый аноним в системе был юзером запала мне в мозг.

Сперва я её отвергал - дескать зачем мне рыться в огромной таблице условно сессиий, когда надо найти пользователя.
Затем я о ней просто помнил и периодически раздумывал.
И в итоге похоже что так оно и есть. Всё пришло к тому, что либо мне учёт разных сущностей в БД делать костылями типа

с последующими извратами при формировании самого запроса в зависимости от анонима или юзера,
Либо для каждой сущности делать отдельно таблицу связи с юзерами и отдельно с анонимами.

И вот сейчас я пришёл к осознанию того, что необходимо принять и реализовать твой вариант, который стоило бы принять 2 года назад :)

Опыт вещь серьёзная!

vmag,

Ну тут загвоздка возникла вокруг такой задачи: Необходимость оформлять подписку (E-Mail) на обновления разных сущностей. И не обязательно для этого регистрироваться в системе.

Т.е. к примеру: Есть обсуждение, и я попав на него - жму "Получать новости этого обсуждения на E-Mail". И соответственно просто должен иметь возможность ввести е-маил, получить письмо с подтверждением и в дальнейшем получать новости по этой сущности в системе.

И загвоздка вся вокруг этих таблиц:




Тут алгоритм такой:
1. При указании e-mail'а хоть авторизованым юзером, хоть анонимом сперва этот адрес вносится в emails, и для вставленного emailID (если вставится, т.е. не существующий) формируем запрос на подтверждение email'а в emailReq
2. И вот в этой схеме проявляется вся двоякость, что если запрос был создан пользователем, то надо искать запросы с userID таким-то, если анонимом - то по sessID и NULL в userID.

Кроме того, особая вишенка в том что я делаю, что типа анонимная подписка - она тоже как-бы сквозь-сессионная. Т.е. аноним сделал так:
1. Подписался на тред, подтвердил е-маил, и в рамках его текущей сессии он уже может бегать по тредам и просто жать "на это тоже подпишусь" и всё это учитывается по emailID подтверждённый в его сессии.
2. Потом он пропал с сайта, сессия подохла, и он снова заходит и снова жмёт "подписаться", ему говорят давай e-mail, и подтверждай его. Он вводит e-mail, тот же который был в п.1, система видит что в тот раз это был "сессионно" подтверждённый емаил, значит в другой сесиии можно его тоже "подтверждать". (Если емаил закреплён за юзером, то такого сделать нельзя)
3. Новый аноним подтверждает высланным кодом прежний емаил, и ему вся его прежняя история подписок на этот емаил доступна. Эдакий сквозной аноним.

И получается что сейчас у меня есть пользователи, а параллельно есть ещё учёт сессий, связываемых между собой в одного субъекта условно по подтверждённому emailID. А если бы делать анонима как советовал Кот Матроскин изначально новая сессия - просто пользователь, с флагом isAnon=1, то была бы везде привязка к userID, а различия бы строились на основе этого флага.

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

Dimitry Sibiryakov,

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

А если на куку только завязываться, то соответственно потёрли куку - всё, потерялась вся эта "сквозная" привязка.

И внезапно система вернётся к более неудобному способу идентификации по почте. В чём
проблема-то?
Ну не совсем идентификация по почте. Это конкретно для тех кто не хочет регистрироваться, но готов получать информацию. А повторная идентфикация по почте - это просто как интересная "плюшка", где подтвердив E-Mail анон имеет свой "личный кабинет" сам изначально о таком и не мечтавший.



Да не, щупать ничего кроме девчачьих округлостей неохота, а просто ситуация вышла так что вспомнил совет и увидел его применимость в моей ситуации.

Vmag , в твоей схеме я сходу вижу например такую проблему:
Ключ подписки описанный тобой (userID, entityID, emailAddr) позволяет:
1. На один E-Mail присобачить сколь угодно много пользователей с подписками.
2. Вносит хаос в виде как раз того, что ты выдал за интересную особенность: чтобы пользователь с прикреплённым к нему e-mail'ом мог оформить подписку от себя но на другой e-mail. Я конечно за возможности и свободу действий пользователей, но мне этот вольный бардак кажется лишним.

А по поводу судов и спама - во-первых потверждение email'а никто не отменял для старта рассылки. Во вторых в тексте каждого рассылочного письма чётко читаемая и не прятаемая ссылка: Хотите удалить из рассылки свою почту - щёлкайте сюда.
Совсем не вижу что именно юридически обязывающего даёт регистрация пользователя на моём сайте в плане получения писем. На многих ресурсах есть возможность подписаться не регистрируюсь, это вполне рабочая практика.
А уж как кого зовут в интернете - если бы это узнавалось из регистрации на сайте - думаю интернет и стиль общения в нём были бы совсем другими чем сейчас :)
А тов.Майору один хер при необходимости более важны будут логи моего веб-сервера для поиска кого-то забредшего на сайт :)

skyANA,

Это просто получается доп.прослойка ведь. Смысл в том, чтобы этот "Контакт" был связан с конкретным субъектом. И этот субъект - это владелец е-майла, и при этом неважно он авторизован на сайте или нет.

Предложение контакта просто добавляет ещё один уровень абстракции между субъектом и емаилом.

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

Спасибо, я погружусь поглубже в эту схему. Надо понять всё это спокойно и применительно к моему случаю.


А что в этом плохого? Вроде вполне логично прежде чем работать вообще с email'ом и писать его в БД, оценить с помощью какого-нибудь filter_var'а




Я теории этого DDD не знаю, но по названию понимаю о чём речь и в целом пользуюсь именно таким подходом. Т.е. понимаю предметную область, формирую отдельные центральные (или может самодостаточные) сущности и строю уже из них отношения.

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

Спасибо!

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

Ну да, сейчас проверил кириллицу filter_var не пропустил. Значит воспользуюсь советом выше и организую проверку собаки, точки после собаки, чем-то до собаки, чего-то между точкой и собакой и после точки.

Можно ещё на уровне dns'а домен проверять, погляжу какая задержка из-за этого будет.