ASP.NET 2.0 Membership

[Ray Booysen]

Hi all

I am using the membership provider and am storing all the login details
via this system.

However, I require to add additional fields that may change over time
that are related to the User. E.g. DOB, Place of birth and all that.

What is the best way to do this? Create a second table taking the
primary key of the aspnet_Users table and use this as a foreign key in
my new table?

Can I extend the provider to take these new fields? If so, how do I
change it in case of new fields?

Regards
Ray

[Riki]

Try using profiles. They are a built in extension for the membership
provider.

--

Riki

"Ray Booysen" <rj***********@rjb.za.net> wrote in message
news:e6*************@TK2MSFTNGP05.phx.gbl...

Hi all

I am using the membership provider and am storing all the login details
via this system.

However, I require to add additional fields that may change over time that
are related to the User. E.g. DOB, Place of birth and all that.

What is the best way to do this? Create a second table taking the primary
key of the aspnet_Users table and use this as a foreign key in my new
table?

Can I extend the provider to take these new fields? If so, how do I
change it in case of new fields?

Regards
Ray

[Ray Booysen]

Thanks, I'll take a look!

Regards
Ray

Riki wrote:

Try using profiles. They are a built in extension for the membership
provider.

--

Riki

"Ray Booysen" <rj***********@rjb.za.net> wrote in message
news:e6*************@TK2MSFTNGP05.phx.gbl...

Hi all

I am using the membership provider and am storing all the login details
via this system.

However, I require to add additional fields that may change over time that
are related to the User. E.g. DOB, Place of birth and all that.

What is the best way to do this? Create a second table taking the primary
key of the aspnet_Users table and use this as a foreign key in my new
table?

Can I extend the provider to take these new fields? If so, how do I
change it in case of new fields?

Regards
Ray

[Erik Funkenbusch]

On Tue, 02 May 2006 10:59:33 +0100, Ray Booysen wrote:

However, I require to add additional fields that may change over time
that are related to the User. E.g. DOB, Place of birth and all that.
No, that's not what membership is about. Membership is not a full user
store, it's merely a way to verify authentic users.
What is the best way to do this? Create a second table taking the
primary key of the aspnet_Users table and use this as a foreign key in
my new table?
Yes, that's a good solution.
Can I extend the provider to take these new fields? If so, how do I
change it in case of new fields?

No, Like I said, Membership is not a general data store. You should write
your own routines to access this data seperately. Trying to tie it into
the membership provider is always a recipe for headaches.

[clintonG]

Let's say you store the properties of each Member as a Profile and want to
query the data for all members from Milwaukee for example or all males over
the age of 35 or whatever. The entire profile for each member is stored as a
series of characters concatenated to one another and stuffed into a single
column. The algorythm for parsing a series of characters concatenated to one
another without a delineator is done how? The answer is we have to write a
sh!tload of code after figuring out how to interpret an undocumented schema
that is present in the Profile table itself.

//A Profile Entry Example:
ClintonGallagherWauwatosaWisconsin53226MilwaukeeCo untyMale5241477415624147741562http://clintongallagher.metromilwaukee.com

See what I mean?
AFIC Profiles are FUBAR and only marginally useful as a replacement for the
Session object for issues related to the state of the application, i.e data
that is not queried intending to be returned as a group of related records.

Somebody correct me if this is wrong...

--
<%= Clinton Gallagher
NET csgallagher AT metromilwaukee.com
URL http://clintongallagher.metromilwaukee.com/
"Ray Booysen" <rj***********@rjb.za.net> wrote in message
news:OA****************@TK2MSFTNGP02.phx.gbl...

Thanks, I'll take a look!

Regards
Ray

Riki wrote:

Try using profiles. They are a built in extension for the membership
provider.

--

Riki

"Ray Booysen" <rj***********@rjb.za.net> wrote in message
news:e6*************@TK2MSFTNGP05.phx.gbl...

Hi all

I am using the membership provider and am storing all the login details
via this system.

However, I require to add additional fields that may change over time
that are related to the User. E.g. DOB, Place of birth and all that.

What is the best way to do this? Create a second table taking the
primary key of the aspnet_Users table and use this as a foreign key in
my new table?

Can I extend the provider to take these new fields? If so, how do I
change it in case of new fields?

Regards
Ray

[Ray Booysen]

clintonG wrote:

Let's say you store the properties of each Member as a Profile and want to
query the data for all members from Milwaukee for example or all males over
the age of 35 or whatever. The entire profile for each member is stored as a
series of characters concatenated to one another and stuffed into a single
column. The algorythm for parsing a series of characters concatenated to one
another without a delineator is done how? The answer is we have to write a
sh!tload of code after figuring out how to interpret an undocumented schema
that is present in the Profile table itself.

//A Profile Entry Example:
ClintonGallagherWauwatosaWisconsin53226MilwaukeeCo untyMale5241477415624147741562http://clintongallagher.metromilwaukee.com

