| Author |
Topic |
|
tribune
Posting Yak Master
105 Posts |
 Posted - 2003-12-06 : 19:59:14
|
| And How can I get a copy? :) |
|
|
jasper_smith
SQL Server MVP & SQLTeam MVY
846 Posts |
Posted - 2003-12-08 : 02:48:42
|
| I don't believe any public information has been available about a date for beta2. Copies were given away at both PDC and PASS this year. Beta information about SQL Server "Yukon" will be posted later this/next year on [url]http://www.microsoft.com/sql/evaluation/betanominations.asp[/url], whilst you're waiting, have a play with Reporting Services ! |
 |
|
|
tribune
Posting Yak Master
105 Posts |
Posted - 2003-12-10 : 21:53:19
|
| ARGH this sucks, I dont want to wait until april 2004 for the standard version if i'm not picked for the beta. I'm starting a massive-scale database project with over 100 tables and hundreds of stored procedures and I reaaaaaaaaally dont want to redo it all later in c# once I can finally get a copy of the server :(I wish I could have gone to PASS but alas my company did not have the money to send me. |
|
|
|
Merkin
Funky Drop Bear Fearing SQL Dude!
4970 Posts |
Posted - 2003-12-10 : 21:58:02
|
| Even with CLR integration, TSQL is still the best language for doing data manipulation. Using C# for every stored proc would perform worse, be much more difficult, and basically.... just silly.You would use C# in place of tasks like extened stored procs, and calling com objects using the sp_OA procs.Damian |
|
|
|
robvolk
Most Valuable Yak
15732 Posts |
Posted - 2003-12-10 : 22:10:00
|
| I concur. The WORST thing you can do is rewrite everything in .Net just because you can. Use SQL for data access, use C# for everything else.You CAN hammer a nail with a screwdriver, but it's not the best tool for the job. |
|
|
|
nr
SQLTeam MVY
12543 Posts |
Posted - 2003-12-10 : 22:26:00
|
| Also, when were you thinking of releasing this system based on Yukon?==========================================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. |
|
|
|
Andraax
Aged Yak Warrior
790 Posts |
Posted - 2003-12-11 : 06:59:21
|
| When do you guys think it will be up on MSDN Universal downloads? |
|
|
|
tribune
Posting Yak Master
105 Posts |
Posted - 2004-01-19 : 17:50:24
|
nr, I wanted to release a beta of the product by the end of June 2004. My deal is I'm sick of stored procedures in SQL 2k. I'm really starting to hate microsoft's T-SQL. When you program extensively in it things becoming annoying. I'd really like to be able to use a more object oriented approach to organizing the business logic and data manipulation. For example, instead of having three stored procedures like ClientAdd, ClientDelete, and ClientUpdate, I'd rather have a client object and be able to call methods to perform those functions. When you have over 100 stored procedures things really become disorganized, especially if you're not using strict naming conventions.Stored procedures = arcane  Does anyone know if there are any yukon books out? Looks like everything at amazon is still on pre-order... |
|
|
|
robvolk
Most Valuable Yak
15732 Posts |
Posted - 2004-01-19 : 22:20:07
|
quote:
My deal is I'm sick of stored procedures in SQL 2k. I'm really starting to hate microsoft's T-SQL. When you program extensively in it things becoming annoying...Stored procedures = arcane
Actually, when I've been programming in T-SQL (for about 6 years now) I've experienced the exact opposite. It has gotten progressively better and more sophisticated, and I've discovered ways to do things that could not be done anywhere near as efficiently with procedural code. For example:http://weblogs.sqlteam.com/robv/posts/182.aspxIf you know of a data import routine that works with less than one line of code (especially in .Net), then I'll concede that T-SQL can be annoying and arcane.quote:
I'd really like to be able to use a more object oriented approach to organizing the business logic and data manipulation. For example, instead of having three stored procedures like ClientAdd, ClientDelete, and ClientUpdate, I'd rather have a client object and be able to call methods to perform those functions.
So you have a package for your next door neighbor, and instead of dropping it off yourself you give it to the post office to deliver? And you have to wrap it and put postage on it and bring it to the post office and all the other things they require you to do in order to use their services. Adding extra object-oriented layers only adds overhead, not efficiency or ease of use. Anything you write to do these tasks as an object will still use T-SQL underneath, as that is the only language SQL Server recognizes. It's less work to do it as a stored procedure than it would be to do it in the application.quote:
When you have over 100 stored procedures things really become disorganized, especially if you're not using strict naming conventions.
Poor naming conventions happen in any language, with any number of procedures or modules, and are the fault of the programmer, not the language. I honestly don't know how you think putting an object-oriented interface to database code will improve that...in fact it can only make it worse, by hiding the real problem. There are over 10 years worth of SQL Server apps with thousands of tables, views, and stored procedures that are clear and easy to follow.By the way, what happens when you need to rewrite your app in another language, and have to completely redo all the data handling and business rules, instead of reusing the same stored procedures? Once you say it'll never happen, you'll guarantee it does.quote:
I wanted to release a beta of the product by the end of June 2004.
Start now, learn T-SQL, use stored procedures, and you'll definitely make it by then. Waiting for Yukon, which you do not need, will only delay release. |
|
|
|
MichaelP
Jedi Yak
2489 Posts |
Posted - 2004-01-20 : 00:43:19
|
| I've got well over 1500 stored procs in one app that I've written. Hasn't caused me any problems. ic an alwasy go right to where the stored proc in question is.Naming conventions (or code generators) are your best friend!Michael<Yoda>Use the Search page you must. Find the answer you will.</Yoda> |
|
|
|
tribune
Posting Yak Master
105 Posts |
Posted - 2004-01-21 : 14:03:39
|
quote:
Originally posted by robvolkFor example:http://weblogs.sqlteam.com/robv/posts/182.aspxIf you know of a data import routine that works with less than one line of code (especially in .Net), then I'll concede that T-SQL can be annoying and arcane.
Right, but you're using BCP which is an external program. Just because you only use one line of code to call the program doesnt mean transact sql is doing all the work. In fact its not doing ANY work, its just calling an executable which parses a command line string. This doesnt prove any utility of transact sql over what I was talking about. You could write a BCP utility in C# or whatever language you want to perform the same function. quote:
So you have a package for your next door neighbor, and instead of dropping it off yourself you give it to the post office to deliver? And you have to wrap it and put postage on it and bring it to the post office and all the other things they require you to do in order to use their services. Adding extra object-oriented layers only adds overhead, not efficiency or ease of use. Anything you write to do these tasks as an object will still use T-SQL underneath, as that is the only language SQL Server recognizes. It's less work to do it as a stored procedure than it would be to do it in the application.
What a rediculous analogy. I'm not even going to bother arguing with someone who thinks OO is innefficient and adds too much overhead to be useful. All I can derive from this reply is that you think turbo pascal and fortran are the "shizzle my nizzle dizzoggiefizzle". Its too bad everyone nowdays is an idiot and wants to develop in all these new "hyped out" technologies like .NET and XML when we could all reinvent the wheel eighty times a day and produce substandard products in the process!quote:
Poor naming conventions happen in any language, with any number of procedures or modules, and are the fault of the programmer, not the language. I honestly don't know how you think putting an object-oriented interface to database code will improve that...in fact it can only make it worse, by hiding the real problem.
Again, more anti-OO going on here. Thats telling a grocery store manager to organize each of his 5000 products alphabetically by the manufacturing brand's mother's maiden last name. Although you're probably like MichaelP who has dozens of people in his IT department so with our grocery scenario you could just have your underlines find each product one by one at the request of a shopper.quote:
By the way, what happens when you need to rewrite your app in another language, and have to completely redo all the data handling and business rules, instead of reusing the same stored procedures? Once you say it'll never happen, you'll guarantee it does.
First of all there is no need to rewrite my application in another language. If I needed to, I could choose among any of the 20+ lanaguages supported by the CLR. Furthermore, if I needed to changed databases, I could theoretically re-use my programming code with minimal changes because of the use of the .net framework (you know, that big 'API' thing that microsoft is "hyping"). For example, if I wanted to port my database to a client side XML application, I could change some of the ado.net sql provider-specific logic to serialze data to XML instead of the System.Data.SqlClient namespace. Stored procedures programmed in t-sql however are reliant upon microsoft's sql 2000 database because they extended ISO/ANSI SQL compliancy which only sql server can understand and therefore would not function when the database is ported to a different vendor.Now, I'm not bad-mouthing all uses of T-SQL. I am rather trying to convey a dissatisfaction with the current architecture of embedded business logic in the data tier by only using TSQL - because SQL only includes very 'arcane' functionality in terms of programmabilty, such as that found in turbo pascal (which is a langugage I'm sure you just love).To quote microsoft: quote:
Transact-SQL is best used in situations where the code will mostly perform data access with little or no procedural logic. Managed code is best suited for CPU intensive functions and procedures that feature complex logic, or where you want to leverage the .NET Framework's Base Class Library. [url]http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnsql90/html/sql_ovyukonnetprogfeatures.asp[/url]
TSQL doesnt support arrays, collections, iterations like foreach loops, bit shifting, classes, inheritance, polymorphism, encapsulation, overloading, structured error handling, et cetera.In addition, when you have a billion stored procedures, there's no heirarchal organization. Therefore you cant take advantage of specialization or generalization along a programmable heirarchal structure, and complex development is extremely confusing, especially for contract developers who weren't around the project from start to finish. |
|
|
|
The Enigma
Posting Yak Master
179 Posts |
Posted - 2004-01-22 : 04:32:28
|
| My opinion stands as ...T-SQL is for DBAsLanguages are for Developers .... Developers will never understand the power of T-SQL so no point arguing about that. |
|
|
|
Merkin
Funky Drop Bear Fearing SQL Dude!
4970 Posts |
Posted - 2004-01-22 : 04:34:58
|
| That is ridiculous.I am a developer, I think I "get" T-SQL pretty well.Damian |
|
|
|
The Enigma
Posting Yak Master
179 Posts |
Posted - 2004-01-22 : 04:39:21
|
| Merkin ... I was not talking about the developers who have so much knowledge of T-SQL, SQL Server that they would be more suited as DBA's. |
|
|
|
tkizer
Almighty SQL Goddess
38200 Posts |
Posted - 2004-01-22 : 12:50:08
|
| I disgree with Enigma as well.Tara |
|
|
|
tribune
Posting Yak Master
105 Posts |
Posted - 2004-01-22 : 13:37:40
|
quote:
Originally posted by The Enigma
My opinion stands as ...T-SQL is for DBAsLanguages are for Developers .... Developers will never understand the power of T-SQL so no point arguing about that.
Enigma = teH stup1|) |
|
|
|
Merkin
Funky Drop Bear Fearing SQL Dude!
4970 Posts |
Posted - 2004-01-22 : 17:40:17
|
| No need to act like a child.You have got the wrong idea about CLR support in Yukon. It won't turn into an object database. The CLR integration is more a replacement for dropping into C++ for the sorts of tasks you need an extended stored proc for.T-SQL is a fantastic language for doing set manipulation, things that would require many many lines of C# code for can be achieved in a very simple SQL statement. I do agree that writing Insert, Update, Select procs for every table does get kinda boring, but that is what a tool like Codesmith is for. You can find templates for codesmith, as well as many other object relational mapping tools to generate all of that layer for you. Then you can call those objects from the rest of your application. Maybe give that a look.Damian |
|
|
|
The Enigma
Posting Yak Master
179 Posts |
Posted - 2004-01-23 : 01:35:10
|
quote:
Originally posted by tduggan
I disgree with Enigma as well.Tara
Tara,Tell me .. how many times have you seen a multi line query that you think could have been written simply and easily in one line of t-sql ... believe me I have !!! |
|
|
|
Merkin
Funky Drop Bear Fearing SQL Dude!
4970 Posts |
Posted - 2004-01-23 : 06:31:53
|
| So what your basically saying is that you don't like seeing work done by people not competant enough to do it.That's fine.However, it's not limited to developers. I have seen "DBAs" do some horrendous things. Damian |
|
|
|
The Enigma
Posting Yak Master
179 Posts |
Posted - 2004-01-23 : 07:01:33
|
| Ya .. what i mean is Tara wouldnt like to see me code in ASP.NET .Take my word for it.And also SQL EM also has a create stored procedure wizard for creating Insert,Update & Delete procs. |
|
|
|
tkizer
Almighty SQL Goddess
38200 Posts |
Posted - 2004-01-23 : 12:21:08
|
| DBAs might have a lot of knowledge about T-SQL, but then again they might not. Developers might have a lot of knowledge about T-SQL, but then again they might not. There's no way for you to know so you can't make a statement that T-SQL is for DBAs. Developers are typically the ones who use T-SQL most. DBAs help out with performance problems, recommendations, etc... That's not to say that DBAs aren't involved with the T-SQL code though. But the point is that T-SQL is for both developers and DBAs.Tara |
|
|
|
Next Page
|
When are Yukon betas being released?