database - How to efficiently track sales of Collectible Items with varying parameters in SQL Server 2014 -

how efficiently track sales of collectible items varying parameters in sql server?

table definiton (mysql example, actual db sql server 2014):

create table `articles` (   `idarticle` int(11 not null,   `idproduct` int(11 default null,   `iduser` int(11) default null,   `idlanguage` int(11) not null,   `comments` longtext,   `price` double not null,   `count` int(11) not null,   `condition` longtext,   `isfoil` tinyint(1) not null,   `issigned` tinyint(1) not null,   `isaltered` tinyint(1) not null,   `isplayset` tinyint(1) not null,   `isfirsted` tinyint(1) not null,   primary key (`idarticle`) ); 

user/product table defintions should not matter.

an article offer user sell product given parameters, each user can offer multiple articles each differing parameters.

articles may change during lifetime, via user intervention or when sold.

there 100.000 products, each in cases several hundred articles offered resulting in few million rows current state.

the current database @ 2 gigabytes.

i sent current state different database every few hours via api, i'm merging them database via stored procedure takes 10 minutes.

the same stored procedure checks whether , item has been sold comparing count column.

should article no longer exists counted sale.

this approach creates few false positives, of sorted plausibility checks , otherwise don't skew data enough matter.

maintaining current state not issue.

i worry future, due every article being varied , changing in parameters have track entire article object every sale made.

as can imagine blows database crazy amounts, 1 sale per article doubles size of entire database.

my question if there approach reduce bloat of database, thought using following 2 already.

1. create article description table can refactor of parameters table , sales rows reference description.

   unfortunately multiplexes articles single object several ones, makes merging new data lot harder since instead of "knowing" foreign keys import i'd have find correct description object first. if try alleviate making key computable key takes same amount of space description rendering whole exercise moot.

2. since want record sales statistical / historic reasons purge old data periodically after calculating them new table containing few key indicators. preferred choice.

hopefully on here knows better approach :)