See what I mean?
AFIC Profiles are FUBAR and only marginally useful as a replacement for the
Session object for issues related to the state of the application, i.e data
that is not queried intending to be returned as a group of related records.

Somebody correct me if this is wrong...

Do the profiles API not expose methods to retrieve all profiles for all
users?

[clintonG]

That's a documentation question ainna?

--
<%= Clinton Gallagher
NET csgallagher AT metromilwaukee.com
URL http://clintongallagher.metromilwaukee.com/
"Ray Booysen" <rj***********@rjb.za.net> wrote in message
news:eO**************@TK2MSFTNGP03.phx.gbl...

clintonG wrote:

Let's say you store the properties of each Member as a Profile and want
to query the data for all members from Milwaukee for example or all males
over the age of 35 or whatever. The entire profile for each member is
stored as a series of characters concatenated to one another and stuffed
into a single column. The algorythm for parsing a series of characters
concatenated to one another without a delineator is done how? The answer
is we have to write a sh!tload of code after figuring out how to
interpret an undocumented schema that is present in the Profile table
itself.

//A Profile Entry Example:
ClintonGallagherWauwatosaWisconsin53226MilwaukeeCo untyMale5241477415624147741562http://clintongallagher.metromilwaukee.com

See what I mean?
AFIC Profiles are FUBAR and only marginally useful as a replacement for
the Session object for issues related to the state of the application,
i.e data that is not queried intending to be returned as a group of
related records.

Somebody correct me if this is wrong...

Do the profiles API not expose methods to retrieve all profiles for all
users?

[Ray Booysen]

clintonG wrote:

Let's say you store the properties of each Member as a Profile and want to
query the data for all members from Milwaukee for example or all males over
the age of 35 or whatever. The entire profile for each member is stored as a
series of characters concatenated to one another and stuffed into a single
column. The algorythm for parsing a series of characters concatenated to one
another without a delineator is done how? The answer is we have to write a
sh!tload of code after figuring out how to interpret an undocumented schema
that is present in the Profile table itself.

//A Profile Entry Example:
ClintonGallagherWauwatosaWisconsin53226MilwaukeeCo untyMale5241477415624147741562http://clintongallagher.metromilwaukee.com

See what I mean?
AFIC Profiles are FUBAR and only marginally useful as a replacement for the
Session object for issues related to the state of the application, i.e data
that is not queried intending to be returned as a group of related records.

Somebody correct me if this is wrong...

ProfileInfoCollection profiles = ProfileManager.GetAllProfiles();

I don't see how your problem occurs now?

With this collection we can write simple code to retrieve the
information we require.

Am I missing something?

Regards
Ray

[Erik Funkenbusch]

On Tue, 02 May 2006 23:10:07 +0100, Ray Booysen wrote:

ProfileInfoCollection profiles = ProfileManager.GetAllProfiles();

I don't see how your problem occurs now?

With this collection we can write simple code to retrieve the
information we require.

One problem is one of scale. Suppose you have 1 million users. You now
have to retrieve all 1 million profiles, then write code to iterate over
them rather than using a simple SQL query to only return the profiles you
are interested in.

Apart from the huge amount of memory this will use, it will also allocate a
lot of small objects, then have to destroy them in GC, all of which suck up
system resources.

[Brock Allen]

> AFIC Profiles are FUBAR and only marginally useful as a replacement

for the
Session object for issues related to the state of the application, i.e
data
that is not queried intending to be returned as a group of related
records.
Somebody correct me if this is wrong...

Profile is meant to be long term storage of user data, which is different
than the intent of session. The odd persistence choice you're commenting
on is an aspect of the SqlProfileProvider. You can choose a different provider
which can store your data differently. I'd suggest googling for the "Table
Profile Provider" which is a sample provider from MSFT that will store each
profile property in a distinct column in your database.

-Brock
http://staff.develop.com/ballen

[clintonG]

Damn Brock your one very useful dude :-) Thanls for the heads up.

--
<%= Clinton Gallagher
NET csgallagher AT metromilwaukee.com
URL http://clintongallagher.metromilwaukee.com/
"Brock Allen" <ba****@NOSPAMdevelop.com> wrote in message
news:b8************************@msnews.microsoft.c om...

AFIC Profiles are FUBAR and only marginally useful as a replacement
for the
Session object for issues related to the state of the application, i.e
data
that is not queried intending to be returned as a group of related
records.
Somebody correct me if this is wrong...

Profile is meant to be long term storage of user data, which is different
than the intent of session. The odd persistence choice you're commenting
on is an aspect of the SqlProfileProvider. You can choose a different
provider which can store your data differently. I'd suggest googling for
the "Table Profile Provider" which is a sample provider from MSFT that
will store each profile property in a distinct column in your database.

-Brock
http://staff.develop.com/ballen