I'll probably have the unpopular opinion as well but this application is well beyond the groupware/loosely structured/disconnected/RAD fitpoints that Domino Excels at.
Some databases (SQL Server 2005 and Oracle that I know of) can automatically partition the database into separate physical files based on critieria you specify, such as blog owner (or month or anything else). This typically simplifies archive, delete and restore requests in addition to the performance gain. If you issue a statement to drop all records by owner X, the database is often smart enough to know that the statement can be handled by merely dropping the partition file rather than going after individual rows. Why try to write functionality that is already available.
My guess is that the users are going to be editing with an online editor, rather than using a Notes client and therefore, Notes doesn't provide any advantage in terms of content editing or storage for that matter. If anything, Notes has limitations on text fields (for html storage) that you'll wind up having to code around.
While domain searching is fast, you cannot narrow the search based on field criteria (such as not [status]=draft) and you can't manipulate the results since its not returning a collection.
A use case like this could benefit from some amount of partial page cacheing and you won't get that from Domino (by itself).
I think sometimes Domino gets a bad wrap when we shoehorn it into a use case that does not fit the platform. What the customer wants is completely separate from what the right choice is. Knowing full well that you are a respected Domino developer, if you tell them this not a good Domino fit, they should be respecting the fact that you are trying to steer them to the best solution and not towards one that puts pounds in your pocket. You don't pull up a roadway with a chisel right?
I'll probably have the unpopular opinion as well but this application is well beyond the groupware/loosely structured/disconnected/RAD fitpoints that Domino Excels at.
Some databases (SQL Server 2005 and Oracle that I know of) can automatically partition the database into separate physical files based on critieria you specify, such as blog owner (or month or anything else). This typically simplifies archive, delete and restore requests in addition to the performance gain. If you issue a statement to drop all records by owner X, the database is often smart enough to know that the statement can be handled by merely dropping the partition file rather than going after individual rows. Why try to write functionality that is already available.
My guess is that the users are going to be editing with an online editor, rather than using a Notes client and therefore, Notes doesn't provide any advantage in terms of content editing or storage for that matter. If anything, Notes has limitations on text fields (for html storage) that you'll wind up having to code around.
While domain searching is fast, you cannot narrow the search based on field criteria (such as not [status]=draft) and you can't manipulate the results since its not returning a collection.
A use case like this could benefit from some amount of partial page cacheing and you won't get that from Domino (by itself).
I think sometimes Domino gets a bad wrap when we shoehorn it into a use case that does not fit the platform. What the customer wants is completely separate from what the right choice is. Knowing full well that you are a respected Domino developer, if you tell them this not a good Domino fit, they should be respecting the fact that you are trying to steer them to the best solution and not towards one that puts pounds in your pocket. You don't pull up a roadway with a chisel right?