any pros/ cons to having multiple Publications

sql2k sp3
Im going to start Replicating 40 or so tables. Is there
any good/ bad to each table going into its own Publication?
TIA, ChrisR
ideally you will want to group your publications into logical units for
administrative, functional, and performance reasons.
To make life simpler for yourself you should have a single publication. This
eases the administrative burden. However sometimes you will want to
replicate different tables on different schedules, ie some transactions are
required to be replicated real time, others must only be replicated once per
day.
You will get better performance if you group your articles that have dri
relationships into the same publications, and then create multiple
publications and use the independent_agent option on each publication. This
will create multiple distribution agents replicating to the same subscriber
db.
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
"ChrisR" <anonymous@.discussions.microsoft.com> wrote in message
news:01ef01c496a0$ed8c86c0$a401280a@.phx.gbl...
> sql2k sp3
> Im going to start Replicating 40 or so tables. Is there
> any good/ bad to each table going into its own Publication?
> TIA, ChrisR
|||> You will get better performance if you group your articles that have dri
> relationships into the same publications, and then create multiple
> publications and use the independent_agent option on each publication.
This
> will create multiple distribution agents replicating to the same
subscriber
> db.
Im going to be replicating to a denormalized db for reporting purposes only.
(Thanks to you ;-) ) Therefore, Im not going to include the dri as it will
be enforced on the Publisher. That being the case, theres really no logical
grouping I can use. What about just putting the really big tables into
they're own Publications and using the independent_agent option you
mentioned?
"Hilary Cotter" <hilary.cotter@.gmail.com> wrote in message
news:OvJMuQtlEHA.896@.TK2MSFTNGP12.phx.gbl...
> ideally you will want to group your publications into logical units for
> administrative, functional, and performance reasons.
> To make life simpler for yourself you should have a single publication.
This
> eases the administrative burden. However sometimes you will want to
> replicate different tables on different schedules, ie some transactions
are
> required to be replicated real time, others must only be replicated once
per
> day.
> You will get better performance if you group your articles that have dri
> relationships into the same publications, and then create multiple
> publications and use the independent_agent option on each publication.
This
> will create multiple distribution agents replicating to the same
subscriber
> db.
> --
> Hilary Cotter
> Looking for a SQL Server replication book?
> http://www.nwsu.com/0974973602.html
>
> "ChrisR" <anonymous@.discussions.microsoft.com> wrote in message
> news:01ef01c496a0$ed8c86c0$a401280a@.phx.gbl...
>
|||separate them according to activity. I.e. if you have 10 really volatile
tables you are publisher 20 ones that are modified a couple of time an hour,
and 50 tables which are fairly static you could do 5 or 10 separate
publications, each with one or two of the volatile tables, 4 to 2 of the
less volatile tables, and 1 to 2 of the static tables.
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
"ChrisR" <chris@.noemail.com> wrote in message
news:uj$UMhulEHA.2020@.TK2MSFTNGP09.phx.gbl...
> This
> subscriber
> Im going to be replicating to a denormalized db for reporting purposes
only.
> (Thanks to you ;-) ) Therefore, Im not going to include the dri as it
will
> be enforced on the Publisher. That being the case, theres really no
logical
> grouping I can use. What about just putting the really big tables into
> they're own Publications and using the independent_agent option you
> mentioned?
>
> "Hilary Cotter" <hilary.cotter@.gmail.com> wrote in message
> news:OvJMuQtlEHA.896@.TK2MSFTNGP12.phx.gbl...
> This
> are
> per
> This
> subscriber
>

any advantage using an xml string as parameter

Hi,
I just wanna know the pros and cons while using XML string as argument to the procedure. Which one will be better in terms of security and performance.
regards
Aneesh R.
That depends on what you want to do with the parameter. Could you please be a bit more specific?
Best regards
Michael
"Aneesh" <aneesh.r@.eostek.com> wrote in message news:%23TD84aoiEHA.1356@.TK2MSFTNGP09.phx.gbl...
Hi,
I just wanna know the pros and cons while using XML string as argument to the procedure. Which one will be better in terms of security and performance.
regards
Aneesh R.
|||Hi,
Actually the application is E-Com. Is it better to use XML parameters for Password verification, UserRegistration etc. I need to consider both Performance and security
regards
Aneesh R.
That depends on what you want to do with the parameter. Could you please be a bit more specific?
Best regards
Michael
"Aneesh" <aneesh.r@.eostek.com> wrote in message news:%23TD84aoiEHA.1356@.TK2MSFTNGP09.phx.gbl...
Hi,
I just wanna know the pros and cons while using XML string as argument to the procedure. Which one will be better in terms of security and performance.
regards
Aneesh R.
|||Some items are dependent on your perf and scaling requirements:
- Are you planning on using OpenXML to unshred it? You may find that large XML documents may be problematic from a scaling point of view (>100kB). Small ones should be fine.
- Are you planning on using a T-SQL statement instead to parse a CSV format? That may be less efficient, but performance tests should be done.
Some items are general security items:
- Do you expose the stored proc parameter to arbitrary users? In that case there are some DoS scenarios that you may need to prepare for by checking for them on the mid-tier. If you have full control over the XML format that you send, then there is no more or less security than on any other data value that you send.
HTH
Michael
"Aneesh" <aneesh.r@.eostek.com> wrote in message news:O0iDzmyiEHA.3564@.TK2MSFTNGP10.phx.gbl...
Hi,
Actually the application is E-Com. Is it better to use XML parameters for Password verification, UserRegistration etc. I need to consider both Performance and security
regards
Aneesh R.
That depends on what you want to do with the parameter. Could you please be a bit more specific?
Best regards
Michael
"Aneesh" <aneesh.r@.eostek.com> wrote in message news:%23TD84aoiEHA.1356@.TK2MSFTNGP09.phx.gbl...
Hi,
I just wanna know the pros and cons while using XML string as argument to the procedure. Which one will be better in terms of security and performance.
regards
Aneesh R.