Nano Hash - криптовалюты, майнинг, программирование

Нужна помощь по схеме таблицы MySQL

У меня проблема с решением, где разместить определенное поле таблицы в моей базе данных. База данных предназначена для сайта объявлений. Я хочу, чтобы зарегистрированные и незарегистрированные пользователи могли размещать объявления. Если незарегистрированный пользователь размещает объявление, сайт должен запросить у него контактный телефон, если пользователь уже зарегистрирован, то следует использовать контактный телефон, хранящийся в таблице пользователей.

Теперь мой вопрос: можно ли хранить контактный телефон для зарегистрированных и незарегистрированных пользователей в одном и том же поле таблицы? Если да, то где это поле должно быть размещено, в таблице объявлений или в таблице пользователей (отмечая, что каждый пользователь в таблице имеет уникальный идентификатор, таким образом, заполняя таблицу пользователей незарегистрированными пользователями только для того, чтобы получить их контакт телефон просто заполнит таблицу бесполезными данными)

Заранее спасибо !

04.04.2011

Ответы:


1

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

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

Вы сказали

заполнение таблицы пользователей незарегистрированными пользователями только для получения их контактного телефона просто заполнит таблицу бесполезными данными

Если он бесполезен, не храните его. Если вам нужно сохранить его, это не бесполезно.

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

Имеет ли смысл требовать контактный номер телефона вместо того, чтобы позволить пользователю оставить либо номер телефона, либо адрес электронной почты? Лично я предпочитаю использовать одноразовый адрес электронной почты для таких вещей.

04.04.2011
  • Спасибо за ваш ответ. Что я имел в виду под «бесполезной информацией», так это то, что зарегистрированные пользователи имеют гораздо больше информации в своем профиле, чем незарегистрированные (имя, адрес электронной почты, имя пользователя, пароль и т. д.). Поэтому просто создайте целую строку таблицы. вставка номера телефона незарегистрированного пользователя показалась мне плохой идеей, потому что целая строка просто создается для вставки в нее 1 поля и оставляет около 8 других полей пустыми. У вас есть смысл заполнять всю информацию в одном месте, я подожду еще нескольких ответов, чтобы принять решение :) 04.04.2011
  • Разница в стоимости между созданием строки, содержащей 8 значений, и строки, содержащей 1 значение и 7 пустых значений, незначительна. Но вам нужно сделать имя пользователя обнуляемым или автоматически назначаемым. (StackOverflow автоматически присваивает имя пользователя незарегистрированным пользователям. Думаю, это хорошая идея.) 04.04.2011

  • 2

    хорошо, вы можете поместить поле телефона в таблицу объявлений с полем is_registered внутри. Затем через php вы проверяете is_registered, и тогда вы знаете, где искать номер телефона.

    С уважением

    04.04.2011
  • Мне очень нравится этот ответ, я, наверное, так и сделаю! Большое спасибо за помощь Алексею! 04.04.2011

  • 3

    Я бы искал гибкость в вашем дизайне, но если ваша логика обрабатывает пользователей в основном независимо от того, зарегистрированы они или нет, я бы использовал ту же таблицу и просто заполнил остальные данные пользователя для зарегистрированных. Я бы не стал хранить пользовательские данные в таблице объявлений, хотя бы для ясности организации данных.

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

    Другой подход: почему бы не сделать регистрацию настолько простой, чтобы незарегистрированные пользователи не имели смысла? Если вы уже запрашиваете номер телефона во всех случаях, просто добавьте поле пароля или сгенерируйте его автоматически, и все ваши пользователи будут зарегистрированы.

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

    04.04.2011
  • Спасибо за ваш ответ AJweb. Регистрация проста, но я чувствую, что многие интернет-пользователи раздражаются, когда им приходится регистрироваться для получения простой услуги, когда многие конкуренты уже предлагают ее незарегистрированным пользователям. Кроме того, поле номера телефона было просто для упрощения, у меня на самом деле есть 3 поля, которые незарегистрированные пользователи должны заполнять каждый раз, когда публикуют объявление. Я думаю о создании гостевой таблицы, содержащей эти 3 поля в дополнение к идентификатору объявления. При размещении поля is_registered в таблице объявлений, чтобы определить, из какой таблицы пользователей (гостей или пользователей) извлекать информацию. Имеет смысл? 04.04.2011
  • Новые материалы

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

    Как написать эффективное резюме
    Предложения по дизайну и макету, чтобы представить себя профессионально Вам не позвонили на собеседование после того, как вы несколько раз подали заявку на работу своей мечты? У вас может..

    Частный метод Python: улучшение инкапсуляции и безопасности
    Введение Python — универсальный и мощный язык программирования, известный своей простотой и удобством использования. Одной из ключевых особенностей, отличающих Python от других языков, является..

    Как я автоматизирую тестирование с помощью Jest
    Шутка для победы, когда дело касается автоматизации тестирования Одной очень важной частью разработки программного обеспечения является автоматизация тестирования, поскольку она создает..

    Работа с векторными символическими архитектурами, часть 4 (искусственный интеллект)
    Hyperseed: неконтролируемое обучение с векторными символическими архитектурами (arXiv) Автор: Евгений Осипов , Сачин Кахавала , Диланта Хапутантри , Тимал Кемпития , Дасвин Де Сильва ,..

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

    Обеспечение масштабируемости LLM: облачный анализ с помощью AWS Fargate и Copilot
    В динамичной области искусственного интеллекта все большее распространение получают модели больших языков (LLM). Они жизненно важны для различных приложений, таких как интеллектуальные..