The reason that Neural Networks doesn't support table prediction is precisely to avoid situations where you could create models to predict 100,000 attributes. Essentially what you are asking the model to do is to create 100,000 simultaneous neural networks. Each of these networks would have 100,000 input nodes, somewhere on the order of 100,000 squared hidden nodes and one output node. A few calculations would determine that the memory required to solve such a problem would be enormous, and you likely wouldn't want to wait until it completed even if you had the memory.
For example, take your 100,000 attribute problem as input and predict a case-level attribute. Time that and multiply by 100,000 (if you have a dual proc box, divide by 2!). Yes, that's how long it would theoretically take assuming you had enough memory.
Let me know if you disagree that the problem you are trying to solve isn't likely suitable for NN. I would try Naive Bayes or Decision Trees for this problem. Logistic Regression may also work, but I'm unsure of it's nested table requirements.
Logistic Regression cannot handle nested table predictions either. Do all the attributes have to be predictable
You should make the attributes you want to predict case level attributes and put all of the other attributes in a nested table which will be input only. For example "Friendly" and "Rich" will be case level attributes with values 0 or 1 and the other attributes will just be nested keys, e.g. something like this.
CREATE MINING STRUCTURE DatingStructure
(
[UserID] LONG KEY,
Friendly LONG DISCRETE,
Rich LONG DISCRETE,
Attributes TABLE
(
Attribute TEXT KEY
)
)
ALTER MINING STRUCTURE DatingStructure
ADD MINING MODEL DatingModel
(
UserID,
Friendly PREDICT,
Rich PREDICT,
Attributes (Attribute)
) USING Microsoft_Neural_Nets
You will need two tables - one that has the UserId and the first two columns for each case, and the second that is a transactional table containing a column for the UserId and the Attribute name. Note that if you have the same user twice, you will need a different userid for each one to represent that user. Eg. Simon1 and Simon2 or whatever. Usually you can make a compound key by appending two columns (e.g. the name and the date). The only requirement is that the UserID in the case table and the UserID in the nested table match.