Question: I have a table called `assets`, where an asset can belong to a user,team, or division, and possibly multiple of each. My issue is that the assets are highly variable, and can have properties associated with them that are different for each one.

ex. These could be assets:

```
1.)
type:workbench
cost:200
vendor:Acme Co.
color:black
2.)
type:microscope
serial_no:BH-00102
purchase_date:1337800923
cost:2040

```

and this could go on for hundreds to thousands of different types of assets.

How would I store this type of data in a normalized way that would be easy to query, without altering my tables every time a new asset type is added? Some of the fields are the present across all assets too, such as cost.

So far I figure that I should have:

```
assets
id,cost,purchase_date,asset_type_id

asset_types
id,name

division_assets
division_id,asset_id

user_assets
user_id,asset_id

```

but i do not know where to put the data that varies

Answer: 
When I've been faced with this in the past, the "best" answer always ends up varying depending on how much processing I want to do in the database, vs how much in the client code. 

For what it's worth, often the approach that has worked best for me in the past has been to end up with one table per optional attribute (in particular, not one table per entity type). So, in your examples above

```
assets (as per your example)
asset_types (as per you example)
division_assets (as per your example)
user_assets (as per your example)
colours
  asset_id, colour
weights
  asset_id, weight
serial_numbers
  asset_id, serial_number

```

Of course, depending on the trade-offs you need to make, this might be a bad choice for you. Personally, I like to keep the schema for data as explicit as possible, including data types and constraints, so I have no drama in changing the the tables next time a new attribute comes along.
You can create two new tables:

1) Defining multiple asset attributes in the following table (as many as the asset may have)

asset\_id

asset\_attribute

asset\_value

2) asset\_attribute table

attribute\_id

asset\_attribute

The logic would be that asset\_attributes will need to be first defined in the asset\_attribute table and then it can be used (linked/tagged) with any asset (as a foreign key, from a drop down list on UI) and a proper value entered.

Hope this helps.