It can sometimes be tempting to go down the [EAV route][1] (or even [diabolically tempting][2]), but [hic sunt leones][3]! This [delightful image][4] encapsulates the difficulties with such an approach - just like in primary school, you can't mix apples and oranges! Take a small amount of time to peruse the links to see where EAV **can** lead.

If I were you, I would do something like the following.

    CREATE TABLE vehicle
    (
      vehicle_id INTEGER PRIMARY KEY,
      vechicle_make VARCHAR (50), -- another table?
      vehicle_name VARCHAR (50),
      vehicle_estimated_value INTEGER,
      vehicle_reserve INTEGER
    );
    
    CREATE TABLE gold
    (
      lot_id INTEGER PRIMARY KEY, -- database generated
      dealer_id INTEGER, -- another table?
      lot_name VARCHAR (30), -- unique/ or unique with dealer
      gold_carat SMALLINT,
      gold_value INTEGER,
      gold_reserve INTEGER
    );
    
    CREATE TABLE portfolio
    (
      portfolio_id INTEGER, -- database generated  
      pf_asset_type INTEGER, -- FOREIGN KEY from asset_type table
      pf_asset_id, -- the PK of the gold/vehicle tables
                          -- combo of pf_asset_type and pf_asset_id UNIQUE
      pf_asset_value INTEGER,   --  If I were you, I'd be using a TRIGGER to feed values from the different asset tables 
      pf_asset_reserve INTEGER --  into these two monetary fields. Not sure of the exact capabilities of SQL Server,
                            --  maybe some sort of non-updateable calculated field? The advantage this has is that
                            --  you're not having a massive sum query for all your assets... Test and see what 
                            -- works for you.
    );

This schema should work on any server (tested on PostgreSQL), but obviously, you'll have to include Microsoft SQL Server specifics for auto-incrementing keys and syntax for the PK and FK constraints.

Other asset types can be readily added as required! 

  [1]: https://dba.stackexchange.com/search?q=user%3A34007%20EAV
  [2]: https://mikesmithers.wordpress.com/2013/12/22/the-anti-pattern-eavil-database-design/
  [3]: https://en.wikipedia.org/wiki/Here_be_dragons
  [4]: http://karwin.blogspot.ie/2009/05/eav-fail.html