Page 1 of 1

sql creating tables and fields

Posted: Tue Jul 13, 2004 3:33 pm
by fresh
hey,

im needing to make some new fields, which are also known as rows right??

well, I need to add two fields to my table:

1. completed
2. Points

now my question is, what value and what type of attributes ect, do I use to store numbers, is it int and if so, what number would I use and why???

any great tutorial on SQL would be awesome, however, a quick confirmation will be just as good, thank you in advance ;)

Posted: Tue Jul 13, 2004 3:38 pm
by feyd
Fields are columns. Rows are entries in the table data. Anyway, INT is probably the better choice, or BIGINT.. INT(10) UNSIGNED is what I'd go for.. I think..

Posted: Tue Jul 13, 2004 3:42 pm
by patrikG

i thought so

Posted: Tue Jul 13, 2004 3:44 pm
by fresh
so fields are the name of the column and rows are the data within the column like:

my_table <-- table

user--|--date--|--points <-- fields
jack--|--7704--|--100 <-- rows

is that right???

so int is what I should use, and why the number 10, why not 1000 or 75 or something???

thanks feyd


edit: hey thanks alot for the link, just what I've been looking for :)

Posted: Tue Jul 13, 2004 3:46 pm
by patrikG
int(10) means that that particular column can hold integer numbers with 10 digits.

ohhh

Posted: Tue Jul 13, 2004 3:48 pm
by fresh
just like an C++ array, setting the buffer to 10 is setting the limit of 10 chars at a time... that makes so much sense now... thank you buddy :)

P.s. is it best to always set that a little higher than need be???

Re: ohhh

Posted: Tue Jul 13, 2004 3:53 pm
by patrikG
fresh wrote:P.s. is it best to always set that a little higher than need be???
Generally: yes, but bear in mind that the bigger the database, the slower it becomes (you won't notice the difference for a long while, though, until your DB is very big and get lots of traffic). Keeping fields as large as necessary and as a small as possible is my rule of thumb.

ok

Posted: Tue Jul 13, 2004 4:02 pm
by fresh
well, what if over time I make another DB will that speed things up??

Posted: Tue Jul 13, 2004 4:06 pm
by patrikG
If designed properly, sure. But my experience with DBs is that you simply want to design them once properly and then forget about them as much as possible. There is nothing as tedious and nerve-wracking as data-migration.
So: a well designed database is priceless - it saves time and hassle. Have a look at McGruff's Starter Pack.

awww

Posted: Tue Jul 13, 2004 9:20 pm
by fresh
sounds nice, a self updating, low maintence DB... do they really exist??? :wink:

hey thank you for the links , I appreciate it buddy ;)