В нашем приложении есть интернет-магазин среди других функций, и пользователям обычно предлагается зарегистрироваться до завершения продажи, создавая уникальный customer_ID
в процессе. Когда они возвращаются, они могут войти в систему, и их контактные данные и история транзакций извлекаются из базы данных.
Теперь мы изучаем, что делать в случае "анонимного" или "гостя" клиента, открывая интернет-магазин для клиентов, которые не хотят регистрироваться, а также для продаж, зарегистрированных в бэкэнд-приложении, где получение электронной почты клиента, почтовый адрес и т.д. - это слишком много времени. Решение также имеет приложения вне интернет-магазина.
Несколько компаний используют одну и ту же базу данных, а база данных построена на структуре party model, поэтому мы изучили несколько вариантов:
- Сохраняйте всех анонимных клиентов в рамках одного предопределенного
customer_ID
в таблицеtransaction
:-
customer_ID = 0
для каждого анонимного пользователя иcustomer_ID > 0
для каждого реального пользователя- Это прямое обращение к жесткому коду в приложение
- Но более активное участие в определении того, какие клиенты принадлежат к какой компании.
- Должны ли детали для
customer_ID = 0
присутствовать в таблицеcustomer
в базе данных или как объект в приложении?- Если в базе данных могут быть установлены ограничения на уровне базы данных, чтобы гарантировать, что они всегда существуют?
- Если нет в базе данных, ограничения внешнего ключа от
transaction.customer_ID
доcustomer.customer_ID
больше не работают
-
customer_ID
- это то же самое, что и компанияparty_ID
- Легче определить совокупные продажи для каждой компании и т.д.
- Это путало бы вопросы, поскольку казалось бы, что компания является ее собственным клиентом, а не другими уникальными клиентами.
-
- Создайте уникальный
customer_ID
для каждого нового анонимного клиента (за сеанс)- Что делать, если тот же физический пользователь возвращается? Будет много записей, повторяющих одни и те же данные; адрес электронной почты, адрес доставки и т.д.
- Используйте другой уникальный ключ, например адрес электронной почты, чтобы обратиться к клиенту
- Не всегда надежный, поскольку люди иногда используют более одного адреса электронной почты или оставляют старые адреса позади.
- Что делать, если адрес электронной почты не принимается, как в случае с цехом, проформовыми счетами и т.д.?
- Некоторые другие решения для!
Добавление
Комбинация № 2 и № 3 была предложена в другом месте - попытайтесь сохранить отдельную запись для каждого клиента, используя, по возможности, адрес электронной почты или новую запись при каждом посещении, если нет.
Я должен указать, что нам не нужно хранить запись для каждого анонимного клиента, но похоже, что реляционная база данных была создана для взаимодействия с отношениями, поэтому с помощью NULL или customer_ID
в transaction
таблица, которая не ссылается на фактическую запись клиента, просто кажется неправильной...
Я также должен подчеркнуть, что цель этого вопроса состоит в том, чтобы определить, какие реальные решения существуют для записи "случайных" транзакций, когда нет почтового адреса или адреса электронной почты (представьте себе супермаркет chekout) наряду с транзакциями в интернет-магазине, где адрес электронной почты и почтовый адрес, независимо от того, хранятся они или нет.
Какие решения использует сообщество SO в прошлом?