, Что пути там, чтобы хранить информацию об анонимном / пользователе-госте в базе данных?

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

Сейчас мы изучаем, что делать в случае «анонимного» или «гостевого» клиента, открывая интернет-магазин для клиентов, которые не хотят регистрироваться, а также для продаж, зарегистрированных в бэкэнд-приложении, где прием электронной почты клиента, почтового адреса и т. Д. Слишком много времени. Решение также имеет приложения вне интернет-магазина.

Несколько компаний используют одну и ту же базу данных, и база данных построена на основе партийной модели , поэтому мы изучили несколько вариантов:

1. Храните всех анонимных клиентов под одним заранее определенным customer _ ID в таблице транзакций :
   1. клиент _ ID = 0 для каждого анонимного пользователя и клиентов _ ID > 0 для каждого реального пользователя
      • Это прямо к жесткому коду в приложении
      • Но более активно, чтобы определить, какие клиенты принадлежат какой компании
      • Должны ли подробные данные для customer _ ID = 0 существовать в таблице customer в базе данных или в качестве объекта в приложении?
        • Какие ограничения на уровне базы данных могут быть установлены для обеспечения ее постоянного существования?
        • Если она отсутствует в базе данных, тогда ограничения внешнего ключа от transaction.customer _ ID до customer.customer _ ID больше не работают
   2. клиентов _ ID совпадает с идентификатором компании вечеринок _ ID
      • Проще определить совокупные продажи для каждой компании, и т.д.
      • Это запутало бы ситуацию, поскольку казалось бы, что компания является ее собственным клиентом, вместо других уникальных клиентов
2. Создайте уникальный customer _ ID для каждого нового анонимного клиента (за сеанс)
   • Что делать, если возвращается один и тот же физический пользователь? Будет много записей, повторяющих один и тот же вид данных; адрес электронной почты, адрес доставки и т.д.
3. Для ссылки на клиента используйте другой уникальный ключ, например адрес электронной почты
   • Не всегда надежны, поскольку люди иногда используют несколько адресов электронной почты или оставляют старые адреса.
   • Что делать, если нет адреса электронной почты, как в случае с магазином, проформой и т.д.?
4. Какое-то другое решение, вдохновленное переполнением стека!

Добавление

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

Я должен отметить, что нам не нужно хранить запись для каждого анонимного клиента, но кажется, что реляционная база данных была построена для работы с отношениями, так что иметь NULL или customer _ ID в таблице транзакции , которая не ссылается на фактическую запись клиента, просто кажется неправильным...

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

, Что решения имеют ТАК сообщество, используемое в прошлом?