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

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.

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

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 ideaif 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."

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.

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)

Prosecutor James Blackburn, in closing argument in the "Fatal Vision" murders trial: "If in the future, you should cry a tear, cry one for them [the murder victims]. If in the future, you should say a prayer, say one for them. And if in the future, you should light a candle, light one for them."