Hello perspolis,
No. Database size is not normally a factor in design. With tables like
Purchase and Sale, I strongly doubt that you will ever have the size of
table that would drive you away to denormalize your design in this way. In
a data warehouse I worked on, we had a single table that contained 20
Billion rows. SQL Server 2000 didn't even flinch. (some operations took a
while
Do not make your decision on the basis of expected size. If the business
has different Meanings for these two tables, and considers them to be
entirely different and unrelated things, then you are better off in
different tables because the business may decide to add fields to one that
are not in the other, or create a complex indexing scheme for only one of
the two tables.
On the other hand, if the business expects to move an item through "stages"
where it is a purchase until an event occurs, and then it is a sale, then
use one table. Otherwise, you will have a much more difficult time
answering basic questions like "has customer X been involved in the purchase
or sale of item Y" and "provide the total of all purchases and sales for
category Z"
I do not know your system. The word "purchase" says "accounts payable"
while the word "sale" says "accounts receivable" to me. If that's what
these mean to you too (or the inventory equivalents), then you definitely
want two different tables. The reason being this: when you purchase
something, you purchase it from someone. When you sell something, you sell
it to someone. These "someone" entities need to have some form of
uniqueness to them. Otherwise, your reporting becomes very difficult to do.
--- Nick
--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik
Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.
--
