Если я использую имя пользователя, или идентификатор пользователя к ссылке аутентифицировал пользователей в ASP.NET
Другое событие NullPointerException возникает, когда объявляется массив объектов, а затем сразу же пытается разыменовать его внутри.
String[] phrases = new String[10];
String keyPhrase = "Bird";
for(String phrase : phrases) {
System.out.println(phrase.equals(keyPhrase));
}
Этот конкретный NPE можно избежать, если порядок сравнения отменяется ; а именно, использовать .equals для гарантированного непустого объекта.
Все элементы внутри массива инициализируются их общим начальным значением ; для любого типа массива объектов, это означает, что все элементы null.
Вы должны инициализировать элементы в массиве перед доступом или разыменованием их.
String[] phrases = new String[] {"The bird", "A bird", "My bird", "Bird"};
String keyPhrase = "Bird";
for(String phrase : phrases) {
System.out.println(phrase.equals(keyPhrase));
}
11 ответов
Я предложил бы использовать имя пользователя в качестве первичного ключа в таблице, если имя пользователя будет уникальным, существует несколько серьезных оснований сделать это:
- первичный ключ будет кластерным индексом и таким образом искать, пользовательские детали через их имя пользователя будут очень быстры.
- Это будет мешать дублирующимся именам пользователей появиться
- , Вы не должны волноваться об использовании двух различных частей информации (имя пользователя или гуид)
- , Это сделает написание кода намного легче из-за не необходимости к поиску два бита информации.
Необходимо использовать некоторый уникальный идентификатор, или GUID, который Вы упоминаете или некоторый другой автоматический сгенерированный ключ. Однако это число никогда не должно быть видимо пользователю.
А огромное преимущество этого - то, что весь Ваш код может работать над идентификатором пользователя, но имя пользователя действительно не связывается с ним. Затем пользователь может изменить их имя (который я нашел полезными на сайтах). Это особенно полезно, если Вы используете адрес электронной почты в качестве входа в систему пользователя..., который очень удобен для пользователей (затем, они не должны помнить 20 идентификаторов в случае, если их идентификатор обычного пользователя является популярным).
Я использовал бы идентификатор пользователя. Если Вы хотите использовать имя пользователя, Вы собираетесь делать "изменение именем пользователя" функция очень дорогой.
Необходимо использовать UserID. Это - свойство ProviderUserKey MembershipUser.
Guid UserID = new Guid(Membership.GetUser(User.Identity.Name).ProviderUserKey.ToString());
Я обычно использовал бы автоматическое число постепенного увеличения интервал
, Вы хотите сохранить размер ключа как можно меньше. Это сохраняет Ваш индекс небольшим и приносит пользу любым внешним ключам также. Additonally Вы не сильно связываете дизайн данных к данным внешнего пользователя (это сохраняется для aspnet GUID также).
Обычно GUID не делают хорошие первичные ключи, поскольку они являются большими, и вставки могут произойти в потенциально любой странице данных в таблице, а не в последней странице данных. Основное исключение к этому - то, если Вы работаете, mutilple копировал базы данных. GUID очень полезны для ключей в этом сценарии, но я предполагаю, что у Вас только есть одна база данных, таким образом, это не проблема.
Если бы Вы собираетесь быть использованием LinqToSql для разработки, я рекомендовал бы использовать Интервал в качестве первичного ключа. У меня было много проблем, когда мне создали отношения прочь немеждународных полей, даже когда nvarchar (x) поле имел ограничения для создания этого уникальным полем.
я не уверен, является ли это известной ошибкой в LinqToSql или что, но у меня были проблемы с ним на текущем проекте, и я должен был выгрузить PKs и FKs на нескольких таблицах.
Я соглашаюсь с Mike Stone. Я также предложил бы только использовать GUID в конечном счете, Вы собираетесь быть отслеживанием огромного объема данных. Иначе простой автоматический увеличивающий целочисленный столбец (Id) будет достаточен.
при необходимости в GUID.NET достаточно прекрасна, который можно получить один простым...
Dim guidProduct As Guid = Guid.NewGuid()
или
Guid guidProduct = Guid.NewGuid();
Я соглашаюсь с Mike Stone также. Моя компания недавно реализовала новую пользовательскую таблицу для внешних клиентов (в противоположность внутренним пользователям, которые проходят проверку подлинности через LDAP). Для внешних пользователей мы приняли решение сохранить GUID как первичный ключ и сохранить имя пользователя как varchar с ограничениями на уникальность данных на поле имени пользователя.
кроме того, если Вы собираетесь сохранить поле пароля, я настоятельно рекомендую хранение пароля как соленое, хешировал двоичный файл в базе данных. Таким образом, если бы кто-то должен был взломать Вашу базу данных, у них не было бы доступа к паролям Вашего клиента.
Я бы использовал guid в своем коде и, как уже упоминалось, адрес электронной почты в качестве имени пользователя. Ведь это уже уникальный и запоминающийся для пользователя. Возможно, даже откажитесь от guid (v. Дискуссионный).
Кто-то упомянул использование кластерного индекса для GUID, если он использовался в вашем коде. Я бы избегал этого, особенно, если вставки высоки; индекс будет перестраиваться каждый раз, когда вы вставляете запись. Кластерные индексы хорошо работают на идентификаторах автоинкремента, потому что только новые записи добавляются.
Я согласен с Палмси, Хотя, похоже, в его коде есть небольшая ошибка:
Guid UserID = new Guid(Membership.GetUser(User.Identity.Name)).ProviderUserKey.ToString());
должно быть
Guid UserID = new Guid(Membership.GetUser(User.Identity.Name).ProviderUserKey.ToString());
Я бы сказал, используйте UserID, чтобы имена пользователей можно было изменять, не затрагивая первичный ключ. Я бы также сделал столбец имени пользователя уникальным, чтобы не дублировать имена пользователей.
Если вы в основном будете искать по имени пользователя, а не по идентификатору пользователя, сделайте имя пользователя кластеризованным индексом и установите для первичного ключа некластеризованный. Это даст вам самый быстрый доступ при поиске имен пользователей, но если вы будете в основном искать UserIds, оставьте это как кластерный индекс.
Изменить: это также будет лучше соответствовать текущим таблицам членства ASP.Net, поскольку они также используют UserID в качестве первичного ключа.