asp.net поставщик профиля

Question

Я знаю, что уже есть некоторые вопросы по этой теме на сайте ...

Я просто пытаюсь понять, если это безопасно использовать ASP.NET Profile Provider с веб-сайта с огромным трафиком?

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

(я просто пытаюсь, чтобы убедиться, что я не хватает чего-то об этом, потому что я довольно новыми для него.)

Answer 1

Поставщик профиля использует EAV (Entity-Attribute-Value) дизайн намеренно, потому что профили в целом очень обычно имеют малонаселенную схему, т. е. существует много потенциальных атрибутов, но лишь немногие будут использоваться для данного единого объекта, а некоторые из них будут широко варьироваться от одного объекта к другому.

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

Но что делать, если ваше заявление делает возраст обязательным? Хорошо, этот столбец заполняется для всех. Но что, если вам нужно сделать заметку в профиле, «пользователь больше не хочет видеть этот неясный диалог». Вам действительно нужен столбец для каждого отдельного диалога в вашем приложении, хочет ли пользователь его увидеть? Возможно нет. Когда вы попадаете в маленькие разовые детали применения любого значительного объема, EAV фактически становится более экономичным выбором.

В целом он очень хорошо масштабируется (гораздо лучше, чем вы, вероятно, думаете). В конкретном случае это не имеет значения - как всегда, используйте то, что работает и исправляет проблемы с производительностью , когда они появляются. Независимо от ограничений масштабируемости провайдера профиля, вы узнаете, когда их ударили. Я гарантирую две вещи: (1) вам придется исправить множество других проблем с производительностью, которых вы не ожидали, прежде чем исправлять это; и (2) если ваш сайт получает достаточно трафика, чтобы разорвать поставщика профилей, это хорошая проблема.

Answer 2

Я согласен с Rex M, если вам не нужно делать такие вещи, как сортировать всех своих пользователей по возрасту или выполнять другие процедуры с данными совокупного профиля. Тогда вы могли бы подумать о том, чтобы кататься самостоятельно. Но для простого хранения свойств, которые вы получаете здесь и там по отдельности, Rex M является правильным.

Answer 3

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