Database Statistics

I am trying to find an efficient way to get the number of times that each ro
w
in a table is selected. I want to avoid using triggers.
Any ideas?
Thanks
John
jpd0861@.msn.comIf you're using stored procedures to access data, then I'd simply suggest
extending those to implement table-use auditing. Of course you'd need to kee
p
statistics in a separate table - something like:
PK_column : AccesedTime (default getdate()) : AccessedBy (default system_use
r)
If your db design allows direct access to tables, then maybe your auditing
requirement is just another point in favour of using procedures.
ML|||From the good news/bad news category:
Good news. We don't have SELECT triggers, so you wont have any problem
Bad news, there really isn't any other way to do this unless you are using
stored procedures, and even then it would be a big drag on performance.
Or I am missing something?
----
Louis Davidson - http://spaces.msn.com/members/drsql/
SQL Server MVP
"John" <John@.discussions.microsoft.com> wrote in message
news:77D095BA-04A6-4EB7-83EB-57B28AA21C51@.microsoft.com...
>I am trying to find an efficient way to get the number of times that each
>row
> in a table is selected. I want to avoid using triggers.
> Any ideas?
> Thanks
> John
> jpd0861@.msn.com|||Thank you Louis, I was not clear in my original message. I know that there
are no SELECT triggers in SQL Server...just good old INSERT, UPDATE, and
DELETE.
FYI, I did get an answer about using table-use auditing from ML that seems
to make sense.
"Louis Davidson" wrote:

> From the good news/bad news category:
> Good news. We don't have SELECT triggers, so you wont have any problem
> Bad news, there really isn't any other way to do this unless you are using
> stored procedures, and even then it would be a big drag on performance.
> Or I am missing something?
> --
> ----
--
> Louis Davidson - http://spaces.msn.com/members/drsql/
> SQL Server MVP
>
> "John" <John@.discussions.microsoft.com> wrote in message
> news:77D095BA-04A6-4EB7-83EB-57B28AA21C51@.microsoft.com...
>
>|||I agree, I just wanted to be clear that without procs this would not be
possible. I rarely expect that people are actually using stored procedures,
but clearly this is yet another reason why they are so excellent.
----
Louis Davidson - http://spaces.msn.com/members/drsql/
SQL Server MVP
"John" <John@.discussions.microsoft.com> wrote in message
news:6D10890D-C733-4673-852F-81C747F2EF10@.microsoft.com...
> Thank you Louis, I was not clear in my original message. I know that there
> are no SELECT triggers in SQL Server...just good old INSERT, UPDATE, and
> DELETE.
> FYI, I did get an answer about using table-use auditing from ML that seems
> to make sense.
> "Louis Davidson" wrote:
>

database size comparisons

hI
I have to database with more than 500 tables. Is there any way to find
number of rows in each tables from system tables. I want this result to
compare another database in different server.
Going table by table is practically time consuming process.
Can any one help me
Thanks
KalyanTry this:
select object_name(id) as TableName, rows
from sysindexes
where indid in (0, 1)
Adam Machanic
SQL Server MVP
http://www.sqljunkies.com/weblog/amachanic
--
"Kalyan" <Kalyan@.discussions.microsoft.com> wrote in message
news:01CB0D73-2553-4531-B7B5-ACAD5C186466@.microsoft.com...
> hI
> I have to database with more than 500 tables. Is there any way to find
> number of rows in each tables from system tables. I want this result to
> compare another database in different server.
> Going table by table is practically time consuming process.
> Can any one help me
> Thanks
> Kalyan|||To add to Adam's response, the row column in sysindexes can be used as an
estimated row count but won't necessarily be accurate. You can use DBCC
UPDATEUSAGE beforehand to get a more accurate row count. The only way to
get a reliable accurate count is with SELECT COUNT(*).
--
Hope this helps.
Dan Guzman
SQL Server MVP
"Kalyan" <Kalyan@.discussions.microsoft.com> wrote in message
news:01CB0D73-2553-4531-B7B5-ACAD5C186466@.microsoft.com...
> hI
> I have to database with more than 500 tables. Is there any way to find
> number of rows in each tables from system tables. I want this result to
> compare another database in different server.
> Going table by table is practically time consuming process.
> Can any one help me
> Thanks
> Kalyan|||This is a multi-part message in MIME format.
--=_NextPart_000_0096_01C4DCAE.8E68F580
Content-Type: text/plain;
charset="Utf-8"
Content-Transfer-Encoding: quoted-printable
Try this:
exec sp_msforeachtable "sp_spaceused '?' "
Tunji O
"Kalyan" <Kalyan@.discussions.microsoft.com> wrote in message =news:01CB0D73-2553-4531-B7B5-ACAD5C186466@.microsoft.com...
hI
I have to database with more than 500 tables. Is there any way to find =
number of rows in each tables from system tables. I want this result =to compare another database in different server.
Going table by table is practically time consuming process.
Can any one help me
Thanks
Kalyan
--=_NextPart_000_0096_01C4DCAE.8E68F580
Content-Type: text/html;
charset="Utf-8"
Content-Transfer-Encoding: quoted-printable
=EF=BB=BF<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
&

