How big should a table be

I'm absolutely a greenhorn in SQL server. I need to record all the data from
my company. The datas are 24 floating points being logged into a SQL table
every one hour. Datas will be presenting on a website which may have at the
most 10 simultaneously access at one time mainly for company staff.
My opnion is try to keep them in one table so that it's easier for me to
write code to do the search, to create the trend etc because I don't have to
reference to multiple table. But I'm concerning the size of the table.
What I am not sure is: Should I keep them all in one table or into different
table divided by year for example. Given 10 years lifespan of it, will on
table be too big? Anybody can give me some consultancy will be greatly
apprecitated.JL (ljmagzine@.hotmail.com) writes:
> I'm absolutely a greenhorn in SQL server. I need to record all the data
> from my company. The datas are 24 floating points being logged into a
> SQL table every one hour. Datas will be presenting on a website which
> may have at the most 10 simultaneously access at one time mainly for
> company staff.
> My opnion is try to keep them in one table so that it's easier for me to
> write code to do the search, to create the trend etc because I don't
> have to reference to multiple table. But I'm concerning the size of the
> table.
> What I am not sure is: Should I keep them all in one table or into
> different table divided by year for example. Given 10 years lifespan of
> it, will on table be too big? Anybody can give me some consultancy will
> be greatly apprecitated.
If I understand this right, each time you save 25 * 8 bytes of data.
(24 floats + the datetime as key). That's 200 bytes. You do this 24
times a day. There are 365 days a year. That is 1.75 megabytes of data.
That is not much for any commercial DB engine.
Had you had 1.75 gigabytes of data per year, maybe it would have been
worth considering different tables, and then use paritioned views to
access them as one table. But in your case, just go along with one
table.
Erland Sommarskog, SQL Server MVP, sommar@.algonet.se
Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techinfo/productdoc/2000/books.asp|||Thanks a lot!|||"JL" <ljmagzine@.hotmail.com> wrote in message
news:uJyFpMx0DHA.2324@.TK2MSFTNGP09.phx.gbl...
> I'm absolutely a greenhorn in SQL server. I need to record all the data
from
> my company. The datas are 24 floating points being logged into a SQL table
> every one hour. Datas will be presenting on a website which may have at
the
> most 10 simultaneously access at one time mainly for company staff.
> My opnion is try to keep them in one table so that it's easier for me to
> write code to do the search, to create the trend etc because I don't have
to
> reference to multiple table. But I'm concerning the size of the table.
> What I am not sure is: Should I keep them all in one table or into
different
> table divided by year for example. Given 10 years lifespan of it, will on
> table be too big? Anybody can give me some consultancy will be greatly
> apprecitated.
Sounds like your needs are quite small ... you might even look at Access to
hold this information as I think SQL Server would be a bit of overkill.
Also, you might want to get a copy of a book that explains relational
databases so that you can better understand how to group your information
into
appropriate tables. [1]
Irrespective of size, it's better to have a good database design that
requires you to learn new code, then a poor design that will be impossible
to maintain in the future but means you don't need to learn new code.
[1] Something like :
http://www.amazon.co.uk/exec/obidos/ASIN/0764539884/qid=1073329045/sr=1-3/ref=sr_1_2_3/202-1193909-5035865
or
http://www.amazon.co.uk/exec/obidos/ASIN/0764507753/qid=1073329104/sr=1-2/ref=sr_1_3_2/202-1193909-5035865