I should clarify that this is a top level node containing 25,000 children. From what I've seen on the web, this is a bad idea as the implication seems to be that only 10-15 nodes should be present at each level.
As an example, think about a book of recipes. In a relational DB, you could easily have a table of 25,000 recipes. It seems this doesn't work for a JCR as having a 'recipes' node with 25,000 'recipe' children would overwhelm the JCR. If that so, seems I need to look into linking CRX to a relational DB unless someone can offer suggestions on dealing with the 25,000 child recipes.
From what I've seen on the web, this is a bad idea as the implication seems to be that only 10-15 nodes should be present at each level.
I don't think this accurate. The most common number you will see is to not have more than 1000 nodes per hierarchy level.
There are a variety of factors that lead into this. In general, you will run into UI limitations well before raw repository performance becomes the primary factor.
For your use case, I would think there are a handful of ways to divide these - first letter, primary cuisine, date, etc.
Query performance should not be impacted by node structure.
Thanks Justin. My challenge is to convince die-hard relational guys that JCR is a viable alternative. I'd have to agree with them that limiting to 1,000 nodes at a hierarchy level by breaking up the dataset is a hack. That said, the power of having the dataset integrated into CQ5 is a counter-weight to that hack.
To be clear, this really has very little to do with JCR and more to do with the tools.