---

Try this:
exec sp_msforeachtable "sp_spaceused ='?' "
Tunji O
"Kalyan" wrote in message news:01C=B0D73-2553-4531-B7B5-ACAD5C186466@.microsoft.com...hII have to database with more than 500 tables. Is there any way to find number of rows in each tables from system tables. I want this =result to compare another database in different server.Going table =by table is practically time consuming process.Can any one help meThanksKalyan

---

--=_NextPart_000_0096_01C4DCAE.8E68F580--

Database Question

Is there a minimum number of operating system files you need when creating a database in 2005?

What do you mean by operating system files ?

Jens K. Suessmeyer.

http://www.sqlserver2005.de|||If by OS files, you mean, what is the minimun number of files required for a SQL Server database, the answer is two; a datafile and a transaction log file.|||If you are talking about installation then it requires some system files which may be found in .net framework. otherwise your question seems unclear. Please specify what you r trying to do actually.

Database query performance

I have a database table. The table has number of fields. Out of those fields one is Company and
another is DateTime. The table has thousands of records. I want to get the most recent
record for each company. In order to do that I am using the following query

SELECT * from CompanyDetail AS X
WHERE [DateTime]=(SELECT max([DateTime]) FROM CompanyDetail WHERE Company=X.Company)
ORDER BY Company

Note: There is only one record exists for the given company on a given date

The problem is that this query is very slow. Am I doing something wrong or there could be another
alternative way to improve it ?

Thanks in advance
KDV

Your best bet is to ask this question in the Transact-SQL forum:
http://forums.microsoft.com/msdn/ShowForum.aspx?ForumID=85

David Sceppa
Microsoft

Database partition

