| Author |
Topic |
|
Wingenious
Starting Member
11 Posts |
 Posted - 2003-08-13 : 01:39:30
|
| Would a typical SQL Server DBA or database developer ever be willing to buy a coherent and comprehensive package of advanced T-SQL routines?There seems to be quite a bit of excitement and discussion with regard to short/simple T-SQL scripts. SQL Server web sites solicit short/simple T-SQL scripts and publish them for all to download. The advantage of such scripts is that they are free. The disadvantage is that they are often very narrow in scope and they are written with very different styles (they are written by many different authors).There is no shortage of SQL Server tools that put a GUI on certain common tasks (such as database schema comparison). We are apparently buying those tools in sufficient quantities to support several companies. There are a number of other tasks that I, as a SQL Server DBA and database developer, do for which I do not have a GUI tool. Maybe GUI tools are not appropriate for the tasks, the tools do not exist, or the tools cost an exorbitant amount.There are commercial packages of source code in other software development contexts, but there does not seem to be any established market for T-SQL source code. Why not? Are SQL Server folks choosing to "roll their own" when it comes to T-SQL scripts? If so, then who are the people that eagerly request and download short/simple T-SQL scripts? Are SQL Server folks so short of funding that they can not afford to buy T-SQL tools? If so, then who are the people that buy tools costing about $3,000 per user (from Princeton Softech)?Brian |
|
|
robvolk
Most Valuable Yak
15732 Posts |
Posted - 2003-08-13 : 07:47:39
|
| No idea who they are, but if you work for a large enough company and the accounting department doesn't squawk, you can easily blow $3,000 on some tools (and maybe find out later they don't do what you want)Most people will roll their own not only because it's cheaper but also because it's a learning experience, one that money literally cannot buy. Or they'll grab a free script and play with it. Once the basic tools are completed the rest become much easier to create.That said, tools like SQL Compare, Log Explorer, some of the Lockwood Tech tools are really well done and useful and/or provide one-of-a-kind features that make the job much easier.As far as non-GUI scripts, these are much harder to market effectively, and it's unlikely you can charge for them without someone else claiming authorship and looking for a piece (or just offering them for free somewhere else) There really are very very few original scripts for admin and maintenace of SQL Server. And as you mentioned, some are so narrow they don't work for your environment.The decision to buy usually comes from an assessment of money, time, and ability. Ability can always improve, so it's mostly time and money. Lack of money leads to a lot of home grown stuff, lack of time leads to a lot of commercial pacakages. |
 |
