| Author |
Topic |
|
Page47
Master Smack Fu Yak Hacker
2878 Posts |
 Posted - 2007-02-07 : 09:14:45
|
| Is anybody using Microsoft Visual Studio 2005 Team Edition for Database Professionals?Jayto here knows when |
|
|
Kristen
Test
22859 Posts |
Posted - 2007-02-07 : 09:40:15
|
| hehhe .. I thought Database Professionals used Notepad! |
 |
|
|
harsh_athalye
Master Smack Fu Yak Hacker
5581 Posts |
Posted - 2007-02-07 : 09:53:54
|
Who Cares...I am too lazy to use different tools unless it can't be done in QA (which is very rare)! Harsh AthalyeIndia."The IMPOSSIBLE is often UNTRIED" |
|
|
|
Page47
Master Smack Fu Yak Hacker
2878 Posts |
Posted - 2007-02-07 : 09:59:03
|
| Team development options:1.) Free-for-all, shoot-from-the-hip cowboy-style2.) Management Studio project under source control3.) Visual Studio 2005 Database Project under source control4.) VSTE for DPI use mostly 2, but inevitably, the actual database and the source control repository get out of sync (that is to say, someone makes a DML change to the DB without checking the script in/out). The same is possible with 3, and so far, I see no real benefit to VS for T-SQL over Management Studio. So far, without fail, 2 and 3 turn into 1 until something gets majorly fuct and we have to stop and regroup. I'm unclear if 4 will solve my problem, but I don't think so. The refactoring stuff in 4 would be helpful and the unit testing integeration stuff I don't need.Why are development tools for us so immature when compared to the rest of the dev community?Jayto here knows when |
|
|
|
Page47
Master Smack Fu Yak Hacker
2878 Posts |
Posted - 2007-02-07 : 10:02:31
|
| Granted, if you are a DBA or in-house DB dev-lite, VSTE4DP is not for you ... but for a team of designers/proc-writers creating a shrink-wrapped product or major consulting deployment, trying to shoot-from-the-hip and manage quality using "process" is a PITA.Jayto here knows when |
|
|
|
Kristen
Test
22859 Posts |
Posted - 2007-02-07 : 10:32:39
|
| What's wrong with dis-allowing all DDL unless it is scripted?And then if the script is stored in a project folder it (presumably) gets into the Source Control autoMagically, no?Kristen |
|
|
|
X002548
Not Just a Number
15586 Posts |
|
|
Page47
Master Smack Fu Yak Hacker
2878 Posts |
Posted - 2007-02-07 : 11:18:39
|
quote:
Originally posted by Kristen
What's wrong with dis-allowing all DDL unless it is scripted?
How?With a .NET project (under-source control), the one truth resides under control. At any given time, you can (should be able to) make a build from source control. The concept of someone changing a method outside of source control simple doesn't exist.Not the same for a SQL Project in Managment Studio under SourceSafe. The one truth is what is on the database server and source control is a view of that truth that is only as good as the "people processes" in place that keep it in sync. Usually, people processes fall apart, especially when DBAs put on Nomex suits and helmets to fight fires.Jayto here knows when |
|
|
|
Page47
Master Smack Fu Yak Hacker
2878 Posts |
Posted - 2007-02-07 : 11:20:08
|
| VSTE4DP makes things a little better by giving you a tool to visually see where the people processes have fallen apart, but as best I can tell, there is no tool that takes the people process out of the equation.Jayto here knows when |
|
|
|
Page47
Master Smack Fu Yak Hacker
2878 Posts |
Posted - 2007-02-07 : 11:28:19
|
quote:
Originally posted by X002548
Jay, where the heck have you been? Where the heck have I been?
Been working ... my SQLTeam times seems to come in spurts.quote:
Originally posted by X002548Who would let object changes be made with out the dba group doing it?
Well, that kinda presumes you have a DBA group. With one or maybe two people you can shoot from the hip. Nightly backups is your source control. Lean and Mean. With 25 people, you make a 2-3 person DBA group that does nothing but prevent the DB developers from screwing each other up. But what about the middle group of 5 to 15 developers building a new database? Do you make one guy the DBA and have the other 4 ask him to check changes in and out of the DB? Software developers don't have to deal with that BS ... you can have a team of 50 .NET programmers and VS and SS alone will pretty much keep them from over-writing each others code. Why do DB teams need to hire an $80K/year person to do what .NET progammers get in code for less than 1/10th the cost?Jayto here knows when |
|
|
|
X002548
Not Just a Number
15586 Posts |
|
|
Page47
Master Smack Fu Yak Hacker
2878 Posts |
Posted - 2007-02-07 : 12:15:12
|
| Brett, I don't know how to do modeling in such a way that frees me from the pains of software process. Every place I've worked, a logic model is established but the physical data model lives and adapts as requirements are tackled.Do you think developers have all the object models etched in stone before writing a single line of code? I've never seen it.Jayto here knows when |
|
|
|
Kristen
Test
22859 Posts |
Posted - 2007-02-07 : 12:35:23
|
"How?"I suppose "hire & fire" is not going to cover it?  "but as best I can tell, there is no tool that takes the people process out of the equation."Script out the database, each night, and stick that in your Version Control?Probably better than nothing ... and at least provides some answers to "When did XXX change, and in what way"Kristen |
|
|
|
spirit1
Cybernetic Yak Master
11752 Posts |
Posted - 2007-02-07 : 13:10:54
|
or run have a trace running?Go with the flow & have fun! Else fight the flow  blog thingie: http://weblogs.sqlteam.com/mladenp |
|
|
|
jezemine
Master Smack Fu Yak Hacker
2886 Posts |
Posted - 2007-02-07 : 16:50:36
|
quote:
Originally posted by Page47
quote:
Originally posted by Kristen
What's wrong with dis-allowing all DDL unless it is scripted?
How?With a .NET project (under-source control), the one truth resides under control. At any given time, you can (should be able to) make a build from source control. The concept of someone changing a method outside of source control simple doesn't exist.Not the same for a SQL Project in Managment Studio under SourceSafe. The one truth is what is on the database server and source control is a view of that truth that is only as good as the "people processes" in place that keep it in sync. Usually, people processes fall apart, especially when DBAs put on Nomex suits and helmets to fight fires.Jayto here knows when
In our org what's on the db server is NOT the truth. If it's not in source control, it's not in the product. each object is checked in as a separate file, and there's a bat file that executes them to produce a "build" of the relevant database, including seed data. Seed data, if it's a small amount, is checked in as well. if it's millions of rows, we put a bcp file on a separate file server that's backed up (but not version controlled).Of course, it's up each org to put the "database compiler" thing in practice. The build process for a database is very much a homegrown thing. This is in stark contrast to compiled binaries: there you don't have to build your own C# compiler!
www.elsasoft.org |
|
|
|
rockmoose
SQL Natt Alfen
3279 Posts |
Posted - 2007-02-07 : 17:28:37
|
quote:
Originally posted by jezemine
quote:
Originally posted by Page47
quote:
Originally posted by Kristen
What's wrong with dis-allowing all DDL unless it is scripted?
How?With a .NET project (under-source control), the one truth resides under control. At any given time, you can (should be able to) make a build from source control. The concept of someone changing a method outside of source control simple doesn't exist.Not the same for a SQL Project in Managment Studio under SourceSafe. The one truth is what is on the database server and source control is a view of that truth that is only as good as the "people processes" in place that keep it in sync. Usually, people processes fall apart, especially when DBAs put on Nomex suits and helmets to fight fires.Jayto here knows when
In our org what's on the db server is NOT the truth. If it's not in source control, it's not in the product. each object is checked in as a separate file, and there's a bat file that executes them to produce a "build" of the relevant database, including seed data. Seed data, if it's a small amount, is checked in as well. if it's millions of rows, we put a bcp file on a separate file server that's backed up (but not version controlled).Of course, it's up each org to put the "database compiler" thing in practice. The build process for a database is very much a homegrown thing. This is in stark contrast to compiled binaries: there you don't have to build your own C# compiler!
www.elsasoft.org
As soon as the db is in production it IS the truth.rockmoose |
|
|
|
Page47
Master Smack Fu Yak Hacker
2878 Posts |
Posted - 2007-02-07 : 17:55:33
|
| Yeah, Jesse ... that seems to be the only way to do it ... I was hoping VSTE4DB was going to do, at least, some of that stuff, but it doesn't look like it. Neat tools, but not the DB killer app I was hoping for ... and not worth the crazy price tag, I should mention.Jayto here knows when |
|
|
|
jezemine
Master Smack Fu Yak Hacker
2886 Posts |
Posted - 2007-02-07 : 19:47:34
|
quote:
Originally posted by rockmooseAs soon as the db is in production it IS the truth.
Sort of. As a dev, I think of prod as the customer. The bits that the customer has diverge from what's in source control as soon as you ship. Bugs are found, fixed in source control, and may or may not be taken by the customer. Which is the truth then? As far as the dev process is concerned, the truth is still in source control. If it's not, the process is broken.Jay: here's a cheap (free) database compiler for ya if you don't like high price tags: http://www.elsasoft.org/tools.htm1. scriptdb generates scripts of all objects in the db so you can put them in source control. probably you don't need that as you already are using VSS.2. included in the download is a bat file that builds all generated scripts. feel free to edit it as appropriate for your system. it's basically a template for how you can "compile" the scripts generated in step 1. Using a batch file like that, it's easy to call it from another bat to do nightly bvts of all databases you have in VSS. and then send angry mail to the dev that broke the build. fun!
www.elsasoft.org |
|
|
|
Page47
Master Smack Fu Yak Hacker
2878 Posts |
Posted - 2007-02-08 : 06:27:07
|
| Thanks Jesse. In fact, I've already used your scripting tool for scripting out older DBs. It works great. (I've also been telling everyone I know about SQLSpec).I've been using custom SQLCMD as the bit to execute the scripts to get a build.The bottom line is I'm just not satisfied. I work in a small, smart, super-fast based group and slowing down to figure out what didn't get check in and other process related things is screwing up our flow more and more.I think as a community, we need to start realizing that compared to the processes our Dev collegues are using, we are in the stone ages.Jayto here knows when |
|
|
|
Kristen
Test
22859 Posts |
Posted - 2007-02-08 : 08:03:20
|
| "In our org what's on the db server is NOT the truth. If it's not in source control, it's not in the product."Us too.We do compare DEV to QA though to check for any Odds & Sods that crept in. Then we re-modify the DDL scripts to match what happened on Dev; and then we have a Public Execution!All our Sproc scripts have a little "insert" at the top that puts Date and Version into a logging table. Easy to compare DEV and QA to see if anything has changed "the wrong way round" - i.e. after running the latest scripts on QA it should have all-same-version as DEV and all-sprocs-more-recently-created than DEV.We also compare "meta data" tables (changes to which are also supposed to be scripted)Kristen |
|
|
|
jezemine
Master Smack Fu Yak Hacker
2886 Posts |
Posted - 2007-02-08 : 12:52:19
|
Thanks Jesse. In fact, I've already used your scripting tool for scripting out older DBs. It works great. (I've also been telling everyone I know about SQLSpec).thanks! if you use DB2 or PostgreSQL, there's a beta out that supports those: http://www.elsasoft.org/sqlspec_db2.zipThe bottom line is I'm just not satisfied. I work in a small, smart, super-fast based group and slowing down to figure out what didn't get check in and other process related things is screwing up our flow more and more.that problem is not unique to sql development. one of the most common ways to break a C/C++/C# build is to forget to check in a file. The only way to catch this stuff early that I know of is to set up an autobuilder. basically this is a dedicated machine that monitors your source control installation. Whenever it sees a file has been added/changed, it gets latest and kicks off a FULL build (which would include building all databases, as well as all binaries). if you have BVTs, it would launch those as well (assuming the build didn't break).if it finds a break, it sends out mail to the whole dev team. Someone, usually the breaker if they are around, investigates and fixes the problem. Spamming the entire dev team is a strong deterrent to breaking the build, let me tell you! Nothing motivates like being embarrassed in front of your peers. This kind of system is widely used internally by many groups at ms. We don't have that kind of thing set up where I work now because we are too small, just don't have the resources. But with a larger project like sql server for example, I think it's essential. if you check in a change that breaks master or msdb, you want to know before that change get integrated into the mainline!also, with a larger project, somehow the average number of breaks per dev seems to go up. that's my experience anyway. For a while at ms I worked on vista - every day there were build breaks and the breaker had to go to the "war room" the next day and explain himself. very motivating!
www.elsasoft.org |
|
|
|
Next Page
|
VSTE for DP