What is best criteria to partition table?
Table size or number of records?
How many partition we can do?
If I have 20 GB size of table how many tables of how much size should i
create?
Regards
Amish ShahThe best criterion is to partition when you need to provide a solution to a
PROBLEM and the best solution is PARTITIONING.
So the question is.... do you have a PROBLEM that needs solving?
What is your PROBLEM?
Is PARTITIONING the best SOLUTION for your PROBLEM?
--
Nik Marshall-Blank MCSD/MCDBA
Linz, Austria
"amish" <shahamishm@.gmail.com> wrote in message
news:1129544966.925091.296410@.g43g2000cwa.googlegroups.com...
> What is best criteria to partition table?
> Table size or number of records?
> How many partition we can do?
> If I have 20 GB size of table how many tables of how much size should i
> create?
>
> Regards
> Amish Shah
>|||Suppose I have table of 20GB how much partition should i create? What
should be size of each partition?
Or
If I have table of 2.5 billion rows how much partition should be
created? How much rows should be in each partition?
Regards|||Amish,
I think what Nik was pointing out is that you are asking for a solution
without describing a problem. Size alone is not enough criteria to determine
proper partitioning. How can your data be segregated? The answer to
partitioning is not <x> rows = partition. The view your build will need to
determine which table(s) from the partition to query. If you do not
partition on a meaningful field, then you will hurt your performance rather
than improve it.
Provide more specifics and I am sure someone here can help you out. Since
you mention the number of rows, I will assume you are looking for horizontal
partitioning, so in the meantime read up on horizontal partitioning in BOL.
John
"amish" wrote:
> Suppose I have table of 20GB how much partition should i create? What
> should be size of each partition?
> Or
> If I have table of 2.5 billion rows how much partition should be
> created? How much rows should be in each partition?
> Regards
>|||Hi John.
Correct. Solutions are for problems. You've not described yours at all. Will
you really have 20 billion rows? If so how big are they, 1 single ID column
and an integer would still mean you may not need partitioning as all the
data could fit onto a normal (or several) medium sized disks.
Paritioning is not the only solution for large or high use databases. You
could split the data into 2 tables each with the same key. One table has a
few columns but is very frequently accessed. In this case the packing
density of rows will be high and a lot of data accesses willl get pages from
buffers alreay in memory. The other table could contain infrequently used
data.
I've seen many people come unstuck because they've embraced something which
sounds "high-tech" or "is the current buzzword", developed their solution
and it doesn't provide what they wanted because they didn't define the
problem properly in the first place.
Please explain your current problem and what you're trying to achieve (with
and without partitioning) and we'll all be able to better help you arrive at
the best solution.
--
Nik Marshall-Blank MCSD/MCDBA
Linz, Austria
"John Scragg" <JohnScragg@.discussions.microsoft.com> wrote in message
news:AA57FE51-EFEA-4D74-8499-4F58535D92EA@.microsoft.com...
> Amish,
> I think what Nik was pointing out is that you are asking for a solution
> without describing a problem. Size alone is not enough criteria to
> determine
> proper partitioning. How can your data be segregated? The answer to
> partitioning is not <x> rows = partition. The view your build will need
> to
> determine which table(s) from the partition to query. If you do not
> partition on a meaningful field, then you will hurt your performance
> rather
> than improve it.
> Provide more specifics and I am sure someone here can help you out. Since
> you mention the number of rows, I will assume you are looking for
> horizontal
> partitioning, so in the meantime read up on horizontal partitioning in
> BOL.
> John
> "amish" wrote:
>> Suppose I have table of 20GB how much partition should i create? What
>> should be size of each partition?
>> Or
>> If I have table of 2.5 billion rows how much partition should be
>> created? How much rows should be in each partition?
>> Regards
>>|||Hi
Thanks for the reply
Actually I have joined a new company.
Here we have some tables of 20 gb to 50 gb in size.
So I just want to know should I partition this tables?
I think if I will partition it, reindex and other management activity
will be easier for me.
I want to partition this tables so I just want to find on which
criteria and how many partition should I create for this tables.
Regards|||Amish,
Again, the answer is not based on size. When you partition you are NOT
doing it to reduce the administrative workload. in fact, you probably
increase it. You are doing it for performance reasons. And the data has to
be partitioned based on criteria.
So for example your company has 5 sales regions and they are comprised of 10
states each. you could partition the data into 5 tables, each representing
the sales data for a specific refion. This might make sense since in most
cases the queries are going to be for a specific region. You see what we
mean when we say there has to be some logical criteria for the parition.
You cannot just say. 2billion / 10 = 200 million rows per table. All you
have done with this partition is forced the creation of a view that will
ALWAYS have to join ALL the tables. No benefit there at all. And how do you
decide which table to insert into? It needs to be based on some business
logic, not just pulled out of thin air. Stop looking at the size of the
tables and start looking at the logic for partitioning.
John Scragg
"amish" wrote:
> Hi
> Thanks for the reply
> Actually I have joined a new company.
> Here we have some tables of 20 gb to 50 gb in size.
> So I just want to know should I partition this tables?
> I think if I will partition it, reindex and other management activity
> will be easier for me.
> I want to partition this tables so I just want to find on which
> criteria and how many partition should I create for this tables.
> Regards
>

Database partition

What is best criteria to partition table?
Table size or number of records?
How many partition we can do?
If I have 20 GB size of table how many tables of how much size should i
create?
Regards
Amish Shah
The best criterion is to partition when you need to provide a solution to a
PROBLEM and the best solution is PARTITIONING.
So the question is.... do you have a PROBLEM that needs solving?
What is your PROBLEM?
Is PARTITIONING the best SOLUTION for your PROBLEM?
Nik Marshall-Blank MCSD/MCDBA
Linz, Austria
"amish" <shahamishm@.gmail.com> wrote in message
news:1129544966.925091.296410@.g43g2000cwa.googlegr oups.com...
> What is best criteria to partition table?
> Table size or number of records?
> How many partition we can do?
> If I have 20 GB size of table how many tables of how much size should i
> create?
>
> Regards
> Amish Shah
>
|||Suppose I have table of 20GB how much partition should i create? What
should be size of each partition?
Or
If I have table of 2.5 billion rows how much partition should be
created? How much rows should be in each partition?
Regards
|||Amish,
I think what Nik was pointing out is that you are asking for a solution
without describing a problem. Size alone is not enough criteria to determine
proper partitioning. How can your data be segregated? The answer to
partitioning is not <x> rows = partition. The view your build will need to
determine which table(s) from the partition to query. If you do not
partition on a meaningful field, then you will hurt your performance rather
than improve it.
Provide more specifics and I am sure someone here can help you out. Since
you mention the number of rows, I will assume you are looking for horizontal
partitioning, so in the meantime read up on horizontal partitioning in BOL.
John
"amish" wrote:

