Heute habe ich mich noch mal um die Suche in Benutzerprofilen bzw. in der Tabelle ASPNET_PROFILE gekümmert. Um wirklich eine gute Performance zu erreichen. wird man nicht eine redundanten Datenhaltung nicht vermeiden können.
Um nicht den DotNetNuke - Core, Tabellen oder aber die Stored Proceduren von DNN zu verändern, habe ich mich dann für Trigger direkt im MS SQL Server entschieden.
Die Erstellung des Triggers war zunächst etwas problematisch, da man innerhalb eines Trigger nicht auf ein Feld vom Typ "nText" zugreifen kann. Änder der Datentypen wollte ich ja vermeiden und so habe ich einfach die Daten aus der Orginaltabelle gelesen.
Klappt perfekt und die redundante Datenhaltung tut jetzt auch schon fast gar nicht mehr weh :)
Wichtig ist nur das man mit einem Trigger arbeitet, der ausgelöst wird nachdem die Aktion insert ode update durchgeführt wurde.
Beispielhaft sieht das dann so aus:
CREATE TRIGGER GaliNeo_ASPPROFILE_Update ON [dbo].[aspnet_Profile] FOR INSERT, UPDATE
AS
DECLAR @sPostalCode varchar(5)
DECLARE @sUserId char(100)
DECLARE @iUserId int
DECLARE @sUserName nvarchar(50)
/*die aktuelle UserId ermittlen, die vom update betroffen ist */
select @sUserId=Userid from inserted
/*Benutzername aus der Tabelle ermittlen, damit die DNN-UserId ermittelt werden kann*/
SELECT @sUserName = [UserName] FROM ASPNET_USERS WHERE [UserId] = @sUserId
/*Die DNN-UserId wird ermittlet */
SELECT @iUserId = [UserId] FROM Users WHERE [UserName] = @sUserName
/*Ermitteln der geänderten Daten direkt aus der Orginaltabelle */
SELECT
@sPostalCode=dbo.fn_GetProfileElement('PostalCode',PropertyNames,PropertyValuesString)
FROM ASPNET_PROFILE
WHERE [USERID] = @sUserId
IF ((SELECT count(*) FROM GaliNeo_User_Profile WHERE [UserId] = @iUserId)= 0)
begin
INSERT INTO GaliNeo_User_Profile
(
[UserId],
[PostalCode],
)
VALUES
(
@iUserId,
@sPostalCode,
)
end
else
begin
UPDATE GaliNeo_User_Profile SET
[PostalCode] = @sPostalCode
WHERE [UserId] = @iUserId
end