Where Do I Want To Go Today? - From the Field

  • Comments posted to this topic are about the content posted at http://www.sqlservercentral.com/columnists/sjones/wheredoiwanttogotodayfromthefield.asp

  • Not sure I like the trigger idea either. Though you have to weigh the overhead of cursoring through the rows in the logical tables vs just firing the trigger once per row - how much different could it be? I can see where it would save writing a lot of repetitive code. I'd support it if it was an option and not a change in behavior (which would break too much code anyway), kind of a "with perrow" attribute.



  • Here is a relatively minor improvement. Change the concatenation operator from a plus sign to "||" like it is in Oracle, and no longer have to cast or convert numeric data types to some kind of character type before including in a concatenation, again as in Oracle. Keep the plus operator as an arithmetic operator only.

  • I like changing the concatenation operator. Never liked plus being the same as "and this".

    Steve Jones




  • I like the idea of changing the concatenation operator as well. DB400 (DB2 on as/400) uses the || as well.

    For triggers, lets keep them set based.  If you do need to cycle thru the individual records, and there are a times, write the trigger to handle them.  Loops thru the records, use case statements, etc.  And I am pretty sure cursors work in a trigger as well.

    It's my understanding that cursors were never a part of true relational database design.  It was later added to accompdate the ISAM world (indexed sequential access method)

    The stats pack is a real nice idea.  SQL Server's self tuning is such a plus, but it seems to be so little known, or even understood, that Oracle makes such a big deal that you need a full time DBA to manage Oracle.  If designed well, a statspack could also be a driver that tells DBA's when it's time to add hardware, or even reconfigure hardware ( RAID 10 instead of RAID 5 - yes, I have clients that still use RAID 5 for databases).



    What's the business problem you're trying to solve?

  • What about SNAPSHOT upon every schema change!


    This is the most annoying in my case. A minor schema change requires to apply SNAPSHOT which is a kill for databases of size in GBs and when the subscribers are at different cities or countries. If a link fails b/w the publisher and subscriber during the SNAPSHOT; the agent starts from beginning.

    Well; sp_repladdcolumn, sp_repldropcolumn do exist but don't help much. If we need to change a column length or key; dropping the column(for very large table) and adding a new one fills up the tran-log and each record needs to be replicated for that column......


    Allowing comprehensive schema change within the replication setup would help a lot; especially for those, running websites with no downtime tolerance.


    A DBA works only when the users can't, so i scarcely work!

Viewing 6 posts - 1 through 5 (of 5 total)

You must be logged in to reply to this topic. Login to reply