> Suppose I have table of 20GB how much partition should i create? What
> should be size of each partition?
> Or
> If I have table of 2.5 billion rows how much partition should be
> created? How much rows should be in each partition?
> Regards
>
|||Hi John.
Correct. Solutions are for problems. You've not described yours at all. Will
you really have 20 billion rows? If so how big are they, 1 single ID column
and an integer would still mean you may not need partitioning as all the
data could fit onto a normal (or several) medium sized disks.
Paritioning is not the only solution for large or high use databases. You
could split the data into 2 tables each with the same key. One table has a
few columns but is very frequently accessed. In this case the packing
density of rows will be high and a lot of data accesses willl get pages from
buffers alreay in memory. The other table could contain infrequently used
data.
I've seen many people come unstuck because they've embraced something which
sounds "high-tech" or "is the current buzzword", developed their solution
and it doesn't provide what they wanted because they didn't define the
problem properly in the first place.
Please explain your current problem and what you're trying to achieve (with
and without partitioning) and we'll all be able to better help you arrive at
the best solution.
Nik Marshall-Blank MCSD/MCDBA
Linz, Austria
"John Scragg" <JohnScragg@.discussions.microsoft.com> wrote in message
news:AA57FE51-EFEA-4D74-8499-4F58535D92EA@.microsoft.com...[vbcol=seagreen]
> Amish,
> I think what Nik was pointing out is that you are asking for a solution
> without describing a problem. Size alone is not enough criteria to
> determine
> proper partitioning. How can your data be segregated? The answer to
> partitioning is not <x> rows = partition. The view your build will need
> to
> determine which table(s) from the partition to query. If you do not
> partition on a meaningful field, then you will hurt your performance
> rather
> than improve it.
> Provide more specifics and I am sure someone here can help you out. Since
> you mention the number of rows, I will assume you are looking for
> horizontal
> partitioning, so in the meantime read up on horizontal partitioning in
> BOL.
> John
> "amish" wrote:
|||Hi
Thanks for the reply
Actually I have joined a new company.
Here we have some tables of 20 gb to 50 gb in size.
So I just want to know should I partition this tables?
I think if I will partition it, reindex and other management activity
will be easier for me.
I want to partition this tables so I just want to find on which
criteria and how many partition should I create for this tables.
Regards
|||Amish,
Again, the answer is not based on size. When you partition you are NOT
doing it to reduce the administrative workload. in fact, you probably
increase it. You are doing it for performance reasons. And the data has to
be partitioned based on criteria.
So for example your company has 5 sales regions and they are comprised of 10
states each. you could partition the data into 5 tables, each representing
the sales data for a specific refion. This might make sense since in most
cases the queries are going to be for a specific region. You see what we
mean when we say there has to be some logical criteria for the parition.
You cannot just say. 2billion / 10 = 200 million rows per table. All you
have done with this partition is forced the creation of a view that will
ALWAYS have to join ALL the tables. No benefit there at all. And how do you
decide which table to insert into? It needs to be based on some business
logic, not just pulled out of thin air. Stop looking at the size of the
tables and start looking at the logic for partitioning.
John Scragg
"amish" wrote:

> Hi
> Thanks for the reply
> Actually I have joined a new company.
> Here we have some tables of 20 gb to 50 gb in size.
> So I just want to know should I partition this tables?
> I think if I will partition it, reindex and other management activity
> will be easier for me.
> I want to partition this tables so I just want to find on which
> criteria and how many partition should I create for this tables.
> Regards
>

Database partition

