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

второй подход лучше, но тоже не очень из-за (pkey, PropertyName (nvarchar), PropertyValue) .

Лучше сделать 3 или более таблиц, вроде

нормальную инфу, то что будете использовать ( пол, возраст, страна, город, адрес и т.д.) храните в
в Profiles, а всякий "мусор" можно хранить в ProfilesAddInfo.

Если появляется требование xранить дополнительную информацию то можно или изменит Profiles и добавить туда доп. поле, например в случае если надо хранить номер телефона, или добавлять данные в ProfilesAddInfo, если дупистим появилось требование хранить какое-нибудь инфо вроде (ЦветБрасетки text)

AxelTv
Не понимаю, зачем в вашем случае выносить основную инфу в таблицу Profiles, а не в Users. Насколько критична разница во времени выполнения поиска пользователей по "основному полю" из Profiles и по "дополнительному" из ProfilesAddInfo?

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

"на сколько быстрее?":
при небольшом кол-ве записей ( < 10М ) и стандартном оборудовании (modern x86 / х86_64 hardware) существенной разницы по скорости не будет, даже учитывая тот факт что индекс по основному полю в Profiles сделать проще чем partial index (если оный поддерживает ваш север бд) по доп. полям в ProfilesAddInfo. Просто если данные представляют определённую ценность т.е. бизнес-требования налагают определённые ограничения на корректность данных, то это намного проще сделать в случае с основными полями в Profiles (т.е. пол -> подстановка из списка, max_year <год рождения < min_year и тд.) чем с данными сохранёнными в виде (id, AttrName, AttrValue)

BelyИ тем неменее весь мир упорно прется по этому неправильному пути на "пикник-анкетирование". А вы им раскрыли глаза...


PS: Прочитайте про EAV.
И прикиньте сколько будет формироваться аналитика по паре млн. анкет с фильтрацией по 10 условиям (разными условиями: сравнение по значению, комбинации AND и OR, заполнено/не заполнено) и группировкой по 3-м полям, например...

После этого советуйте.

PS2: EAV структуры кажутся решением всех проблем хранения атрибутов, но при этом в реальной жизни создают много неудобств в обработке данных.

2 Bely
про то что "весь мир" проектирует базы виде одной большой таблицы вы меня не убедили.

Я знаю о существовании EAV модели, и таковая имеет смысл если данные не несут особого смысла кроме как для приложения которое их использует (хранения сереализованых данных классов и проч). В других случаях часто имеются требование по обеспечению корректности данных, а вот тут у EAV-модели проблемы.