Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase

Simple SQL Question... Expand / Collapse
Author
Message
Posted Wednesday, December 5, 2012 5:24 PM
SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: Friday, February 22, 2013 9:10 PM
Points: 25, Visits: 112
Hi Guys,

Simple question but don't know the answer, In my database i have 99 table that don't have any rows. My question is, it would be good idea
if i delete those table or leave it there. For Example, if i delete/remove these table, my users can see any application performance or not?
I know they are not using space, but just wondering....

Thank You.
Post #1393277
Posted Wednesday, December 5, 2012 5:36 PM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Monday, September 22, 2014 10:53 PM
Points: 5,383, Visits: 7,456
You'll get no performance increases from their removal, but you'll probably get readability and maintenance improvements from having less objects to keep track of.

EDIT: I should say no significant performance differences. 99 less tables to review during index rebuild reviews and the like will get you a few milliseconds or something back, just in case someone gets picky.



- Craig Farrell

Never stop learning, even if it hurts. Ego bruises are practically mandatory as you learn unless you've never risked enough to make a mistake.

For better assistance in answering your questions | Forum Netiquette
For index/tuning help, follow these directions. |Tally Tables

Twitter: @AnyWayDBA
Post #1393279
Posted Wednesday, December 5, 2012 8:08 PM


SSCommitted

SSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommitted

Group: General Forum Members
Last Login: Yesterday @ 8:24 PM
Points: 1,945, Visits: 3,017
In my database I have 99 table that don't have any rows. My question is, it would be good idea if I delete those tables or leave them there.


Better question: how did this happen in the first place?


Books in Celko Series for Morgan-Kaufmann Publishing
Analytics and OLAP in SQL
Data and Databases: Concepts in Practice
Data, Measurements and Standards in SQL
SQL for Smarties
SQL Programming Style
SQL Puzzles and Answers
Thinking in Sets
Trees and Hierarchies in SQL
Post #1393298
Posted Wednesday, December 5, 2012 8:30 PM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: General Forum Members
Last Login: Yesterday @ 11:28 PM
Points: 35,263, Visits: 31,750
CELKO (12/5/2012)
In my database I have 99 table that don't have any rows. My question is, it would be good idea if I delete those tables or leave them there.


Better question: how did this happen in the first place?


+1 on that! I've seen this happen with many 3rd party installations though. They sometimes install everything although the product level paid for may not use certain tables because certain options aren't available. Still, if you try to cleanup the mess they've left behind, it could break a maintenance contract, support contract, or some form of warranty. It would be like deleting unused job related tables from MSDB if you never ran any jobs.

More to your point (and I whole heartedly agree), these rowless tables are frequently development artifacts that have been forgotten. It's a part of the reason why I strongly suggest that no Developer be allowed any form of "write" access to production and that DBAs do code reviews and excercise change controls.


--Jeff Moden
"RBAR is pronounced "ree-bar" and is a "Modenism" for "Row-By-Agonizing-Row".

First step towards the paradigm shift of writing Set Based code:
Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column."

(play on words) "Just because you CAN do something in T-SQL, doesn't mean you SHOULDN'T." --22 Aug 2013

Helpful Links:
How to post code problems
How to post performance problems
Post #1393305
Posted Wednesday, December 5, 2012 8:45 PM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: General Forum Members
Last Login: Yesterday @ 11:28 PM
Points: 35,263, Visits: 31,750
tooba111 (12/5/2012)
Hi Guys,

Simple question but don't know the answer, In my database i have 99 table that don't have any rows. My question is, it would be good idea
if i delete those table or leave it there. For Example, if i delete/remove these table, my users can see any application performance or not?
I know they are not using space, but just wondering....

Thank You.


I don't care for rowless tables because they just clutter up the works especially when looking at tables through the Object Explorer of SSMS.

That notwithstanding, I wouldn't delete any of the tables unless I knew for sure who owned them. I'd never delete 3rd party product tables because, like I said above, it could void a maintenance contract, support contract, or maybe even break code because their GUI interface may still have objects for those tables and you just haven't used (or purchased) certain functionality, yet.

Even if the tables are from in-house applications, you could run into breaking code if you remove the tables.

Even when I think I've clearly identified that a rowless table is a true orphan, I'll script out the table (including all keys, fks, indexes, constraints, triggers, extended properties, privs, etc, etc), send out multiple emails asking if anyone knows what it's used for (along with a message of my intent to eventually delete it), store that scripts in a revision control product such as SubVersion or SourceSafe, rename the table, and let it sit for two or three months waiting for the phone to ring. 2 days prior to deletion, I send out 4 emails over those two days. Two "intent to delete" emailsat the beginning of each day with a list of the tables to be deleted, an "intent to delete" an hour before I delete them along with a final warning, and a "here's what I deleted" message after the fact.

I also tell people in that fourth email that if they want a deleted table to be restored after all of those warnings and the 3 month renaming period, that they should submit their request to reinstantiate each table on a separate $20 bill stapled to a paper bag with a #9 Jimmy John's sandwich, a Coke, and two Tylenol in the bag.

As a side bar, I suppose it is possible that you could see a bit of performance improvement in the app but only by removing or streamlining the objects that refer to such rowless tables. I don't believe that it would be worth it, though, except to have a cleaner and leaner app that might not require as much memory to operate.


--Jeff Moden
"RBAR is pronounced "ree-bar" and is a "Modenism" for "Row-By-Agonizing-Row".

First step towards the paradigm shift of writing Set Based code:
Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column."

(play on words) "Just because you CAN do something in T-SQL, doesn't mean you SHOULDN'T." --22 Aug 2013

Helpful Links:
How to post code problems
How to post performance problems
Post #1393307
Posted Wednesday, December 5, 2012 9:20 PM
SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Tuesday, September 23, 2014 1:40 PM
Points: 219, Visits: 838
Hi Guys,

Thank you so much to give me answer in detialll...

Appreciate all.

Have a nice weekend!
Post #1393311
Posted Friday, December 7, 2012 7:27 AM
SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: Thursday, June 12, 2014 2:25 PM
Points: 45, Visits: 45
I'd be cautious if you don't know how the tables got there in the first place. We have an accounting system that utilizes work tables, which are generally empty unless a particular application is running, loading it with data that can then be used in reports and processes. Maybe the programmers wrote code to recreate the tables if they accidentally get dropped, but that's not an assumption I'd care to risk.
Post #1394059
Posted Friday, December 7, 2012 11:38 AM
SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Yesterday @ 2:22 PM
Points: 2,121, Visits: 3,207
One or more them could also be exception/override tables. They may be empty in your case because currently you don't have any exceptions to normal processing rules/conditions. But existing code might still reference the tables to check for such exceptions.

Since they're virtually zero overhead, I wouldn't worry about them until you have everything else in the db fully tuned up.


SQL DBA,SQL Server MVP('07, '08, '09)

Carl Sagan said: "There is no such thing as a dumb question." Sagan obviously never watched a congressional hearing!
Post #1394182
Posted Friday, December 7, 2012 3:19 PM


Old Hand

Old HandOld HandOld HandOld HandOld HandOld HandOld HandOld Hand

Group: General Forum Members
Last Login: 2 days ago @ 11:06 AM
Points: 361, Visits: 1,176
I would replicate it in Development and/or backup in development if it already exists, then delete. If application has errors, restore. If not, migrate to production.

¤ §unshine ¤
Post #1394268
« Prev Topic | Next Topic »

Add to briefcase

Permissions Expand / Collapse