What is best criteria to partition table?
Table size or number of records?
How many partition we can do?
If I have 20 GB size of table how many tables of how much size should i
create?
Regards
Amish ShahThe best criterion is to partition when you need to provide a solution to a
PROBLEM and the best solution is PARTITIONING.
So the question is.... do you have a PROBLEM that needs solving?
What is your PROBLEM?
Is PARTITIONING the best SOLUTION for your PROBLEM?
Nik Marshall-Blank MCSD/MCDBA
Linz, Austria
"amish" <shahamishm@.gmail.com> wrote in message
news:1129544966.925091.296410@.g43g2000cwa.googlegroups.com...
> What is best criteria to partition table?
> Table size or number of records?
> How many partition we can do?
> If I have 20 GB size of table how many tables of how much size should i
> create?
>
> Regards
> Amish Shah
>|||Suppose I have table of 20GB how much partition should i create? What
should be size of each partition?
Or
If I have table of 2.5 billion rows how much partition should be
created? How much rows should be in each partition?
Regards|||Amish,
I think what Nik was pointing out is that you are asking for a solution
without describing a problem. Size alone is not enough criteria to determin
e
proper partitioning. How can your data be segregated? The answer to
partitioning is not <x> rows = partition. The view your build will need to
determine which table(s) from the partition to query. If you do not
partition on a meaningful field, then you will hurt your performance rather
than improve it.
Provide more specifics and I am sure someone here can help you out. Since
you mention the number of rows, I will assume you are looking for horizontal
partitioning, so in the meantime read up on horizontal partitioning in BOL.
John
"amish" wrote:

> Suppose I have table of 20GB how much partition should i create? What
> should be size of each partition?
> Or
> If I have table of 2.5 billion rows how much partition should be
> created? How much rows should be in each partition?
> Regards
>|||Hi John.
Correct. Solutions are for problems. You've not described yours at all. Will
you really have 20 billion rows? If so how big are they, 1 single ID column
and an integer would still mean you may not need partitioning as all the
data could fit onto a normal (or several) medium sized disks.
Paritioning is not the only solution for large or high use databases. You
could split the data into 2 tables each with the same key. One table has a
few columns but is very frequently accessed. In this case the packing
density of rows will be high and a lot of data accesses willl get pages from
buffers alreay in memory. The other table could contain infrequently used
data.
I've seen many people come unstuck because they've embraced something which
sounds "high-tech" or "is the current buzzword", developed their solution
and it doesn't provide what they wanted because they didn't define the
problem properly in the first place.
Please explain your current problem and what you're trying to achieve (with
and without partitioning) and we'll all be able to better help you arrive at
the best solution.
--
Nik Marshall-Blank MCSD/MCDBA
Linz, Austria
"John Scragg" <JohnScragg@.discussions.microsoft.com> wrote in message
news:AA57FE51-EFEA-4D74-8499-4F58535D92EA@.microsoft.com...[vbcol=seagreen]
> Amish,
> I think what Nik was pointing out is that you are asking for a solution
> without describing a problem. Size alone is not enough criteria to
> determine
> proper partitioning. How can your data be segregated? The answer to
> partitioning is not <x> rows = partition. The view your build will need
> to
> determine which table(s) from the partition to query. If you do not
> partition on a meaningful field, then you will hurt your performance
> rather
> than improve it.
> Provide more specifics and I am sure someone here can help you out. Since
> you mention the number of rows, I will assume you are looking for
> horizontal
> partitioning, so in the meantime read up on horizontal partitioning in
> BOL.
> John
> "amish" wrote:
>|||Hi
Thanks for the reply
Actually I have joined a new company.
Here we have some tables of 20 gb to 50 gb in size.
So I just want to know should I partition this tables?
I think if I will partition it, reindex and other management activity
will be easier for me.
I want to partition this tables so I just want to find on which
criteria and how many partition should I create for this tables.
Regards|||Amish,
Again, the answer is not based on size. When you partition you are NOT
doing it to reduce the administrative workload. in fact, you probably
increase it. You are doing it for performance reasons. And the data has to
be partitioned based on criteria.
So for example your company has 5 sales regions and they are comprised of 10
states each. you could partition the data into 5 tables, each representing
the sales data for a specific refion. This might make sense since in most
cases the queries are going to be for a specific region. You see what we
mean when we say there has to be some logical criteria for the parition.
You cannot just say. 2billion / 10 = 200 million rows per table. All you
have done with this partition is forced the creation of a view that will
ALWAYS have to join ALL the tables. No benefit there at all. And how do yo
u
decide which table to insert into? It needs to be based on some business
logic, not just pulled out of thin air. Stop looking at the size of the
tables and start looking at the logic for partitioning.
John Scragg
"amish" wrote:

