the CREATE TABLE statement. Sparse columns optimize the storage of NULL values (which now take up no space at all) and are useful when the majority records in a table will have NULL values for that column. Indexes on sparse columns are also optimized: only those rows with values are indexed. In addition, the contents of all sparse columns in a particular row of a table can be collectively aggregated into a single XML column (a column set), whose contents are of the form [<column-name>column contents </column-name>]*.... In fact, if a column set is defined for a table as part of a CREATE TABLE statement, all sparse columns subsequently defined are typically added to it. This has the interesting consequence that the SQL statement SELECT * from <tablename> will not return the individual sparse columns, but concatenate all of them into a single XML column whose name is that of the column set (which therefore acts as a virtual, computed column). Sparse columns are convenient for business applications such as product information, where the applicable attributes can be highly variable depending on the product type, but where the total number of variable attributes per product type are relatively modest. Limitations of sparse attributes However, this approach to modeling sparse attributes has several limitations: rival DBMSs have, notably, chosen not to borrow this idea for their own engines. Limitations include: The maximum number of sparse columns in a table is 10,000, which may fall short for some implementations, such as for storing clinical data, where the possible number of attributes is one order of magnitude larger. Therefore, this is not a solution for modeling *all* possible clinical attributes for a patient. Addition of new attributes – one of the primary reasons an EAV model might be sought – still requires a DBA. Further, the problem of building a user interface to sparse attribute data is not addressed: only the storage mechanism is streamlined. * Applications can be written to dynamically add and remove sparse columns from a table at run-time: in contrast, an attempt to perform such an action in a multi-user scenario where other users/processes are still using the table would be prevented for tables without sparse columns. However, while this capability offers power and flexibility, it invites abuse, and should be used judiciously and infrequently. It can result in significant performance penalties, in part because any compiled query plans