Best practices for huge databases joined to a featureclass

[StephenLead]

I'm seeking some advice on best practices for handling datasets with hundreds of attributes. (I made a typo in the subject of this thread - the attributes would be part of the featureclass, not joined to it.)

I'm building some polygon featureclasses from raw census tables, which contain hundreds of fields. I'd like to leave all of the attributes on the featureclasses (rather than stripping off the ones I don't currently need), so I can be flexible about which attributes to show at a later date.

Does anyone have any advice on how this will affect performance?

1) is it a bad idea to have a file geodatabase featureclass with hundreds of attributes?

2) is it a bad idea to create a map service from this featureclass, containing hundreds of attributes?

3) is there a performance implication if I build a featureLayer in the JS API, and only specify the attributes I currently need?

eg, the map service might contain 500 attributes, but I define my feature layer using

featureLayer.fields = [x, y, z]

Thanks for any advice, and please let me know if you need any further details.

Steve

[HemingZhu]

I'm seeking some advice on best practices for handling datasets with hundreds of attributes. (I made a typo in the subject of this thread - the attributes would be part of the featureclass, not joined to it.)

I'm building some polygon featureclasses from raw census tables, which contain hundreds of fields. I'd like to leave all of the attributes on the featureclasses (rather than stripping off the ones I don't currently need), so I can be flexible about which attributes to show at a later date.

Does anyone have any advice on how this will affect performance?

1) is it a bad idea to have a file geodatabase featureclass with hundreds of attributes?

2) is it a bad idea to create a map service from this featureclass, containing hundreds of attributes?

3) is there a performance implication if I build a featureLayer in the JS API, and only specify the attributes I currently need?

eg, the map service might contain 500 attributes, but I define my feature layer using

featureLayer.fields = [x, y, z]

Thanks for any advice, and please let me know if you need any further details.

Steve

Very good questions. Be nice to see more discussion about these.

Here are my thoughts and reads

1) is it a bad idea to have a file geodatabase featureclass with hundreds of attributes?

Not that i know of except a file geodatabase featureclass allows only one user at a time can edit the same data. So no editable feature layer allowed.

2) is it a bad idea to create a map service from this featureclass, containing hundreds of attributes?

map service include not only the geometries but also the attributes. It would properly be better to make only needed field visible in your .mxd or msd to cut the traffic volumn between server and client.

3) is there a performance implication if I build a featureLayer in the JS API, and only specify the attributes I currently need?

I think the No. of records in a featureclass is more of a x factor than the No. of fields in a featureclass while building a featureLayer. In terms of the No. of attributes, see Quotes from the ESRI:

"....feature layers bring geometry information across to the client computer to be drawn by the Web browser. Feature layers potentially cut down on round trips to the server. A client can request the features it needs, then perform selections and queries on those features without having to request more information from the server. Feature layers are especially appropriate for layers that respond to user interaction, such as a mouse click or hover."

Choosing the attributes you need
"Feature layers not only retrieve feature geometries; they can also get attribute information. When you create the feature layer, you can specify which attributes, or "out fields" will be retrieved for your features. It's possible to just request "*" to get all the fields, but to reduce the amount of information sent between the client and server, you should request only the fields you need in your application. If you later perform a query using the feature layer, the query will honor the out fields you set."

[StephenLead]

Thanks for the tips. I guess I'll just have to experiment and see the results, as everyone seems to have different opinions on whether it'll cause a performance problem, but no hard evidence either way!

A suggestion from an ESRI Australia expert was to build the relate at the REST API level - http://help.arcgis.com/en/arcgisserver/10.0/apis/rest/queryrelatedrecords.html

I'll let you know how it goes.