> Hi
> Thanks for the reply
> Actually I have joined a new company.
> Here we have some tables of 20 gb to 50 gb in size.
> So I just want to know should I partition this tables?
> I think if I will partition it, reindex and other management activity
> will be easier for me.
> I want to partition this tables so I just want to find on which
> criteria and how many partition should I create for this tables.
> Regards
>

Database ownership best practice

Does it matter much who owns a database? I'm reviewing security on our
SQL installation and find a number of different owners: sa, Domain
administrators and some others. I want to tidy this up. Is it best to
make an NT administrator the owner of all databases, assign a special
user which does nothing else but own databases?
Having looked at Books Online and elsewhere, I don't see any advice as
broad based as what I'm seeking.
Any suggestions would be welcome.I think it's mostly an audit trail, to see who created the database.|||Hi
Our corporate standard is that all objects must be owned by SA. If it owned
by a domain user, or a SQL Server login, if that user leaves you have to
change the ownership of the object before you can remove the user from the
DB/system.
Regards
--
Mike Epprecht, Microsoft SQL Server MVP
Zurich, Switzerland
IM: mike@.epprecht.net
MVP Program: http://www.microsoft.com/mvp
Blog: http://www.msmvps.com/epprecht/
<stevester@.freeuk.com> wrote in message
news:1123238913.304851.90500@.g44g2000cwa.googlegroups.com...
> Does it matter much who owns a database? I'm reviewing security on our
> SQL installation and find a number of different owners: sa, Domain
> administrators and some others. I want to tidy this up. Is it best to
> make an NT administrator the owner of all databases, assign a special
> user which does nothing else but own databases?
> Having looked at Books Online and elsewhere, I don't see any advice as
> broad based as what I'm seeking.
> Any suggestions would be welcome.
>|||Like Mike Epprecht said, it's a good practice to use a standard SQL login as
the database owner since this will ensure the database owner account is
never orphaned. An orphaned database owner account can have side affects,
such as problems using sp_helpdb or using Enterprise Manager. If only
sysadmin role members can create database objects on your SQL Server, 'sa'
database ownership is probably ok. However, I'd like to add some additional
notes on the importance of the database owner.
The login associated with the database owner determines the mapping of the
database's 'dbo' user. 'dbo' has full permissions within the database so
the database owner login account needs to be appropriately secured.
Furthermore, when cross-database chaining is enabled (configurable option in
SQL 2000 SP3+ and always on in older SPs/versions), dbo-owned views, procs,
functions and triggers can access dbo-owned objects in other databases owned
by the same login even without user permissions on the referenced objects.
This is a major security concern with sa-owned databases because master is
also owned by 'sa' and is why one should enable cross-database chaining in
an sa-owned database when only sysadmin role members can create dbo-owned
objects. It is best to avoid turning on cross-database chaining unless
absolutely necessary.
If non-sysadmin role members can create dbo-owned database objects and you
must enable cross-database chaining, you should instead consider creating
and using a specialized SQL login for database ownership. See the Books
Online for more information on cross-database chaining.
Hope this helps.
Dan Guzman
SQL Server MVP
<stevester@.freeuk.com> wrote in message
news:1123238913.304851.90500@.g44g2000cwa.googlegroups.com...
> Does it matter much who owns a database? I'm reviewing security on our
> SQL installation and find a number of different owners: sa, Domain
> administrators and some others. I want to tidy this up. Is it best to
> make an NT administrator the owner of all databases, assign a special
> user which does nothing else but own databases?
> Having looked at Books Online and elsewhere, I don't see any advice as
> broad based as what I'm seeking.
> Any suggestions would be welcome.
>|||The owner info is of limited use from an audit perspective because the
database owner can be subsequently changed. See my response on security
considerations.
Hope this helps.
Dan Guzman
SQL Server MVP
<MICHAEL_SUNLIN@.COUNTRYWIDE.COM> wrote in message
news:1123249058.756243.222770@.z14g2000cwz.googlegroups.com...
>I think it's mostly an audit trail, to see who created the database.
>|||Thanks for the advice. I liked the idea of a dedicated db owner, to
keep things modular, but the orphaned user concern is a good point.
I'll review those areas mentioned and go with sa as long as the
associated points are not a problem.