Мне отказали в регистрации нового кошелька на старый номер.
> WebMoney Transfer — строгая учетная система, данные не удаляются.
> Данные из системы не удаляются. Вы можете закрыть данные к просмотру и заблокировать WMID
> на вход в систему, написав с регистрационного e-mail в службу технической поддержки по E-mail
> support.wmtransfer.com/asp/services.asp.
> Регистрация производится на новый номер.
Похожая ситуация, давным давно регистрировался и при регистрации указал свой номер телефона. Ключи потерял. И вообще забыл что регистрировался. Недавно возникла нужда зарегистрироваться — говорят фиг тебе, на этот номер телефона уже зарегистрирован кошелек. Обратился в суппорт, сказали номер кошелька, создал заявку на восстановление доступа, и, параллельно, задал вопрос в суппорт, нельзя ли просто отписать тот кошелек от моего номера. Ответили что нельзя. Вот уже почти месяц жду восстановления, отправил им фотку паспорта (заверений правда вроде никаких не нужно).
ненавижу такие задачи, 9 WA на 2м тесте, забил — пошел 4ю решать, только после игры заметил что последняя попытка не на 2м а на 9м тесте сдохла… подстава %(
first_name и last_name нужны непосредственно для аутентификации. По крайней мере, хотя бы для того чтобы вывести «Здравствуйте, {{ first_name }} {{ last_name }}, вы успешно аутентифицировались». Это данные, идентифицирующие пользователя. Ну и да, куда их засунуть, если не сюда?
зачем плодить число запросов там, где можно этого не делать
Это замечание справедливо тогда, когда вы пытаетесь выполнить необходимую работу скриптом вместо того чтобы предоставить её базе данных. Здесь же, нагрузка от обработки лишнего объема данных (в данной ситуации 1/3 объема — лишние, а на практике обычно в таких ситуациях всё гораздо хуже), превзойдет нагрузку от обработки большего числа запросов. Хотя это конечно зависит от базы данных, какой-нибудь MySQL с каким-нибудь движком с кривыми транзациями может вполне и загнуться от кучи мелких запросов… Но опять же, эти 20 запросов прекрасно превращаются в 10, с тем же объемом данных, если грамотно подойти к делу. А чтобы вытащить тот же объем из лишнего базе придется проделать бОльшую работу. Как уже говорили здесь, нормализация рулит.
А трафик в большистве случаев вообще локальный. И действительно, в большинстве случаев может не учитываться… Но это в большинстве. А меньшинство составляют Highload-проекты, где снижение трафика на сервере баз данных на 1/3 это существенный профит, ради которого разработчики не то что модели перелопатить, но и новую СУБД могут написать.
kmike тоже советует использовать отдельную модель для профиля…
Не важно один тип профиля или несколько. Важна производительность и удобство работы. Если в какой-то ситуации действительно удобно обращаться ко всем данным через одну модель и это не вызывает существенного спада производительности — можно использовать primate, как гарантию того, что вы не наткнетесь через манкипатчинг на какие-то грабли самостоятельно.
Я бы как раз позиционировал эту библиотеку как попытку избавить молодых джангистов от желания самостоятельно лезть в чужие структуры данных без особого на то повода.
Нет, здесь нужны две — auth.User начинается на auth, что как бы намекает. А myapp.Profile начинается на myapp. Не нужно смешивать независимые друг от друга данные без необходимости.
У меня для Вас плохие новости: джанговский ORM загружает модели полностью. Даже если Вы обращаетесь к username пользователя, сервер БД передаст и фамилию, и имя, и пароль (захешированный, конечно) и пресловутую сексуальную ориентацию.
Ну вот же! А ведь если разбить эти данные на несколько моделей, то мы получим возможность не передавать лишние. Лучше 20 мелких запросов, чем 10 но в 3 раза больших.
Чем вам не угодил подход с отдельной моделью профиля? Не понимаю, почему вдруг один из ключевых принципов теории реляционых баз данных стал костылем? УМВР, не было проблем с профилями пользователей.
По вашим пунктам:
> сложность поддержки
Запутаться??? Логин/пароль и допустим сексуальная ориентация пользователя — это же совершенно разные данные, умоляю, почему они все должны храниться в одном объекте? К тому же, что делать, если у меня вообще три разных типа профилей для пользователей, и в каждом свои данные?
> нецелевая растрата ресурсов
А не будет ли растратой ресурсов то, что я каждый раз подгружаю совершенно не нужные мне данные чтобы получить, допустим, список пользователей? (конечно даже если не указывать конкретные поля в запросе, django может быть оптимизирует всё что нужно, и лишние данные не будут передаваться, но всё равно семантика нарушается, и это всё уже зависит от того как напишешь)
> а ещё всё надо руками делать!
Ну вообще это нормально, не нужен мне профиль для какого-то пользователя — не буду создавать.
В общем не убедили вы меня в необходимости использования столь жесткого манкипатчинга в решении данной проблемы, но за статью про эту библиотеку всё равно спасибо — больше костылей, хороших и разных!
> WebMoney Transfer — строгая учетная система, данные не удаляются.
> Данные из системы не удаляются. Вы можете закрыть данные к просмотру и заблокировать WMID
> на вход в систему, написав с регистрационного e-mail в службу технической поддержки по E-mail
> support.wmtransfer.com/asp/services.asp.
> Регистрация производится на новый номер.
Относитесь спокойно к изменениям рейтинга.
Это замечание справедливо тогда, когда вы пытаетесь выполнить необходимую работу скриптом вместо того чтобы предоставить её базе данных. Здесь же, нагрузка от обработки лишнего объема данных (в данной ситуации 1/3 объема — лишние, а на практике обычно в таких ситуациях всё гораздо хуже), превзойдет нагрузку от обработки большего числа запросов. Хотя это конечно зависит от базы данных, какой-нибудь MySQL с каким-нибудь движком с кривыми транзациями может вполне и загнуться от кучи мелких запросов… Но опять же, эти 20 запросов прекрасно превращаются в 10, с тем же объемом данных, если грамотно подойти к делу. А чтобы вытащить тот же объем из лишнего базе придется проделать бОльшую работу. Как уже говорили здесь, нормализация рулит.
А трафик в большистве случаев вообще локальный. И действительно, в большинстве случаев может не учитываться… Но это в большинстве. А меньшинство составляют Highload-проекты, где снижение трафика на сервере баз данных на 1/3 это существенный профит, ради которого разработчики не то что модели перелопатить, но и новую СУБД могут написать.
Не важно один тип профиля или несколько. Важна производительность и удобство работы. Если в какой-то ситуации действительно удобно обращаться ко всем данным через одну модель и это не вызывает существенного спада производительности — можно использовать primate, как гарантию того, что вы не наткнетесь через манкипатчинг на какие-то грабли самостоятельно.
Я бы как раз позиционировал эту библиотеку как попытку избавить молодых джангистов от желания самостоятельно лезть в чужие структуры данных без особого на то повода.
Нет, здесь нужны две — auth.User начинается на auth, что как бы намекает. А myapp.Profile начинается на myapp. Не нужно смешивать независимые друг от друга данные без необходимости.
Ну вот же! А ведь если разбить эти данные на несколько моделей, то мы получим возможность не передавать лишние. Лучше 20 мелких запросов, чем 10 но в 3 раза больших.
По вашим пунктам:
> сложность поддержки
Запутаться??? Логин/пароль и допустим сексуальная ориентация пользователя — это же совершенно разные данные, умоляю, почему они все должны храниться в одном объекте? К тому же, что делать, если у меня вообще три разных типа профилей для пользователей, и в каждом свои данные?
> нецелевая растрата ресурсов
А не будет ли растратой ресурсов то, что я каждый раз подгружаю совершенно не нужные мне данные чтобы получить, допустим, список пользователей? (конечно даже если не указывать конкретные поля в запросе, django может быть оптимизирует всё что нужно, и лишние данные не будут передаваться, но всё равно семантика нарушается, и это всё уже зависит от того как напишешь)
> а ещё всё надо руками делать!
Ну вообще это нормально, не нужен мне профиль для какого-то пользователя — не буду создавать.
В общем не убедили вы меня в необходимости использования столь жесткого манкипатчинга в решении данной проблемы, но за статью про эту библиотеку всё равно спасибо — больше костылей, хороших и разных!