August 29, 2003 at 12:00 am
Comments posted to this topic are about the content posted at http://www.sqlservercentral.com/columnists/sjones/wheredoiwanttogotodayfromthefield.asp
September 2, 2003 at 3:53 am
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.
Andy
September 2, 2003 at 8:42 am
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.
September 2, 2003 at 11:07 am
I like changing the concatenation operator. Never liked plus being the same as "and this".
Steve Jones
September 2, 2004 at 10:16 am
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?
September 3, 2004 at 9:12 am
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