November 23, 2007 at 5:26 am
Hello I have a huge database and i need to know how i can list the tables within a database, so to know what and what tables are existing.
November 23, 2007 at 5:30 am
SELECT * FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_TYPE = 'BASE TABLE'
SELECT * FROM sysobjects WHERE type = 'U'
--Ramesh
November 23, 2007 at 10:01 pm
To add to that... sp_help.
--Jeff Moden
Change is inevitable... Change for the better is not.
November 26, 2007 at 2:42 am
Try to avoid select * at any point of time.
Do write your sqlcode like
------------------
Select id,
name,
type,
crdate
From sysobjects
Where type = 'U'
-------------------
instead of
---------------
Select *
From sysobjects
Where type = 'U'
----------------
You can include whatever you wish to view in the output, just for example, i took id,name,type,crdate in the select list.
It is a good practice to specify the table columns explicitly.
karthik
November 28, 2007 at 2:10 am
Jeff,By mistakenly i took your word 'Running Total'.
Reason 1:
SELECT * queries are also bad from an application maintenance point of view. If a column is added to a table, the results returned to your application will change in structure. Well programmed applications should be referring to columns by name and shouldn't be affected, but well programmed applications should also minimize the ways in which they are vulnerable to external changes.
Reaon 2:
To reduce the size of worktables select only needed columns from the tables. Avoid using select * unless you need all columns of the tables. This reduces the load on tempdb and the cost of sorting the result tables.
Am i correct ? If i am wrong kindly let me know or if you add some more reasons then it would be truly appreciated.
karthik
November 28, 2007 at 8:06 am
That's better, Karthik...
I would also add a couple of things to that...
Reason 3:
SELECT * will normally cause a table scan (even if it looks like an index scan on the execution plan) which defeats most, if not all, performance benefits of indexing.
Reason 4:
Think of the "pipe". Returning more data to the client than is necessary causes extra and unneeded network traffic.
Whenever someone explains to someone that SELECT * isn't a "best practice", they should also either explain why or provide a URL that explains why. That causes learning on the part of the person you are "talking" with. It helps prevent SQL "clones" that know some of the rules but not the reason for the rules. I, and many others, call it the "Five Monkey's Syndrome"... see the following URLs for that...
http://doh-san.blogspot.com/2005/10/five-monkeys.html
http://www.mwls.co.uk/anecdotes/5monkeys.htm
Even the U.S. Navy seems to embrace the lesson taught by the story of the Five Monkeys...
http://www.safetycenter.navy.mil/Articles/a-m/monkeys.htm
Which, of course, leads to...
http://www.urbandictionary.com/define.php?term=five+monkeys
The myth has it, that such an experiment actually took place, although I don't have the details on that...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 28, 2007 at 3:39 am
Jeff Moden (11/23/2007)
To add to that... sp_help.
Some more methods
1 EXEC sp_tables
2 In QA, dont point any content and press Alt+F1
Failing to plan is Planning to fail
Viewing 7 posts - 1 through 6 (of 6 total)
You must be logged in to reply to this topic. Login to reply