Date parsed: 04/10/2007 06:13:03
Date: Thu, 4 Oct 2007 10:13:03 -0400

10MBs? I think you can safely say that Express won't be an issue and you
will see no differences in performance between Express and Workgroup on a db
that size.

--
Andrew J. Kelly SQL MVP
Solid Quality Mentors


"John Austin" <John.Austin@nospam.nospam> wrote in message
news:72834DEC-E5FC-4787-A9AB-91CC3F0953B7@microsoft.com...
> For a small company with say 6 concurrent users, a database of say 10
> Mbytes
> and using only normal tables and indices (nothing fancy), will there be
> any
> significant performance differences between SQL Server Workgroup and SQL
> Server Express?
>
> Thanks,
> --
> John Austin

Date parsed: 09/10/2007 09:07:48
Date: Tue, 9 Oct 2007 13:07:48 -0400

That is virtually impossible to tell based on so little data. Each app does
things differently and the data and schemas are different. Size of the DB
means little as to how many users it can support if it is properly tuned. If
most access is via PK's it makes the process very efficient, especially if
the PK is clustered to avoid BookMark Lookups. The only way to know for sure
is to test it under your exact conditions but you are probably safe.

--
Andrew J. Kelly SQL MVP
Solid Quality Mentors


"John Austin" <John.Austin@nospam.nospam> wrote in message
news:B0F1C03C-0107-43A2-A5F4-9659DB45EF44@microsoft.com...
> Thanks, Charles.
>
> I have now been asked the same question about a simple 300 MB database
> with
> 10 to 15 users (virtually all access via primary keys). Do you know of any
> guidance regarding the number of users and database size and recommended
> SQL
> edition?
>
> Thanks
>
> --
> John Austin
>
>
> "Charles Wang[MSFT]" wrote:
>
>> Hi John,
>> I do not think that there will be any significant performance differences
>> between SQL Server Workgroup and SQL Server Express Edition for your
>> scenario. However if you encountered any performance issue, you may refer
>> to the following article:
>> Troubleshooting Performance Problems in SQL Server 2005
>> http://www.microsoft.com/technet/prodtechnol/sql/2005/tsprfprb.mspx
>>
>> If you have any other questions or concerns, pelase feel free to let us
>> know. Have a nice day!
>>
>> Best regards,
>> Charles Wang
>> Microsoft Online Community Support
>> =====================================================
>> When responding to posts, please "Reply to Group" via
>> your newsreader so that others may learn and benefit
>> from this issue.
>> ======================================================
>> This posting is provided "AS IS" with no warranties, and confers no
>> rights.
>> ======================================================
>>
>>
>>
>>
>>

Date parsed: 12/10/2007 06:36:14
Date: Fri, 12 Oct 2007 10:36:14 -0400

One of the best indicators of lack of memory for things like queries is the
Page Life Expectancy counter in Perfmon found under the SQL Server Buffer
Manger object. The higher the counter the better it is. This is the
estimated number of seconds a typical data page will stay in cache before
being swapped out. Values under 100 start to indicate poor memory
utilization. This is true regardless of edition. But if your db size is
only 300MB then if you have the recommended 1GB on the machine this should
not be an issue.

--
Andrew J. Kelly SQL MVP
Solid Quality Mentors


"John Austin" <John.Austin@nospam.nospam> wrote in message
news:561F12DF-DD1E-40EE-BA30-7BAA3E5F69D9@microsoft.com...
> Thanks, Charles,
>
> Express and Workgroup both have limits on processor count and memory
> usage.
> The limit on database size should not be a problem and is easily
> quantifiable. Presumably, if one is just reading data, CPU usage is not
> the
> limiting factor, however I suspect memory usage may be. Is there a way of
> tracking the memory usage of SQL Server standard in order to see if the
> Express memory limits will impact performance?
>
> Thanks,
> --
> John Austin
>
>
> "Charles Wang[MSFT]" wrote:
>
>> Hi Jason,
>> Thanks for your feedback.
>>
>> Actually database size and the number of users are not the factors for
>> database performance. Assume that a very large database with a great many
>> of historical data, but the real operations are based on several tables
>> which only contain very few records. In other words, there is a job
>> scheduled to remove the old records to history tables which are only for
>> report sometimes. In this case, if every T-SQL statement can finish
>> within
>> a very short time, it is possible that your SQL Server can handle
>> hundreds
>> of connections in parallel. Of course the CPU licensing of your server
>> need
>> to be able to support so many connections. I think that the real
>> performance here depends on your database design, server capability and
>> network bandwidth.
>>
>> Appreciate your understanding that it is hard to say that there is any
>> performance issue with only knowing your database size and the number of
>> users. It is a good practice that you perform a test environment to see
>> if
>> you encounter any performance issue before you put it into your
>> production
>> environment. If you encounter any performance issue during your test
>> process, please feel free to post back. We are very glad to assist you
>> further.
>>
>> Best regards,
>> Charles Wang
>> Microsoft Online Community Support
>> =====================================================
>> When responding to posts, please "Reply to Group" via
>> your newsreader so that others may learn and benefit
>> from this issue.
>> ======================================================
>> This posting is provided "AS IS" with no warranties, and confers no
>> rights.
>> ======================================================
>>
>>