Simple SQL Question...

Question

Simple SQL Question...

tooba111

Right there with Babe

Points: 767
More actions
December 5, 2012 at 5:24 pm

#285902

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.

Viewing 8 posts - 1 through 7 (of 7 total)

You must be logged in to reply to this topic. Login to reply

Evil Kraig F SSC Guru Points: 100851 More actions · Answer 1

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[/url] | Forum Netiquette
For index/tuning help, follow these directions.[/url] |Tally Tables[/url]
Twitter: @AnyWayDBA

Jeff Moden SSC Guru Points: 1004406 More actions · Answer 2

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:w00t:?

+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.

Change is inevitable... Change for the better is not.

Helpful Links:
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally)

Jeff Moden SSC Guru Points: 1004406 More actions · Answer 3

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.

Change is inevitable... Change for the better is not.

Helpful Links:
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally)

rocky_498 SSCertifiable Points: 6532 More actions · Answer 4

Hi Guys,

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

Appreciate all.

Have a nice weekend!

bev.kaufman SSC Enthusiast Points: 173 More actions · Answer 5

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.

ScottPletcher SSC Guru Points: 101120 More actions · Answer 6

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) "It's a dog-eat-dog world, and I'm wearing Milk-Bone underwear." "Norm", on "Cheers". Also from "Cheers", from "Carla": "You need to know 3 things about Tortelli men: Tortelli men draw women like flies; Tortelli men treat women like flies; Tortelli men's brains are in their flies".

sunshine-587009 SSCrazy Eights Points: 8981 More actions · Answer 7

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 ¤