ASP.NET 2.0: How SqlProfileProvider Stores its Data...
This probably isn't entirely correct since I am just looking at the output (e.g. the database rows) to determine this. For each object in profile (i.e. Users), there is a single row in the aspnet_Profile table. This table is made up like so:
CREATE TABLE [aspnet_Profile] (
[UserId] [uniqueidentifier] NOT NULL,
[PropertyNames] [ntext] NOT NULL ,
[PropertyValuesString] [ntext] NOT NULL ,
[PropertyValuesBinary] [image] NOT NULL ,
[LastUpdatedDate] [datetime] NOT NULL )
The three middle columns are used to store the properties and their values. PropertyNames stores a list of properties with hints on how to retrieve it from the String or Binary column. For example:
Each section of this string is the metadata about the property:
- First is the name of a property. This needs to map directly to the property names in the web.config file.
- Then the place its to be stored (S = String, B = Binary). Note that the placement in String or Binary form is based on the datatype or the serialization format. XML Serialization ends up in Strings and binary serialization ends up in the binary area. It seems that numbers also end up in binary format.
- Start Position. For a string it's where in the string to start looking for that value. Understand that this will change as the size of the property changes. Using -1 in a Binary stored property seems to indicate that it is not stored at all. For example, the IsClient is a Boolean, but is stored as a string here, but Expired is also a boolean, but since it has a -1 we know it isn't actually stored.
- Length. If the start position is -1, there will be no length. Otherwise this is used to substring out the actual data in the string and binary fields.
As you would expect, the string field may be a mix of XML serialized data and string data. For example, the string field here is stored like so:
<?xml version="1.0" encoding="utf-16"?>
You'll notice that the first four characters are the word "True" which corresponds to the PropertyNames "IsClient:S:0:4:". Likewise I have a property called Services which is the XML Serialized piece at the end that corresponds to "Services:S:71:239:".
So far I like the profile stuff and luckily it is using the common provider model because the one glaring weakness here is searching. Finding all Users with a specific Property value is going to be very very difficult. My plan is to write my own provider that is a specialization of the SqlProfileProvider but normalizing the data into a PropertyName and Value table. I have not dug deep into the ramifications as it has to do with Groups or custom serialized types, but I don't think they will get in the way.
If anyone has any comment on this, I am very open to hear what you have to say.