People sometimes mistake skinny tables as a convenient means of remedying performance issues, but skinny tables might not accommodate all use cases, or improve performance more than reading from the base Salesforce object with efficient indexes.
They come with “side effects” that you should understand, as they might restrict or burden your business processes.
Before implementing skinny tables, consider the following.
1. Skinny tables are skinny. To ensure optimal performance, they contain only the minimum set of fields required to fulfill specific business use cases. If you later decide to add a field to your report or SOQL query, contact salesforce.com Customer Support to re-create the table.
2. You might think, “Why not just add all the fields at the beginning to get around the previous limitation?” Salesforce.com can add up to only 100 fields, and those fields must be of a certain type.
For example, formula fields, fields derived from other objects (i.e., through lookup fields), and large CLOB fields cannot be added—if they were, we wouldn’t be calling skinny tables “skinny” at all.
Check out Benefits of Using Skinny Tables In Salesforce here !!!
3. Skinny tables don’t get copied over to sandbox organizations. This limitation might not be an issue for you, but to keep your production and sandbox environments consistent, you must track your changes and work with salesforce.com Customer Support to keep your environments in sync.
4. Skinny tables are custom tables in the underlying Force.com database. They don’t have the dynamic metadata flexibility you find in the base object. If you alter a field type (e.g., change a number field to a text field) the skinny table becomes invalid, and you must contact salesforce.com Customer Support to create a new skinny table.