December 4, 2006 at 2:37 pm
SalesOrderID(PK) | FruitID | Date | Volume | Price |
Int int datetime int int
4 4 8 4 4
Allow null box
Empty Checked Checked Checked Checked
tblFruit
FruitID(PK) | FruitDescription |
Int varchar
Allow null is empy for both fields
can someone tell me what would be the correct answer ?
thanks
December 4, 2006 at 3:05 pm
Even an orable DBA could answer this one.
THREAD CLOSED!
December 4, 2006 at 4:48 pm
Just so anyone else is interested:
FYI - this poster had this to say in another thread:
im oracle dba and applied for sql dba job and been given sql db questions, to answer and post it back havent got time to go through books and stuff, just quick, simple answer will do.
never used sql db lol
-SQLBill
December 5, 2006 at 3:45 am
For crying out loud, can't you do your own homework?
December 5, 2006 at 10:17 am
I have one question for you. What can you do with the order that shouldn't be allowed for an order to be created. Should be easy enough to see but if you can't then you need to read about proper design methodologies.
December 5, 2006 at 10:20 am
Lol, there are so many problems with this design that I wouldn't know where to start... but that's another question for another day !
December 5, 2006 at 4:23 pm
When designing a set of tables that would be related by usage then a permanent relation should be defined between them (Grasshopper): create tblSales.FruitID as FK for tblFruit.FruitID(PK)
Then you have to keep in mind that it always works to have a clustered index defined on each table. Why: firstly you have a physical order defined for your records; if the pages become fragmented then the presence of at least a clustered index is mandatory for performing a defragmentation task (you cannot defragment a heap table without additional step). For eg, you can choose to have the defined PKs in both tables as clustered index (please keep in mind that not always the PK has to be a clustered index)
On the other hand, be careful with the lenght of a row. Why: SQL Server reads 64k at once (8 extents) If we take your example here then your row in tblSales is 52 in lenght, so SQL can read 1230 rows at once. But what if you don't need a datetime field type and instead you consider that a smalldatetime is enough. In this case SQL can read 1333 rows at once, 100 rows more, which can make quite a difference with your "select...where..." queries.
I hope this is useful as a start.
Good luck!
December 6, 2006 at 3:42 am
he he!
December 7, 2006 at 8:00 am
Points still to be talked about.
Why allow all those nulls.
Why iatr the quantity and price fields not declared as decimal.
Where is the unique constraint.
Viewing 9 posts - 1 through 8 (of 8 total)
You must be logged in to reply to this topic. Login to reply