Running SQL Server as a DOMAIN user account.It is a single, two-edged sword. If SQL Server authenticates to the domain, it can have access to the resources of the domain. That is both a blessing and a curse.
It means that (given the proper permissions), the SQL Server can "see" other resources such as disk, printers, etc. The server can then send mail and other forms of messages (that rely on domain authentication).
In general, I usually have one "intereface" server that uses a domain account, but has no end user connections. It does all of the "cross server" work for the whole farm. The other servers use Local System unless some particular reason forces another choice.
-PatP|||Search for MS Best Practices on SQL Server and SQL Agent service accounts.|||with a domain user account the sqlserver and sql server agent accounts can access the local machine and can be audited through the os.
the mssqlserver service can communicate more efficiently with other servers that are domain members.
you can use sqlmail directly(no workarounds) because you will have an exchange mailbox created for your mssqlserver user account.
you can make the accounts [domain users] but give them admin rights on the local sql server machine to control access and use.
you can avoid having to create a cmdexec proxy account for running activex scripts ..
the accounts allow you the ability to perform active directory delegeation and impersonation.
the domain accounts provide for mutal authentication services through kerberos in active directory.sql
Showing posts with label disadvantages. Show all posts
Showing posts with label disadvantages. Show all posts
Tuesday, March 20, 2012
Advantages/Disadvantages to using more than one database
I have a content site where everything is currently in one SQL Server
DB. As I add features to the site, for example message boards and
blogging, does it make sense to put those features in a separate
database? What would I lose and gain in doing so? Thanks so much.
It's difficult to say without knowing more about the business as such.
But assuming that you have common concepts like users, and you may want
to have links between different entities, a single database makes life
simpler. Cross-databases references are messy.
>
It's difficult to say without knowing more about the business as such.
But assuming that you have common concepts like users, and you may want
to have links between different entities, a single database makes life
simpler. Cross-databases references are messy.
>
But if the message board and the blogs are entirely unrelated, separate
databases may be a better idea.
>
One advantage of separate databases, is that if the message-board database
crashes, the blog database may still be available.
Thanks Erland...what if the message board and blog were to sit in
subdomains - is that a stronger argument for using a different
database? My concern is that if the traffic builds, I wouldn't want
activity in one area to slow down other areas of the site; but I don't
want to sacrifice simplicity either. From the sound of it, there's no
hard and fast rule about this...I'm just trying to plan in the event I
get the traffic going. Easier to fix now than later. :)
Subdomains? You mean like blogs.lautier.com, messageboard.lautier.com etc?
I can't see that that has anything to do with it.
DB. As I add features to the site, for example message boards and
blogging, does it make sense to put those features in a separate
database? What would I lose and gain in doing so? Thanks so much.
ErikErik Lautier (lautier@.gmail.com) writes:
Quote:
Originally Posted by
I have a content site where everything is currently in one SQL Server
DB. As I add features to the site, for example message boards and
blogging, does it make sense to put those features in a separate
database? What would I lose and gain in doing so? Thanks so much.
It's difficult to say without knowing more about the business as such.
But assuming that you have common concepts like users, and you may want
to have links between different entities, a single database makes life
simpler. Cross-databases references are messy.
But if the message board and the blogs are entirely unrelated, separate
databases may be a better idea.
One advantage of separate databases, is that if the message-board database
crashes, the blog database may still be available.
--
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se
Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/pr...oads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodin...ions/books.mspx|||Erland Sommarskog wrote:
Quote:
Originally Posted by
Erik Lautier (lautier@.gmail.com) writes:
Quote:
Originally Posted by
I have a content site where everything is currently in one SQL Server
DB. As I add features to the site, for example message boards and
blogging, does it make sense to put those features in a separate
database? What would I lose and gain in doing so? Thanks so much.
>
It's difficult to say without knowing more about the business as such.
But assuming that you have common concepts like users, and you may want
to have links between different entities, a single database makes life
simpler. Cross-databases references are messy.
>
But if the message board and the blogs are entirely unrelated, separate
databases may be a better idea.
>
One advantage of separate databases, is that if the message-board database
crashes, the blog database may still be available.
Thanks Erland...what if the message board and blog were to sit in
subdomains - is that a stronger argument for using a different
database? My concern is that if the traffic builds, I wouldn't want
activity in one area to slow down other areas of the site; but I don't
want to sacrifice simplicity either. From the sound of it, there's no
hard and fast rule about this...I'm just trying to plan in the event I
get the traffic going. Easier to fix now than later. :)
Erik
Quote:
Originally Posted by
--
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se
>
Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/pr...oads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodin...ions/books.mspx
Quote:
Originally Posted by
Thanks Erland...what if the message board and blog were to sit in
subdomains - is that a stronger argument for using a different
database? My concern is that if the traffic builds, I wouldn't want
activity in one area to slow down other areas of the site; but I don't
want to sacrifice simplicity either. From the sound of it, there's no
hard and fast rule about this...I'm just trying to plan in the event I
get the traffic going. Easier to fix now than later. :)
Subdomains? You mean like blogs.lautier.com, messageboard.lautier.com etc?
I can't see that that has anything to do with it.
If you are nervous that the bloggers would slow down the message board,
then the same or the different database does not matter, as long as they
are on the same server. And that would be an argument for different
databases: if you go for different databases from the start, it will be
simple to move the databases between servers.
But then the databases would be entirely independent. Things like storing
users and their profiles should probably be in a separate database, and
the middle tier would be responsible to pass that information to the
databases.
--
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se
Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/pr...oads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodin...ions/books.mspx
Advantages/Disadvantages of TEXT Column type in SQL 2005
Hello,
I know this question has been asked before, but I'd like to get the
opinions from others before I continue with my database. I am creating
a Database to track calls for a Tech Support dept. There are some
tables like tb_Call, tb_Ticket where I need to allow a user to enter a
long description if necessary. I am thinking of using the Text Field
type with a leght of 16. My question is what are the
advantages/di
vantages with this as opposed to using any other data
type. Any insight or recommendations you can provide will be greatly
appreciated!
Thanks in advance!The TEXT datatype is deprecated in SQL Server 2005. So do not use it for
any new work. Instead, use VARCHAR(MAX) -- that datatype has the same
maximum storage capacity as TEXT, and is a lot more flexible in terms of
being able to use string functions.
Adam Machanic
Pro SQL Server 2005, available now
http://www.apress.com/book/bookDisplay.html?bID=457
--
"Ed_p" <edp@.nomail.com> wrote in message
news:utvCvDY6FHA.1248@.TK2MSFTNGP14.phx.gbl...
> Hello,
> I know this question has been asked before, but I'd like to get the
> opinions from others before I continue with my database. I am creating a
> Database to track calls for a Tech Support dept. There are some tables
> like tb_Call, tb_Ticket where I need to allow a user to enter a long
> description if necessary. I am thinking of using the Text Field type with
> a leght of 16. My question is what are the advantages/divantages with
> this as opposed to using any other data type. Any insight or
> recommendations you can provide will be greatly appreciated!
> Thanks in advance!|||
Adam Machanic wrote:
>The TEXT datatype is deprecated in SQL Server 2005. So do not use it for
>any new work. Instead, use VARCHAR(MAX) -- that datatype has the same
>maximum storage capacity as TEXT, and is a lot more flexible in terms of
>being able to use string functions.
>
>
It's worth noting that while for [text] the default is
to store data out-of-row, for the (max) types, the
default is to store data in-row. In some cases, this
can make a difference, and it may be useful to set the
table option so that the (max) type behaves like [text]
did:
exec sp_tableoption N'MyTable', 'large value types out of row', 'ON'
Steve Kass
Drew University|||In addition to the other posts, if you have several such columns, where each
will fit inside the
regular varchar or nvarchar limit: In 2005, you have page overflow, meaning
you can have for
instance two varchar(5000) each containing 5000 characters.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
Blog: http://solidqualitylearning.com/blogs/tibor/
"Ed_p" <edp@.nomail.com> wrote in message news:utvCvDY6FHA.1248@.TK2MSFTNGP14.phx.gbl...[colo
r=darkred]
> Hello,
> I know this question has been asked before, but I'd like to get the opinio
ns from others before I
> continue with my database. I am creating a Database to track calls for a
Tech Support dept.
> There are some tables like tb_Call, tb_Ticket where I need to allow a user
to enter a long
> description if necessary. I am thinking of using the Text Field type with
a leght of 16. My
> question is what are the advantages/divantages with this as opposed to
using any other data
> type. Any insight or recommendations you can provide will be greatly appr
eciated!
> Thanks in advance![/color]
I know this question has been asked before, but I'd like to get the
opinions from others before I continue with my database. I am creating
a Database to track calls for a Tech Support dept. There are some
tables like tb_Call, tb_Ticket where I need to allow a user to enter a
long description if necessary. I am thinking of using the Text Field
type with a leght of 16. My question is what are the
advantages/di
vantages with this as opposed to using any other datatype. Any insight or recommendations you can provide will be greatly
appreciated!
Thanks in advance!The TEXT datatype is deprecated in SQL Server 2005. So do not use it for
any new work. Instead, use VARCHAR(MAX) -- that datatype has the same
maximum storage capacity as TEXT, and is a lot more flexible in terms of
being able to use string functions.
Adam Machanic
Pro SQL Server 2005, available now
http://www.apress.com/book/bookDisplay.html?bID=457
--
"Ed_p" <edp@.nomail.com> wrote in message
news:utvCvDY6FHA.1248@.TK2MSFTNGP14.phx.gbl...
> Hello,
> I know this question has been asked before, but I'd like to get the
> opinions from others before I continue with my database. I am creating a
> Database to track calls for a Tech Support dept. There are some tables
> like tb_Call, tb_Ticket where I need to allow a user to enter a long
> description if necessary. I am thinking of using the Text Field type with
> a leght of 16. My question is what are the advantages/di
vantages with> this as opposed to using any other data type. Any insight or
> recommendations you can provide will be greatly appreciated!
> Thanks in advance!|||
Adam Machanic wrote:
>The TEXT datatype is deprecated in SQL Server 2005. So do not use it for
>any new work. Instead, use VARCHAR(MAX) -- that datatype has the same
>maximum storage capacity as TEXT, and is a lot more flexible in terms of
>being able to use string functions.
>
>
It's worth noting that while for [text] the default is
to store data out-of-row, for the (max) types, the
default is to store data in-row. In some cases, this
can make a difference, and it may be useful to set the
table option so that the (max) type behaves like [text]
did:
exec sp_tableoption N'MyTable', 'large value types out of row', 'ON'
Steve Kass
Drew University|||In addition to the other posts, if you have several such columns, where each
will fit inside the
regular varchar or nvarchar limit: In 2005, you have page overflow, meaning
you can have for
instance two varchar(5000) each containing 5000 characters.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
Blog: http://solidqualitylearning.com/blogs/tibor/
"Ed_p" <edp@.nomail.com> wrote in message news:utvCvDY6FHA.1248@.TK2MSFTNGP14.phx.gbl...[colo
r=darkred]
> Hello,
> I know this question has been asked before, but I'd like to get the opinio
ns from others before I
> continue with my database. I am creating a Database to track calls for a
Tech Support dept.
> There are some tables like tb_Call, tb_Ticket where I need to allow a user
to enter a long
> description if necessary. I am thinking of using the Text Field type with
a leght of 16. My
> question is what are the advantages/di
vantages with this as opposed to using any other data
> type. Any insight or recommendations you can provide will be greatly appr
eciated!
> Thanks in advance![/color]
Advantages/Disadvantages of SQL 2005 Reporting Vs Crystal Report 1
Hi:
Can someone show me a link where I can get the Advantages/Disadvantages of
SQL 2005 Reporting Vs Crystal Report 10 ?
Thanks in advance.
--
Thanks,
SDRoyTry this:
http://www.crystalreportsbook.com/SSRSandCR_ExecSummary.asp
"SDRoy" wrote:
> Hi:
> Can someone show me a link where I can get the Advantages/Disadvantages of
> SQL 2005 Reporting Vs Crystal Report 10 ?
> Thanks in advance.
> --
> Thanks,
> SDRoy|||I just perused it and two things. One is that it was written prior to SQL
Server 2005 coming out. And, two, the licensing is incomplete. Apples to
Apples I have never heard that Crystal Reports is cheaper. The licensing
costs mentioned are per CPU for SQL Server which you might or might not have
to do. From what I have seen when we looked at Crystal Reports licensing
there is no way that you will get away with the $7,500 license fee that the
author compares to the Enterprise per processor license for SQL Server.
Bruce Loehle-Conger
MVP SQL Server Reporting Services
"John G." <John G.@.discussions.microsoft.com> wrote in message
news:9AF11023-0A1E-4CE8-87DC-81B7F583A2D0@.microsoft.com...
> Try this:
> http://www.crystalreportsbook.com/SSRSandCR_ExecSummary.asp
> "SDRoy" wrote:
>> Hi:
>> Can someone show me a link where I can get the Advantages/Disadvantages
>> of
>> SQL 2005 Reporting Vs Crystal Report 10 ?
>> Thanks in advance.
>> --
>> Thanks,
>> SDRoy
Can someone show me a link where I can get the Advantages/Disadvantages of
SQL 2005 Reporting Vs Crystal Report 10 ?
Thanks in advance.
--
Thanks,
SDRoyTry this:
http://www.crystalreportsbook.com/SSRSandCR_ExecSummary.asp
"SDRoy" wrote:
> Hi:
> Can someone show me a link where I can get the Advantages/Disadvantages of
> SQL 2005 Reporting Vs Crystal Report 10 ?
> Thanks in advance.
> --
> Thanks,
> SDRoy|||I just perused it and two things. One is that it was written prior to SQL
Server 2005 coming out. And, two, the licensing is incomplete. Apples to
Apples I have never heard that Crystal Reports is cheaper. The licensing
costs mentioned are per CPU for SQL Server which you might or might not have
to do. From what I have seen when we looked at Crystal Reports licensing
there is no way that you will get away with the $7,500 license fee that the
author compares to the Enterprise per processor license for SQL Server.
Bruce Loehle-Conger
MVP SQL Server Reporting Services
"John G." <John G.@.discussions.microsoft.com> wrote in message
news:9AF11023-0A1E-4CE8-87DC-81B7F583A2D0@.microsoft.com...
> Try this:
> http://www.crystalreportsbook.com/SSRSandCR_ExecSummary.asp
> "SDRoy" wrote:
>> Hi:
>> Can someone show me a link where I can get the Advantages/Disadvantages
>> of
>> SQL 2005 Reporting Vs Crystal Report 10 ?
>> Thanks in advance.
>> --
>> Thanks,
>> SDRoy
Advantages of Database Diagram
What is the advantages/disadvantages of using Database Diagram and link all the tables in MS SQL Server Management Studio versus letting the application check and link the different tables at run time? Currently, I do not have all my tables linked in a Database Diagram. I do everything at run time in my application code behind. What are the best practices? Which is easier or perhaps more secure?
I always used the diagram tool in SQL2000 - not only is it a great resource for new DBA's and developers, it adds constraints that you might otherwise forget. It's a great simple way to ensure you don't end up with missing links in your data.
|||Many thanks for the response. Is constraint the biggest advantage of using diagram? By the way, can I use MS SQL Server Management Studio 2005 to diagram a database tables on SQL Server 2000?
|||Lack of referential integrity can lead to very hard to trace faults. Where relationships exist, it is far better to define then at the database level as the relationship is then always enforced.
You can have more than one diagram. It is not necessary to have diagrams to define foreign key relationships, it is just a bit easier that way.
|||
Thanks for the responses.
sqlAdvantages and disadvantages of stored proc encryption?
Security is good for me as for developer. But what are advantages and
divantages of stored proc encryption?
May be encrypted sp's are executing slow?Though encryption is good from security point of view, SQL Server 2000
stored procs can be easily decrypted. In terms of performance there's no
difference, as the execution plan will be the same. But if you do encrypt,
make sure you have the source readily available.
--
HTH,
Vyas, MVP (SQL Server)
SQL Server Articles and Code Samples @. http://vyaskn.tripod.com/
"Oleg Cherkasenko" <oleg@.opel.com.ua> wrote in message
news:eO8n$ixnFHA.3312@.tk2msftngp13.phx.gbl...
Security is good for me as for developer. But what are advantages and
divantages of stored proc encryption?
May be encrypted sp's are executing slow?|||...also, troubleshooting in the production environment becomes a bit more d
ifficult. Like execute
the proc, compare the source (which you don't have) to the execution plan.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
Blog: http://solidqualitylearning.com/blogs/tibor/
"Narayana Vyas Kondreddi" <answer_me@.hotmail.com> wrote in message
news:udzTFmxnFHA.3540@.TK2MSFTNGP10.phx.gbl...
> Though encryption is good from security point of view, SQL Server 2000
> stored procs can be easily decrypted. In terms of performance there's no
> difference, as the execution plan will be the same. But if you do encrypt,
> make sure you have the source readily available.
> --
> HTH,
> Vyas, MVP (SQL Server)
> SQL Server Articles and Code Samples @. http://vyaskn.tripod.com/
>
> "Oleg Cherkasenko" <oleg@.opel.com.ua> wrote in message
> news:eO8n$ixnFHA.3312@.tk2msftngp13.phx.gbl...
> Security is good for me as for developer. But what are advantages and
> divantages of stored proc encryption?
> May be encrypted sp's are executing slow?
>
>|||Oleg,
better is upload the code and its revisions to VSS
"Narayana Vyas Kondreddi" wrote:
> Though encryption is good from security point of view, SQL Server 2000
> stored procs can be easily decrypted. In terms of performance there's no
> difference, as the execution plan will be the same. But if you do encrypt,
> make sure you have the source readily available.
> --
> HTH,
> Vyas, MVP (SQL Server)
> SQL Server Articles and Code Samples @. http://vyaskn.tripod.com/
>
> "Oleg Cherkasenko" <oleg@.opel.com.ua> wrote in message
> news:eO8n$ixnFHA.3312@.tk2msftngp13.phx.gbl...
> Security is good for me as for developer. But what are advantages and
> divantages of stored proc encryption?
> May be encrypted sp's are executing slow?
>
>|||Thank you All.
By the way,
what about encryption in sql2005 editions?
"Oleg Cherkasenko" <oleg@.opel.com.ua> wrote in message
news:eO8n$ixnFHA.3312@.tk2msftngp13.phx.gbl...
> Security is good for me as for developer. But what are advantages and
> divantages of stored proc encryption?
> May be encrypted sp's are executing slow?
>|||The encryption is trivial to break with freely available tools.
Encrypted code has very little to do with real security. It's pretty
much a cosmetic feature that *may* limit low-level meddling by
incompetent users but won't protect you against smart hackers.
David Portas
SQL Server MVP
--
di
vantages of stored proc encryption?May be encrypted sp's are executing slow?Though encryption is good from security point of view, SQL Server 2000
stored procs can be easily decrypted. In terms of performance there's no
difference, as the execution plan will be the same. But if you do encrypt,
make sure you have the source readily available.
--
HTH,
Vyas, MVP (SQL Server)
SQL Server Articles and Code Samples @. http://vyaskn.tripod.com/
"Oleg Cherkasenko" <oleg@.opel.com.ua> wrote in message
news:eO8n$ixnFHA.3312@.tk2msftngp13.phx.gbl...
Security is good for me as for developer. But what are advantages and
di
vantages of stored proc encryption?May be encrypted sp's are executing slow?|||...also, troubleshooting in the production environment becomes a bit more d
ifficult. Like execute
the proc, compare the source (which you don't have) to the execution plan.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
Blog: http://solidqualitylearning.com/blogs/tibor/
"Narayana Vyas Kondreddi" <answer_me@.hotmail.com> wrote in message
news:udzTFmxnFHA.3540@.TK2MSFTNGP10.phx.gbl...
> Though encryption is good from security point of view, SQL Server 2000
> stored procs can be easily decrypted. In terms of performance there's no
> difference, as the execution plan will be the same. But if you do encrypt,
> make sure you have the source readily available.
> --
> HTH,
> Vyas, MVP (SQL Server)
> SQL Server Articles and Code Samples @. http://vyaskn.tripod.com/
>
> "Oleg Cherkasenko" <oleg@.opel.com.ua> wrote in message
> news:eO8n$ixnFHA.3312@.tk2msftngp13.phx.gbl...
> Security is good for me as for developer. But what are advantages and
> di
vantages of stored proc encryption?> May be encrypted sp's are executing slow?
>
>|||Oleg,
better is upload the code and its revisions to VSS
"Narayana Vyas Kondreddi" wrote:
> Though encryption is good from security point of view, SQL Server 2000
> stored procs can be easily decrypted. In terms of performance there's no
> difference, as the execution plan will be the same. But if you do encrypt,
> make sure you have the source readily available.
> --
> HTH,
> Vyas, MVP (SQL Server)
> SQL Server Articles and Code Samples @. http://vyaskn.tripod.com/
>
> "Oleg Cherkasenko" <oleg@.opel.com.ua> wrote in message
> news:eO8n$ixnFHA.3312@.tk2msftngp13.phx.gbl...
> Security is good for me as for developer. But what are advantages and
> di
vantages of stored proc encryption?> May be encrypted sp's are executing slow?
>
>|||Thank you All.
By the way,
what about encryption in sql2005 editions?
"Oleg Cherkasenko" <oleg@.opel.com.ua> wrote in message
news:eO8n$ixnFHA.3312@.tk2msftngp13.phx.gbl...
> Security is good for me as for developer. But what are advantages and
> di
vantages of stored proc encryption?> May be encrypted sp's are executing slow?
>|||The encryption is trivial to break with freely available tools.
Encrypted code has very little to do with real security. It's pretty
much a cosmetic feature that *may* limit low-level meddling by
incompetent users but won't protect you against smart hackers.
David Portas
SQL Server MVP
--
Monday, March 19, 2012
Advantages and disadvantages
Code: ( text )
[list]what is the advantages and disadvantages of Ms SQL server and java servletts front-end on the clien end.[list]what is the advantages and disadvantages of Ms Access on the server, connected via JDBC and java on the client end.what is the advantages and disadvantages of HTML on the client end,coupled with SQL server and ODBL on the server end.
My first experience with JDBC (several years ago) left much to be desired. It was simply a Java layer on top of ODBC and was God Awful slow and many ODBC features were not implimented or had some sort of custom implimentation. Simple things like execute calls could not be done in a standard query statement, they had to use a separate exec entry point.
Lately though my experience is MUCH better. The current implimentation I use does not use the ODBC layer and instead goes directly to the SQL dll -- MUCH, MUCH, MUCH faster and as far as I can tell, fully implimented without custom entry points. Oh, by the way, did I tell you it's MUCH faster!
My experience is with CFMX and the JDBC that comes with it. I can round up the version information if you need it but if you are using CFMX, then as long as you are on the latest and greatest, I don't see any disadvantages.
Subscribe to:
Posts (Atom)