|
|
MichaelP
Jedi Yak
2489 Posts |
Posted - 2003-08-13 : 13:47:49
|
| I totally agree with Rob on the tools thing. It's almost always a time / money trade-off. I know the only tool I've purchased is SQLCompare, and it did a great job for what we paid for it. Writing that myself would have taken much more time than the money I paid for it. Same thing with LogExplorer. Great product that would take far too much time to write by myself.As far as scripts, I think a library of scripts would not be too useful. There are far too many free examples etc out there to warrent paying for such things.Michael<Yoda>Use the Search page you must. Find the answer you will.</Yoda> |
|
|
|
Wingenious
Starting Member
11 Posts |
Posted - 2003-08-13 : 16:04:29
|
| Thanks for the replies!I understand the time versus money issue. That only makes sense.I do not understand why "it's unlikely you can charge for them without someone else claiming authorship and looking for a piece (or just offering them for free somewhere else)". If that's the expected outcome it's a very sorry statement about our society. FMS markets source code libraries for other languages. I wonder what their experience has been.I'm not talking about a package of routines that you could simply collect from a web site for free. Those are the short/simple T-SQL scripts. I'm talking about robust routines that are very similar in functionality to several different commercial products. |
|
|
|
MichaelP
Jedi Yak
2489 Posts |
Posted - 2003-08-13 : 18:10:20
|
| If you had a "robust routine" (or a set of routines) then I'd say slap a nice UI on it and sell it as a software package. That's what all the other packages have done AFAIK.They just made those difficult admin tasks easier with a nice UI.Michael<Yoda>Use the Search page you must. Find the answer you will.</Yoda> |
|
|
|
Wingenious
Starting Member
11 Posts |
Posted - 2003-08-14 : 02:52:24
|
| If a nice UI is the ticket...How do you explain the many posts from SQL Server users that shun the Enterprise Manager GUI in favor of using system stored procedures?How do you explain the popularity of the short/simple T-SQL scripts being featured on all the SQL Server web sites?What about the many products that have a pretty GUI, but lack in functionality or simply do not work (insertXpress comes to mind for me)?Brian |
|
|
|
robvolk
Most Valuable Yak
15732 Posts |
Posted - 2003-08-14 : 07:38:24
|
quote:
How do you explain the many posts from SQL Server users that shun the Enterprise Manager GUI in favor of using system stored procedures?
Because we're trying to educate people in SQL Server. If they have to actually sit down and think a little bit to do something, instead of clicking a button, they are more likely to learn. Do kids learn anything if their parents always do their homework for them?quote:
How do you explain the popularity of the short/simple T-SQL scripts being featured on all the SQL Server web sites?
Because they ARE short and simple. Don't mistake short and simple for being weak and less useful. You can probably do a lot more with 10 short and simple scripts, properly combined, than the best custom-designed monster procedure that does everything and make coffee too. One of the first concepts taught in any decent programming book is to make your code small and modular so that it can be dropped in and reused anywhere.quote:
What about the many products that have a pretty GUI, but lack in functionality or simply do not work (insertXpress comes to mind for me)?
No idea. Bad programmers. Marketing department that pushed the product out too quickly. Or just the 2nd or 3rd best product in a market where another product is substantially better.I don't think there's any real answer to "why there isn't a set of robust scripts" available, other than what Michael said. No one is going to pay money for something they still have to sit down, install, and figure out how to use, no matter how well documented it is, especially if something easier exists. If they can't click a button and go, no company is going to effectively market it. And that's as much perception as actual fact too. This is probably the biggest thing that prevents Linux from growing its share of the computer market. |
|
|
|
Page47
Master Smack Fu Yak Hacker
2878 Posts |
Posted - 2003-08-14 : 08:44:43
|
| All scripts have floors.Jay White{0} |
|
|
|
Merkin
Funky Drop Bear Fearing SQL Dude!
4970 Posts |
Posted - 2003-08-14 : 09:16:39
|
You spelt "scrip" wrongOn topic though...It feels to me like Wingenious is getting jumped on pretty hard. Don't take it personally Brian, we are a cynical bunch and get prickly with the amount of lame product spam we get around here  (not that I'm implying that about your products).My take on it is that any DBA worth their salt would have their own scripts and routines for standard tasks, and given a DBA's nature NOBODY'S routines would be better than their own  The other class of DBA, the beginner falls into two types. The one who wants to learn and the one that doesn't. Those who want to learn will figure out their own automation and mainainance scripts in order to reach category 1. Those who don't want to learn anything aren't too likely to want to pay either. They just come here and ask books online type questions If I was managing a DBA who asked me to sign off the purchase of T-SQL scripts I'd either fire them, or get them a Ken Henderson book. Depending on how much coffee I had managed to drink that morning.Damian |
|
|
|
Wingenious
Starting Member
11 Posts |
Posted - 2003-08-14 : 11:01:56
|
| Damian,Thanks for your comments. Your explanation is probably as close to reality as we're going to get. I was hoping to find some consensus, but there is none. The replies that I have gotten to this posting (on this web site and others) are filled with contradictions, even within a single reply.Some would buy a utility product if the time (to write) versus cost ratio justified it, but others would fire a DBA for wanting to buy any T-SQL code.Some would require that a product have a pretty GUI (just click a button), but others would be fine with trying to string together 10 different T-SQL scripts written in 10 different styles.The only agreement, if there is any, is that nobody seems much interested in paying anything for significant T-SQL routines, no matter what they do. There appears to be no market for such a product. That answers my original question.Brian |
|
|
|
Merkin
Funky Drop Bear Fearing SQL Dude!
4970 Posts |
Posted - 2003-08-14 : 11:45:08
|
| I guess it might help a bit more if you could give some more detail about what the routines do.Depending on their purpose there might be a business model in there somewhere. Perhaps a book containing the scripts and some explainations behind them ?Damian |
|
|
|
Wingenious
Starting Member
11 Posts |
Posted - 2003-08-15 : 17:12:23
|
| The package offers much of the functionality of these commercial products:LockwoodTech Software - SQLAudit ($599)LockwoodTech Software - Proc-Blaster ($399)Red-Gate Software - SQL Data Compare ($195)A & G Software - xp_ags_crosstab ($150)The package also offers some additional functionality that I have not seen provided by any free or commercial product.Regardless, the concept is being pretty much universally dismissed. The most common reason for dismissal is also the most puzzling. The fact that the features are implemented using T-SQL appears to be the downfall. It seems that SQL Server users are so accustomed to short/simple T-SQL scripts that anything more substantial is beyond comprehension. Further, people believe that because the package is constructed using T-SQL it can not carry a price tag. The common opinion is that T-SQL source code is supposed to be free.Brian |
|
|
|
nr
SQLTeam MVY
12543 Posts |
Posted - 2003-08-15 : 18:24:23
|
| I always write my own and wouldn't use a package for the same reason I wouldn't use maint.exe.==========================================Cursors are useful if you don't know sql.DTS can be used in a similar way.Beer is not cold and it isn't fizzy. |
|
|
|
robvolk
Most Valuable Yak
15732 Posts |
Posted - 2003-08-15 : 19:31:28
|
| I second Nigel's sentiment. It's not that the routines aren't useful. People expect a full application with an easy-to-use interface if they're going to pay for something. Anyone comfortable enough to run a script using query analyzer will probably write their own set of tools. Anyone not comfortable enough with QA will not use them.I'm not sure why you find the convenience factor puzzling. Most people buy pre-assembled computers and are willing to pay more than purchasing the components and assembling it themselves. The same applies to user interfaces. They don't just make it easier to use, they add an additional level of professional finish to the product. Add a user interface to your scripts and you'll have no problem selling them. |
|
|
|
Wingenious
Starting Member
11 Posts |
Posted - 2003-08-16 : 01:53:43
|
| What sentiment are you seconding? Nigel seems to be saying that he would not buy a SQL Server tool, period. He would not trust anybody else's programming. The time (to write) versus cost (to buy) factor would not matter. A fine GUI would not matter.The statement "Anyone comfortable enough to run a script using query analyzer will probably write their own set of tools" seems invalid. Those who thrive on short/simple T-SQL scripts that can be downloaded for free are a contradiction. If the statement is valid, for whom did Microsoft expose and document system stored procedures?It's not the convenience factor that I find puzzling, and I agree with the professional finish comment. However, those apply only if you are talking about an end-user product. I'm not. I'm talking about a product intended for a DBA (who obviously knows how to work in Query Analyzer) and/or developer. The flaw in my logic was thinking that a DBA would ever use anybody else's programming. I accept that I was wrong in my assumption. Perhaps each DBA (including myself) should consider whether his/her arrogance is justified.The real confusing aspect is probably best exemplified by the crosstab functionality. There have been many posts asking for such a routine. All of the free examples that I have seen are lacking in generality and flexibility. I mentioned a commercial product with a price tag of $150. That product appears to provide nothing more than a general and flexible crosstab function. I have no idea if the product sells, but it has been available for some time. The functionality of that product is hidden within a DLL. There is no UI. Among the many routines in the package that I have proposed is an equally general and flexible crosstab function. It may even be better. However, it was implemented with T-SQL. It appears that the feature implemented with T-SQL is not worth a fraction of the cost of the feature implemented as a DLL. Why? That's what puzzles me. |
|
|
|
nr
SQLTeam MVY
12543 Posts |
Posted - 2003-08-16 : 13:09:37
|
| >> What sentiment are you seconding? Nigel seems to be saying that he would not buy a SQL Server tool, period. He would not trust anybody else's programming. The time (to write) versus cost (to buy) factor would not matter. A fine GUI would not matter.Yep. I want to know what the product is doing as the tasks are too important. If I am going to spend the time going through the code it's probably quicker to write it myself.I tend not to use a lot of the system stored procs or enterprise manager for the same reasonCrosstab product - doubt if it sells as it's too easy to write yourself.Also anyone who wanted a script could probably just post a question on a forum and get it for free.Saying that there are a lot of "dba"'s who don't really know what they are doing and might be willing to buy a product.The same one's that might use maint.exe .==========================================Cursors are useful if you don't know sql.DTS can be used in a similar way.Beer is not cold and it isn't fizzy. |
|
|
|
|
SQL Server Tools Market