Please start any new threads on our new
site at https://forums.sqlteam.com. We've got lots of great SQL Server
experts to answer whatever question you can come up with.
Author |
Topic |
SamC
White Water Yakist
3467 Posts |
Posted - 2003-08-05 : 08:40:42
|
I've got a requirement to customize small amounts of page content on a client by client basis.In ASP, it's pretty easy to code the content for each client's <%=strClientname%>A framework to move forward might be a single table in the database to hold the content:CREATE TABLE dbo.Content (ClientID INT NOT NULL ,VarName VARCHAR (100) ,Content VARCHAR (3000))It's another roundtrip to the database for every page, but a SP could be written to return a recordset of all Client specific content...SELECT VarName, Content FROM dbo.Content WHERE ClientID = @ClientIDImplementing this so it is transparent and the content can be easily referenced is a mixed bag of tradeoffs. If the number of snippets are small, then it may be reasonable to read them all into every page, store them in a hash table and use them where needed:Response.Write "Welcome " & MyHash("Clientname")------------------------If the number of snippets grows large in number or content, then this method will begin to have performance problems eventually. The road to designing scalable content rendering splits into many directions, each with different merits and trade-offs.I am looking for suggestions from anyone who may have implemented something like this.Sam |
|
setbasedisthetruepath
Used SQL Salesman
992 Posts |
Posted - 2003-08-05 : 09:33:18
|
I've done this before using XML / XSLT to avoid peppering the page with Response.Write calls in the classic ASP model, and subclassing in the ASP.NET model.Jonathan{0} |
 |
|
mohdowais
Sheikh of Yak Knowledge
1456 Posts |
Posted - 2003-08-05 : 10:01:45
|
quote: I've got a requirement to customize small amounts of page content on a client by client basis.
hah! did the management tell you that?! you can bet they were lying! "Huh? It's small, isn't it? That's only 98 snippets!"Seriously though, I dont think you'll face major performance problems if you retreive data on a page-to-page basis. If you dont expect a very large number of concurrent users, you can also think of storing the hash table for each client in a Session variable. This way you just have to retreive the data once for each session. But this will not scale very well, and for a heavy-traffic site, it can easily eat up all available memory on the server. Jonathan, your experience sounds interesting. Can we get a little more info on what you did?Owais |
 |
|
SamC
White Water Yakist
3467 Posts |
Posted - 2003-08-05 : 10:06:12
|
What I'd like to do is port the whole enchelada to the RAINBOW content management system. The day to day stuff never stops, so I doubt I'll have time for that, or to migrate to an XML solution (pass the pepper please).Yes, management believes "small", but we know that won't last.I guess I'll add a page index to pull page specific info when needed.Sam |
 |
|
setbasedisthetruepath
Used SQL Salesman
992 Posts |
Posted - 2003-08-05 : 11:31:45
|
Here I was laboring under the impression that you were management, Sam .It depends what you mean by customizing content. Does it mean showing different data to different consumers, or does it mean showing the same data in different ways to different consumers? If the latter, then XML/XSLT is a good way to go, although yes there is a significant effort involved initially. If the former, then you might consider MSFT's content management server for big things, else the five-finger method for small things .Jonathan{0} |
 |
|
|
|
|
|
|