Click here to Skip to main content
15,880,796 members
Please Sign up or sign in to vote.
1.00/5 (1 vote)
See more:
I might be asking this question wrong, please let me know if there's a better way of formulating this question.

background:
I am making .net application to handle the product information for a company selling promotional "stuff". They require many variants a single product, multiple prices based on customer, price history, and much much more. I see some advantages with XML for this, but I have no experience with "complex" data-storage like this. Essentially there are 5'000 base products, some have 30 size-variants, then there are multiple colour variants for each size, variants that are for regular customers (printed logos etc.), then there are minimum 5 prices, and then these needs to have a price history.

I made something that was messy and buggy, by using loads of tables in a SQL-database, but a 50 product test, with a limited number of variants, resulted in 34 tables created, (had it making tables as needed).

Am I going at this problem the wrong way, thinking that a single database could hold so much data?

Simplified data-structure
XML
<products>
	<product name="Nice Shirt" prodno="12345">
		<prices>
			<retailprice val="299">
				<history>
					<price val="99" date="2014.09.01" /> 
				</history>
			</retailprice>
		</prices>
		<variants>
			<colours>
				<colour val="red" />
			</colours>
			<sizes>
				<size val="XL" pricemod="0" />
			</sizes>
		</variants>
	</product>
</products>

This is just a simplified data-structure, written in XML, to demonstrate my thinking

Bottom line
How is the better way of storing data like this? I don't expect some finished product, but I'm in dire need of a nudge, to get moving on this project.

thanks!

Frank
Posted
Comments
PIEBALDconsult 15-Oct-14 10:09am    
"(had it making tables as needed)" That's certainly not a good idea.
Frank R. Haugen 16-Oct-14 4:35am    
You don't say
Mycroft Holmes 16-Oct-14 3:46am    
Probably better in the database forum but the pedants will get you for cross posting now. This is after all inviting discussion whereas most of us ignore a question with 1 or more answer.
Frank R. Haugen 16-Oct-14 4:36am    
Point! But now, if I "double post", I'll catch hell for that
Mycroft Holmes 16-Oct-14 4:46am    
I would do it anyway, I think they generally just bitch at you, not down vote a valid question. There are a number of other guys who will input valuable opinions.

Generally use json instead of xml, since it is more concise, easier to parse and work with : fastJSON[^]

If you are storing "blob" representations, then look at Document Database engines instead of storing in relational tables of SQL Server etc. :
RaptorDB - the Document Store[^]
 
Share this answer
 
Comments
PIEBALDconsult 15-Oct-14 10:07am    
I thought JSON was for transmitting, not storing.
Mehdi Gholam 15-Oct-14 10:10am    
Anything you can transmit you can store :)
PIEBALDconsult 15-Oct-14 10:24am    
That's generally true, but there may be some exceptions. Just checking.
Mehdi Gholam 15-Oct-14 10:32am    
RaptorDB, MongoDB, CouchDB etc. are all storing data as json or binary json, currently fastJSON can serialize any poco object even with circular references to json.
Frank R. Haugen 16-Oct-14 6:53am    
How about Sedna DB?? I am intrigued by it being a XML-database, and XML is, if nothing else, elegant
So this is not a document database requirement, it requires a straight relational database structure.

If you are creating tables on the fly you are making a fundamental error in your design. I can believe you may need 34 or more tables but they must be structured correctly and once created it is unlikely the table count will change except to add STRUCTURE.

If you are struggling to define a data structure, and it is a complex on, then get in a professional, sit with him and understand why he is putting together the data structure. This should allow you to extend the structure as development progresses.
 
Share this answer
 
Comments
Frank R. Haugen 16-Oct-14 4:29am    
I'll probably have to get a specialist on this. I have problems visualizing at multidimensional data, which is why I really like XML as a data-visualization tool, my programmers "mindset" just gets it.
Mycroft Holmes 16-Oct-14 4:49am    
I wrote this application in the early 90's using Excel as the database, I was selling the dammed rubbish at the time, it is the one I cut my database teeth on when I moved it to SuperBase. Bloody complex and it needs to be correct otherwise it will drive you nuts.
barneyman 16-Oct-14 18:01pm    
agree w/ mycroft - it's a fairly 'routine' multi-dim problem - table of products with a guid key, table of customers with a guid key, _customer_product table with customer, product and guid key - your _customer_product.id now is the pin around which all your different sku details can revolve ... and for the love of cheese, use guids :)
Mycroft Holmes 16-Oct-14 18:43pm    
By the great Ghu do NOT use guids unless you have a specific need for a distributed system. Use ints or bigints as identity columns. Try remembering a guid when debugging!

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)



CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900