Not Northwind Planning

May 30, 2008 at 2:24 AM
What should it look like? Any ideas on the example's domain space?
May 30, 2008 at 3:06 AM
I would like to contribute! Preferably doing most of the database work.

May 30, 2008 at 4:07 AM
Edited May 30, 2008 at 4:29 AM
Thanks Scott. Love your Podcasts BTW.

I wonder if this effort could serve the greater good--something medical??  Leveraging what we create for things like patient scheduling, research, or even a medical records/EMR system might find use somewhere in the world. I have a personal interest in Multiple Sclerosis and I know you have your focus on Diabetes. 

I think hierarchies are one of the more interesting patterns in data. Many years ago I worked in aerospace--NASA, Boeing and Learjet. The BOM problem springs to mind and not everyone has seen it.

One last example could be some type of bird watching database. This can also be a complex example given the linked lists, multiple notation styles (Sibley and others) with range, habitat and all the data amateur ornathologists collect (just a beginner myself).

Too many times I've seen examples showing the WRONG practices: naming conventions (sp_mysproc), use of data types, approaches to problems (cursors). These often came by way of example from our good friends in Redmond ;)

The example should demonstrate:

1) Nice solid design and documentation.
2) Best practices by example
3) Ability to create either latin and unicode example--maybe a switch
4) More advanced approaches such as table variables vs. common table expressions (CTEs) vs. cursors -- in the context of which to use when
5) Iterative examples

Contact me if you're interested in exploring this further.

Thanks!

»:*´`´`*:«© Rowland ©»:*´`´`*:«
May 30, 2008 at 4:50 AM
This is a great idea!  I was actually just dealing with a similar issue a couple weeks ago trying to compile sample SSRS reports (think it was around 30 reports).  Every sample I found went off of a different database (AdventureWorks, AdventureWorksDW, Northwind, pubs, custom DB, etc.).  Trying to alter the samples to all go off the same db was a hassle and needing to deploy multiple "sample" databases was unnecessary.

1.) Are you thinking of doing just an OLTP implementation or also a DW/Analysis Services Cube with it as well? 
2.) Would definatly like to see the ability to use a domain that can add additional types of data (ex. when SQL 2k8 comes out I don't want to have to relearn a new sample db, we can add filestream and geo data into the existing sample database).
3.) Not sure about copyright issues, but the Automobile domain might be interesting as we can potentially incorporate hierarchical, non-hierarchy (xml), filestream and geo data.  It could also translate easy to OO.  IMO the larges bonus though is that is familar to people.  While I agree there should be sold documentation, adoption will be based upon ease and understanding of the design and domain (which is why I think AdventureWorks didn't get adopted as well and the reason AdventureWorksLT exists).

Anyway would love to help in any way that I can.
Thanks!

--AML--
May 30, 2008 at 6:21 AM
Edited May 30, 2008 at 6:29 AM
One thing that has also always been missing is CLR procedures. Documentation is a bit sparse on this subject, although there is enough to figure it out. It would be nice to incorporate the Sql Server CLR into this sample database as well. I agree with Rowland that this should attempt to be inline with best practices, but when it comes to naming conventions, every developer is a unique and beautiful snow flake. We just need to set a standard and stick to it.

As for thinking of a sample DB, I'm not as creative as some other who have posted in this arena. So I'll leave that part up to all of you, and I'll just help with the implementation and design.
May 30, 2008 at 6:55 AM
Count me in.  I can help with the middle layer and coordinating if you need.  Sounds like a fun project!
May 30, 2008 at 3:56 PM
Hi Scott count me in, I can help with programming phase. A hug from Peru
May 30, 2008 at 4:46 PM
Hi Scott count me in, I can help with programming phase. A hug from Peru
May 31, 2008 at 5:09 AM
I'm wondering if it can have elements of different "styles" - someone earlier mentioned the BOM type of database, I'm wondering if there could be a mix of something like this with some of the more simple, intuitive patterns.  Someone mentioned the idea of a "blog" database, how about a blog with entries and then modeling the tags of entries using the BOM pattern? 

Just a few cents...
May 31, 2008 at 9:40 AM

Please add me as a developer.  I am happy to work on design, coding or documentation - wherever we have a need.

I mentioned in the comments - and I think it worth one more mention.  I'd like to see some consideration to not making this a database based on a fictional "retail" company.  There are plenty of examples of that already (Adventure Works, Northwind and the Project REAL work).  Maybe this could be based on a transportation company or even a manufacturer of some commodity.

This makes the BI piece more compelling - since it wouldn't be an easily modeled concept - but instead could be a showcase for how to handle some real world "dirty data" issues.

Also - I think the making sure that the new features of the database engines are included as well - since developers will want to take advantage of these - XML datatype is the example that comes to mind.  I'd have to take a look at the SQL Server 2005/8 features to come up with a complete list.

Looking forward to working on this.

Matt


shanselman wrote:
What should it look like? Any ideas on the example's domain space?


Jun 1, 2008 at 6:38 AM
Edited Jun 1, 2008 at 6:39 AM
Maybe I missed something, but who exactly is our target audience. The answer to that question should dramatically affect the course of design by which we proceed. In my experience the Northwind database was never about the domain or the database model, but something, anything, to serve as a cohesive data source with which to demonstrate the basic points of some technology (ASP.NET / Silverlight / ADO.NET / LINQ / etc..). Even then it was "just enough" to get the some-new-technology-101, but didn't have much to offer the intermediate to advanced developer.

I see a lot of different things in the comments and simply want to throw some thoughts out there on what I have read so far. I think there are some categories that are beginning to arise that will give us some hints as to who this system is meant for.
  1. Database Development
    1. An emphasis on solving problems through the underlying data model. There are a lot of people out there who simply don't know about some of the neat things you can do through good database design, and end up doing it very very badly. The focus here would not be on the technology sitting on top of the database, but on the best practices behind the design and implementation of the database itself. To people in this category the database is the example, and not secondary to the applications which use it.
  2. Programming (Specific Technology)
    1. This is the developer who isn't trying to design a brand new application from the ground up, but needs to learn a new skill with an existing technology, or learn a new technology altogether. The underlying data model is usually (not always) going to be secondary to the technology that is being used to connect to the database, and manipulate the data. The more complicated the underlying data model, the more difficult it will be to write examples on top of.
  3. Solving Domain Problems
    1. This is by far the most difficult part of our jobs. Programming is easy in comparison to figuring out a decent solution for handling the customer who wants to add new business rules to the system every week. The reason Northwind sucks is because most professional developers are looking to solve some domain problem. Read any technical forum and most of the unanswered questions look like this "I need to be able to do X for customer Y. How do I start?"
    2. Granted this is what we get paid to do, but there are also some patterns and practices for handling very common domain problems. This type of person doesn't really care about the technology used in the application or the database, they just need to see a concrete example of a pattern that they can't get through a magazine article or a forum post.
It is also important to note that in each of these categories there are going to be different levels of expertise that any one individual will fall into, and that will dramatically affect what kind of information can be useful to them.
  1. Newbie
    1. Needs extremely simple examples so they don't get lost in the details 25-30 tables would blow their minds :)
  2. Novice
    1. Needs more complicated examples to hone their skills, but still not quite ready for "Real World" examples as trying to understand the domain model would detract from learning the basic concepts.
  3. Intermediate
    1. Contrived examples simply won't get the job done here. Needs a bigger playground that has advanced concepts, but still needs decent explanations on all the details. More importantly here is to begin to explain some of the whys as this person is going to be taking a more academic interest (hopefully) in their profession.*
    2. * There are going to be a great deal of developers in this category, sadly, who are simply looking for a "quick fix", or fast solution to some pending problem they have in their job.
  4. Advanced
    1. Looking for solid applications of new technologies and the latest patterns. This person is looking for ways to solve domain issues with the best technologies in the best possible way.
    2. This type of developer is probably helping to write samples for, and contribute to this project :)
Food for thought... Also, put me down as a developer.
Jun 3, 2008 at 9:22 AM
I like the medical idea, but not as much as I like the media library idea (it is very versatile, and highly extensible as a concept). I think jwcaroll has a good point with the summation of possible target audiences and their problems. I also think that we should take the path of solid design, good and elaborate documentation and best practice examples, both in code and in database design. We should also decide on a good modern naming scheme (also, both for code and for database entities like tables, views, sp's and the lot). Perhaps we could agree on StyleCop/FxCop style (for code)?
Jun 5, 2008 at 9:20 PM

Well I have been meaning to post on here since spotting Scott's rant on his blog so here goes.

The posts from ejneuman, jwcarroll and rowlandq were all excellent , and raised a lot of good points so I won't reiterate them here. They lay out a good set of points to consider in the decision process. As jwcaroll says we did sort of skip over the target audience and hop straight into "what would be a cool domain"mode. It's clear that we need to be very aware in advance of all the things we want this database to be able to provide in order to pick a suitable domain. Otherwise we will end up in the position of having to try and clumsily shoehorn extra bits onto the database to accomodate. So we need not only a domain that people will find it easy to identify with but also one that can support the full spectrum of possible use cases that we can envision now, and with room to potentially expand in the future. Unfortunately my specialisations in the database realm are working with front and back office trading systems for financial markets - which is probably not the most accessible subject.  I have worked on systems for travel agencies and monitoring companies as well too though which lend themselves a bit better.

When we suggest domains here we need to take a think to which of the points our colleagues have brought forward that they meet. We seem to so far have had medical, media library, bird watching and blogs. Let's throw in travel company to the mix just for the hell of it.

As far as accessibility go they all seem pretty ok. We have all gone to a travel agents or booked a holiday online. We have all been to a doctor/hospital at some point in our lives and if not most of us watch or are familiar with some form of medical drama (ER/House). We all own CD's ans are aware of their properties. Blogs are here to stay whether we like them or loathe them. Bird watching we all know due to partaking in the passtime or having made fun of someone who does.

Likewise for basic reporting they are all pretty good. How many patients had an MRI this month? How many Bearded Tits did I see in the last year? (and no I don't mean among your colleagues!). How many holidays did I sell this month? The media library may be a little harder on that front. How many Michael Jackson CD's do I own doesn't seem as engaging.

When it comes to doing BI / trend analysis then I would say that medical begins to stand out a bit, with travel being pretty good, and birdwatching not bad.

You get the idea, so I'll stop now. From what we have so far , I would say some form of medical system tracking a fictitous hospital's activity on all levels would seem to be the one closest to matching all the points brought forward. At the highest level you can have the simple list of what doctors saw what patients and prescribed what drugs in the ER. You can track the usage of all the medical equipment, track occurences of each disease, treatment success rates, correct diagnosis rates,  improvement or otherwise in rate of diagnosis compared to equipment used... it's easy to go on and on.

I could actually suggest a ton in the travel scenario, especially when it comes to say a fictional agency providing custom packages for individuals or groups. Easy to understand and good for simple and complex scenarios - however as I work in that domain I'd rather not have you lot create a great Open Source DB to upstage me :P

I'll be happy to help out on the odd bit of dev/documentation/moral support down the pub over a beer or whatever.

Jun 6, 2008 at 2:37 AM
I just wanted to drop a note saying that I'm totally heads down at TechEd, but I'm going to go through this VERY good feedback and respond first thing next week when I'm back and we'll start figuring out a plan as a group.

- Scott Hanselman
Jun 6, 2008 at 9:18 AM
Enjoy TechEd......  and you and the DX boys have a lot to answer for in decreasing productivity in my office - you can check Steamin' to see what I am talking about.

I was just re-reading the post from ejneuman on the home page and noticed he had mentioned the idea of geospatial data , which could certainly lead to some interesting demos. So having a think about it , a suggestion that encompasses that could be a Breakdown Service. That I guess is the AAA for the Americans among us , and the AA (Automobile Association not Alcoholics Anonymous!) or RAC for us Brits.

I don't think there are many people who wouldn't know how such a service operates, and it lends itself pretty well to both simple and complex scenarios. Geospatial data can be used for tracking positions of callers and of the breakdown vehicles which lets you knock up samples showing closest free responders etc. You can run analysis on average response times, number of callers per time period per given area. Should I place more responding vehicles in Area X during Period Y as we frequently see spikes there.  You can even narrow it down to locating danger points on individual streets by tracking cause of the call - was it just a blown tire, or was it an accident. Cost analysis can be thrown in by tracking mileage of responders, parts used by them on each callout etc...


Jun 6, 2008 at 9:25 AM
Hi all,

I agree with most of what has been said. I just want to emphasize that the domain of the sample data should be something that can be easily understood by the majority of the people that could benefit from such a deliverable. I mean it could be a problem if the database is going to be l about the representation of human DNA etc. In my humble opinion, it should be about a business domain that most developers might have interacted with. Ok, I realize how boring orders and invoices can be, but I am just saying not to go to the other extreme. That is if we want the possible deliverable of this project to be used by many people all over the world.

BTW, how do I become a member of this project? I am a software developer and I could help with anything. I also have quite a long experience with Developer Express XPO (OPF), and maybe we could write some examples using that.


Thanks,
Petros
Jun 10, 2008 at 5:47 AM
Just a thought, but it might be fun to make a bug tracking or version control database.  Everyone should be somewhat familiar with the data and they probably have interacted with the data.
Jun 10, 2008 at 10:05 PM
I'd like to see the database include multiple schemas and implementing best practices in terms of database design. But to make it interesting why not through in some not so best practice design decisions that we typically get lumped with in maintenance of existing products.

With the SQL Server 2008 release around the corner the plan should hopefully include some spatial tables as an option perhaps.

In terms of the domain of data, why limit it? Lets let it start off small and let it grow with a monthly or quarterly release schedule perhaps.
Jun 11, 2008 at 9:34 AM
I think the point about needing trends within the data is important.

So, brainstorming, in order to find a domain that works...

Requirements:

* Some fairly static data for basics demos, ala "Products/Posts/Media/Books"
* Some fairly dynamic time-based trending data, ala "Sales/Comments/Downloads"
* Reasonably complex to showcase modelling tools. That means > 10 tables
* Reasonably simple to jump-start demos. That means ~3 tables in a query can be immediately meaningful.

I want to find a balance between boring (but clear) and fun (but not crazy).

Totally wacky idea - What about an Northwind-LIKE site that radically extends Northwind with:

* product reviews, ratings, media, videos, geo-tagging, social networking stuff that revolves around Northwind?
* on the BI side, we could warehouses, sales, trending, etc

I know I said "NOT Northwind" but I'm wondering if we can accomplish all these goals by bringing Northwind into Web 2.0.

Too weird? Just weird enough?
Jun 11, 2008 at 10:31 AM


shanselman wrote:
Totally wacky idea - What about an Northwind-LIKE site that radically extends Northwind with:

* product reviews, ratings, media, videos, geo-tagging, social networking stuff that revolves around Northwind?
* on the BI side, we could warehouses, sales, trending, etc

I know I said "NOT Northwind" but I'm wondering if we can accomplish all these goals by bringing Northwind into Web 2.0.

Too weird? Just weird enough?

I think this idea is also worth exploring, I like the idea of a webshop-kind-of database (products/suppliers/...) featuring user ratings/reviews and comments, a (public/private) wish-list per user, "shopping buddies :)", etc. So this would be like, the Northwind of the 21st century...

I think we should summarize all of the ideas that were posted, and their pros and cons, and match them to our target audiences (which we still have to fully define) and then set up some voting of sorts to decide.

Jun 11, 2008 at 3:14 PM

shanselman wrote:
Totally wacky idea - What about an Northwind-LIKE site that radically extends Northwind with:

* product reviews, ratings, media, videos, geo-tagging, social networking stuff that revolves around Northwind?
* on the BI side, we could warehouses, sales, trending, etc

I know I said "NOT Northwind" but I'm wondering if we can accomplish all these goals by bringing Northwind into Web 2.0.

Too weird? Just weird enough?


 

If we are going to extend Northwind, we could add the following:

  1. Expense Tracking and Approval
  2. Accounts Receivable and Payable, maybe even payroll

Scott

Jun 13, 2008 at 10:16 AM

You stole the words from my mouth scott. After going through the discussion list here, i was thinking to myself - why would you want to go away with northwind at the first place. I mean many will agree that they have grown learning SQL by using Northwind. So can we enhance it. May be yes. Couple of ides you have given is absolutely necessary. I think we can make Northwind little bit more end to end by including whatever you have thought of. How about a HR module where in we can add more sales rep :). Handle the goods reciavables. I kind of like the idea of making Northwind as a web 2.0 app. That should be cool. With MVC in place this will be one rocker of an app if we can put in place. I second the idea of Web 2.0. This will give a realistic app both from the UI and back end perspective.

Thoughts ?

Jun 13, 2008 at 5:01 PM
I've been lurking for a while, and I would just like to interject how I model my domains.  First, I write down a series of sentences: "There are Employee.  Each Employee has zero or one First Name.  First Name is Person Name.  Each Employee has exactly one Last Name.  Last Name is Person Name.  Each Employee has zero or one Current Employer.  Employer is Company.  Company has exactly one Company Name.  Company Name is Entity Name.  Person Name is string.  Entity Name is string.  Each Company has zero or one Primary Address.  Address is US Address or Global Address.  US Address has exactly one Street."

And so forth.  The basic terms are "There are Foo (singular)."  "Each Foo has (exactly one | zero or one | one or more) Bar."  "Bar is Kind."  From these sentences, it is automatic how to produce a logical diagram, and from the logical diagram it is automatic how to produce an optimal physical design.  (By automatic, I mean there are no decisions to make for an individual developer.  Each developer may choose to materialize things in different ways to optimize different things.)  It's also fairly automatic how to write the queries.

I would rather formalize a process such as this with a concrete example than write a Web 2.0 app around some random database :-)
Jun 23, 2008 at 10:31 PM
tballard - I hear what you're saying. Let me ask you this. I looked again at the Northwind Database and it's so exceedingly simple that it almost reads like your sentences. Why not formalize the extension of Northwind in the way you describe?
Jun 26, 2008 at 8:10 PM
I'm in this SkypeCast room for the next hour, as it's currently NOON on Thursday (-8GMT): https://skypecasts.skype.com/skypecasts/skypecast/detailed.html?id_talk=4841279&hash=4aea155df6f7313eb699
Jun 27, 2008 at 4:54 AM
I hate to be the one to ask this question, but it probably needs to be asked.  If the idea is to extend the current Northwind database, are there any legal issues to consider?
Jun 27, 2008 at 6:21 AM
Dude, I have no idea.  I'll ask.

Poop on you for asking. :P
Jun 27, 2008 at 9:04 AM
The Northwind installation download does not include any kind of terms of use nor does the download page include any kind of information that would suggest limits to what can be done with or to the database.  With those things in mind, I don't think there's anything to worry about.
Jun 27, 2008 at 4:32 PM


shanselman wrote:
I'm in this SkypeCast room for the next hour, as it's currently NOON on Thursday (-8GMT): https://skypecasts.skype.com/skypecasts/skypecast/detailed.html?id_talk=4841279&hash=4aea155df6f7313eb699


bah. i guess i need to set replies to email notification instead of just consuming via RSS. or maybe we should plan a skype cast a bit ahead of time, so i can have a microphone at work, if that's what time it will take place at.
Jul 3, 2008 at 6:50 PM
Curses! Ok, so I guess the company is taking everyone out to lunch today, so if we were still planning on having another meeting on skype today, I will be unable to attend. Would it be possible for someone to record the call with a program like pamela? If so that would be great. If not, then I'll just continue to watch the discussions and wait for someone to post a summary of what's going on.

-Darren
Jul 3, 2008 at 7:49 PM
I've got the Skypecast up here: http://tinyurl.com/5mvesu from now until about 12:30PST, so you've got 15 min warning. ;) Hopefully it'll email this out.
Jul 3, 2008 at 10:15 PM
just got the e-mail. 2:14 PST.  Bummer I missed out.
Sep 5, 2009 at 10:19 PM

Has there been any progress on this project?

We see huge potential in this.

FYI: There are no more SkypeCasts since the 1st of September.

Sep 15, 2009 at 12:51 AM
Not really...no one really stepped up to do any planning and I haven't had the time to play cheerleader.

On Sat, Sep 5, 2009 at 2:19 PM, Shaharyar <notifications@codeplex.com> wrote:

From: Shaharyar

Has there been any progress on this project?

We see huge potential in this.

FYI: There are no more SkypeCasts since the 1st of September.

Read the full discussion online.

To add a post to this discussion, reply to this email (NorthwindCommunity@discussions.codeplex.com)

To start a new discussion for this project, email NorthwindCommunity@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com




--
Scott Hanselman
http://www.hanselman.com
Sep 15, 2009 at 5:46 PM

if planning is all what's missing, then start it simple..

what about just replicating the 100k years old Northwind database in the SQL Server 2008 environment as a mdf database? - it would totally allow us to distribute it easily

good or bad idea?

Sep 15, 2009 at 5:49 PM
Ah, just for putting in App_data? Certainly. It's easier than the .SQL file we have now. That's a good idea!

On Tue, Sep 15, 2009 at 9:47 AM, shaharyar <notifications@codeplex.com> wrote:

From: shaharyar

if planning is all what's missing, then start it simple..

what about just replicating the 100k years old Northwind database in the SQL Server 2008 environment as a mdf database? - it would totally allow us to distribute it easily

good or bad idea?

Read the full discussion online.

To add a post to this discussion, reply to this email (NorthwindCommunity@discussions.codeplex.com)

To start a new discussion for this project, email NorthwindCommunity@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com




--
Scott Hanselman
http://www.hanselman.com
Sep 15, 2009 at 7:09 PM

After re-reading the main page and what this project was targeting I think there are two parts to this project.

  1. The script to generate the database.
  2. The sample application(s)

And I think the glue for the project is the motto that it should "just work." The question we now face since this project started is, how should it "just work." Who are we trying to target here? Are we targeting people who do demo's on throw away machines? or are we targeting developers who want to look at/run/debug the code, or both?

For demo people it really depends on what they are demoing. I would guess that if it's just a simple application on a throw away virtual machine they are probably just running sql server express. Unless they are demoing websites running in the cloud, in which case is Sql Azure (which is very important as it didn't exist publicly when this project started).

For developers just wanting to jump in and see how we did the sample code I would guess sql server express also, however it's not unfeasible to believe that they might have a sql server 2005/08 server in which they run the script on. They could be in the azure category also.

To summarize, we need to pick what we want to do first and what we want to support, and do it well. I would suggest we extract the existing data into a more workable form (xml files or what not) that can be used to generate the sql for multiple databases (sql server 2008 for sure, with option of sql azure). Then once we have this, we can go about updating the data and building sample applications. But at least if we can deliver a script to generate the existing schema and data on 2008 and SQL Azure, then I think it would be beneficial to the community (let them continue using their existing sample apps for now).

Sep 15, 2009 at 7:13 PM
Well, then maybe we pivot on deliverables:

* 2008 .MDF file for /App_data and autoattach scenarios.
* Database in XML form?
* Updated .SQL File? or just re-release it here so it can be easily found?

Thoughts?

On Tue, Sep 15, 2009 at 11:10 AM, darren <notifications@codeplex.com> wrote:

From: darren

After re-reading the main page and what this project was targeting I think there are two parts to this project.

  1. The script to generate the database.
  2. The sample application(s)

And I think the glue for the project is the motto that it should "just work." The question we now face since this project started is, how should it "just work." Who are we trying to target here? Are we targeting people who do demo's on throw away machines? or are we targeting developers who want to look at/run/debug the code, or both?

For demo people it really depends on what they are demoing. I would guess that if it's just a simple application on a throw away virtual machine they are probably just running sql server express. Unless they are demoing websites running in the cloud, in which case is Sql Azure (which is very important as it didn't exist publicly when this project started).

For developers just wanting to jump in and see how we did the sample code I would guess sql server express also, however it's not unfeasible to believe that they might have a sql server 2005/08 server in which they run the script on. They could be in the azure category also.

To summarize, we need to pick what we want to do first and what we want to support, and do it well. I would suggest we extract the existing data into a more workable form (xml files or what not) that can be used to generate the sql for multiple databases (sql server 2008 for sure, with option of sql azure). Then once we have this, we can go about updating the data and building sample applications. But at least if we can deliver a script to generate the existing schema and data on 2008 and SQL Azure, then I think it would be beneficial to the community (let them continue using their existing sample apps for now).

Read the full discussion online.

To add a post to this discussion, reply to this email (NorthwindCommunity@discussions.codeplex.com)

To start a new discussion for this project, email NorthwindCommunity@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com




--
Scott Hanselman
http://www.hanselman.com
Sep 15, 2009 at 7:17 PM
This sounds pretty good to me. We can be lean about how we proceed and see where it goes from there. If we try and make the solution slice bread and solve world hunger nothing will ever happen.

On Tue, Sep 15, 2009 at 2:13 PM, shanselman <notifications@codeplex.com> wrote:

From: shanselman

Well, then maybe we pivot on deliverables:

* 2008 .MDF file for /App_data and autoattach scenarios.
* Database in XML form?
* Updated .SQL File? or just re-release it here so it can be easily found?

Thoughts?


On Tue, Sep 15, 2009 at 11:10 AM, darren <notifications@codeplex.com> wrote:

From: darren

After re-reading the main page and what this project was targeting I think there are two parts to this project.

  1. The script to generate the database.
  2. The sample application(s)

And I think the glue for the project is the motto that it should "just work." The question we now face since this project started is, how should it "just work." Who are we trying to target here? Are we targeting people who do demo's on throw away machines? or are we targeting developers who want to look at/run/debug the code, or both?

For demo people it really depends on what they are demoing. I would guess that if it's just a simple application on a throw away virtual machine they are probably just running sql server express. Unless they are demoing websites running in the cloud, in which case is Sql Azure (which is very important as it didn't exist publicly when this project started).

For developers just wanting to jump in and see how we did the sample code I would guess sql server express also, however it's not unfeasible to believe that they might have a sql server 2005/08 server in which they run the script on. They could be in the azure category also.

To summarize, we need to pick what we want to do first and what we want to support, and do it well. I would suggest we extract the existing data into a more workable form (xml files or what not) that can be used to generate the sql for multiple databases (sql server 2008 for sure, with option of sql azure). Then once we have this, we can go about updating the data and building sample applications. But at least if we can deliver a script to generate the existing schema and data on 2008 and SQL Azure, then I think it would be beneficial to the community (let them continue using their existing sample apps for now).

Read the full discussion online.

To add a post to this discussion, reply to this email (NorthwindCommunity@discussions.codeplex.com)

To start a new discussion for this project, email NorthwindCommunity@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com




--
Scott Hanselman
http://www.hanselman.com

Read the full discussion online.

To add a post to this discussion, reply to this email (NorthwindCommunity@discussions.codeplex.com)

To start a new discussion for this project, email NorthwindCommunity@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com


Sep 15, 2009 at 8:10 PM
Edited Sep 15, 2009 at 8:13 PM

I would say data dump to .sql/.mdf, then extract data into seperate human readable files that can be combined into a script. The advantages of having something like an xml file is that we can isolate changes to related data and multiple people can work on different parts all at the same time without having to do crazy diff's against one big giant text file. It also allows us to isolate the data so that the generated script can be different based on the target database. Cons are that now we have to figure out a way to generate the script and we have the angle bracket tax.

For the release strategy, the following is under the concept if we went with a generated script approach. I think what would be ideal is if we made an MSBuild task or leveraged an existing community one as well as continuous integration so that when we decide to do a release, it would go and generate a .sql file for each database we want to support, and optionally a native data file for each database we want to support. Generating the data file is a bit tricky as we would need the integration to run on a machine that has the server installed so that we could run the sql script on it then grab the data. I'm not sure what level of CI support CodePlex has in comparison to TFS, so all of this would depend. Without CI, we could just run the build script and then upload the script to releases as well.

I am very much for the idea of doing an initial release right now of sql server 2008 script / mdf as well as a script that will work on sql azure (if that's how it's done). I believe i have access to sql azure, but i'll have to double check. I could tackle figuring out what needs to be done to create a sql azure database and how we could get northwind data on it.

 

*Edit*
just looked, don't have an invite to the sql part. i'm sure hanselman could acquire one for the projects use though. 

Sep 15, 2009 at 8:56 PM

As jwcarroll stated, I’m all for starting off small and then building upon it. 

As far as release strategy, most Codeplex project released as Visual Studio projects with a build file.  Why not follow suit utilizing Visual Studio for Database Professionals?   This would have the added benefit of integrating straight into TFS on Codeplex and we could include Data Generation plans and Unit Tests and the build file is just a .sql file.

Thoughts?

From: darren [mailto:notifications@codeplex.com]
Sent: Tuesday, September 15, 2009 2:10 PM
To: aaron_m_lowe@hotmail.com
Subject: Re: Not Northwind Planning [NorthwindCommunity:28681]

From: darren

I would say data dump to .sql/.mdf, then extract data into seperate human readable files that can be combined into a script. The advantages of having something like an xml file is that we can isolate changes to related data and multiple people can work on different parts all at the same time without having to do crazy diff's against one big giant text file. It also allows us to isolate the data so that the generated script can be different based on the target database. Cons are that now we have to figure out a way to generate the script and we have the angle bracket tax.

For the release strategy, the following is under the concept if we went with a generated script approach. I think what would be ideal is if we made an MSBuild task or leveraged an existing community one as well as continuous integration so that when we decide to do a release, it would go and generate a .sql file for each database we want to support, and optionally a native data file for each database we want to support. Generating the data file is a bit tricky as we would need the integration to run on a machine that has the server installed so that we could run the sql script on it then grab the data. I'm not sure what level of CI support CodePlex has in comparison to TFS, so all of this would depend. Without CI, we could just run the build script and then upload the script to releases as well.

I am very much for the idea of doing an initial release right now of sql server 2008 script / mdf as well as a script that will work on sql azure (if that's how it's done). I believe i have access to sql azure, but i'll have to double check. I could tackle figuring out what needs to be done to create a sql azure database and how we could get northwind data on it.

Read the full discussion online.

To add a post to this discussion, reply to this email (NorthwindCommunity@discussions.codeplex.com)

To start a new discussion for this project, email NorthwindCommunity@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com

Sep 15, 2009 at 9:15 PM
Interesting point. I'd like both, a project AND a zip file.

On Tue, Sep 15, 2009 at 12:56 PM, AaronL <notifications@codeplex.com> wrote:

From: AaronL

As jwcarroll stated, I’m all for starting off small and then building upon it. 

As far as release strategy, most Codeplex project released as Visual Studio projects with a build file.  Why not follow suit utilizing Visual Studio for Database Professionals?   This would have the added benefit of integrating straight into TFS on Codeplex and we could include Data Generation plans and Unit Tests and the build file is just a .sql file.

Thoughts?

From: darren [mailto:[email removed]]
Sent: Tuesday, September 15, 2009 2:10 PM
To: [email removed]
Subject: Re: Not Northwind Planning [NorthwindCommunity:28681]

From: darren

I would say data dump to .sql/.mdf, then extract data into seperate human readable files that can be combined into a script. The advantages of having something like an xml file is that we can isolate changes to related data and multiple people can work on different parts all at the same time without having to do crazy diff's against one big giant text file. It also allows us to isolate the data so that the generated script can be different based on the target database. Cons are that now we have to figure out a way to generate the script and we have the angle bracket tax.

For the release strategy, the following is under the concept if we went with a generated script approach. I think what would be ideal is if we made an MSBuild task or leveraged an existing community one as well as continuous integration so that when we decide to do a release, it would go and generate a .sql file for each database we want to support, and optionally a native data file for each database we want to support. Generating the data file is a bit tricky as we would need the integration to run on a machine that has the server installed so that we could run the sql script on it then grab the data. I'm not sure what level of CI support CodePlex has in comparison to TFS, so all of this would depend. Without CI, we could just run the build script and then upload the script to releases as well.

I am very much for the idea of doing an initial release right now of sql server 2008 script / mdf as well as a script that will work on sql azure (if that's how it's done). I believe i have access to sql azure, but i'll have to double check. I could tackle figuring out what needs to be done to create a sql azure database and how we could get northwind data on it.

Read the full discussion online.

To add a post to this discussion, reply to this email (NorthwindCommunity@discussions.codeplex.com)

To start a new discussion for this project, email NorthwindCommunity@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com

Read the full discussion online.

To add a post to this discussion, reply to this email (NorthwindCommunity@discussions.codeplex.com)

To start a new discussion for this project, email NorthwindCommunity@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com




--
Scott Hanselman
http://www.hanselman.com
Sep 15, 2009 at 9:35 PM

As stated earlier, we should build on the basics of the available Northwind Database.

The current database is perfect for all days use. The ONLY thing it lacks is not being up to date with latest technologies.

Adapt the old database to SQL 2008 first. Then decide on the basic project to retreive data from it.

During the database construction/design we'll face a lot of changes and updates which will require us to change all the additional .sql/zip files or generate them every time.

Steps which would ease the pain and actually move the project forward would be:

  • Create an ASP.NET MVC Project (might also be some other project template else, just using MVC because it's too cool to be true ;-))
  • Create new Northwind Database
  • As shanselman said:  Put the database in the App_Data dir of the project.
  • We are now ready to build upon this initial project setup.

Deciding too much at a too early stage only causes trouble later on ;-).

Sep 15, 2009 at 11:34 PM

@AaronL - VS for Database Professionals really is only seen a whole lot with people who use Team Suite or people that are just DBA's. I would venture to say that most people won't have it or won't install VSTS on a VM for a demo. While it would be nice to use it to generate the script, I don't think we'll be able to get away with that kind of dependency. I personally have access to it, but don't have it installed currently as part of my VSTS setup because i never use it.

@shaharyar - the .zip files should only be created on release builds. normal day to day development shouldn't be creating these.

I believe what we are looking at here is 2 conceptually different projects: the changes/updating of northwind and sample projects. I would suggest approaching these like so:

The project that is changing/updating/expanding the northwind data and schema will most likely be getting rapid changes and should be based on scripts that generate the database (we could look into following this model). This should have unit tests associated with it to make sure that we don't break anything. Releases will generate .sql files for supported databases.

The project that contains sample projects should only reference release version .sql files and create the database or should have the pre-generated database file in the app_data folder. This will allow the developers to update the sample applications only when the changes to the database have been approved an accepted. This way we can also build sample applications with the stock northwind database until we have time to start updating / changing / extending it.

Thoughts? Suggestions?

Sep 16, 2009 at 1:06 AM

True DBPro only comes under either Developer or Database which are both team system editions so the sku is limited to those who would have it (and I’m not going to even touch the “just DBA’s” comment J)

Regarding DBPro, personally I’ve been using it off and on since the originally CTPs, and consistently since the first of this year.  I absolutely agree that DBPro would be more widely used if it was in a sku that wasn’t Team system specific, but on the other hand it does have a many strengths which have been discussed, like the unit testing and datagen that have been mentioned.

 

As you mention below that the question of who is the intended audience is as Northwind was used for both database presentations/learning as well as application layer presentations/learning.  I agree with you that it should be separated out. 

However if we separated it out, why wouldn’t we build the DB with DBPro and the sample projects (the one for just developers J) that only reference the output of the database project?

Just continuing the discussion. J

From: darren [mailto:notifications@codeplex.com]
Sent: Tuesday, September 15, 2009 5:35 PM
To: aaron_m_lowe@hotmail.com
Subject: Re: Not Northwind Planning [NorthwindCommunity:28681]

From: darren

@AaronL - VS for Database Professionals really is only seen a whole lot with people who use Team Suite or people that are just DBA's. I would venture to say that most people won't have it or won't install VSTS on a VM for a demo. While it would be nice to use it to generate the script, I don't think we'll be able to get away with that kind of dependency. I personally have access to it, but don't have it installed currently as part of my VSTS setup because i never use it.

@shaharyar - the .zip files should only be created on release builds. normal day to day development shouldn't be creating these.

I believe what we are looking at here is 2 conceptually different projects: the changes/updating of northwind and sample projects. I would suggest approaching these like so:

The project that is changing/updating/expanding the northwind data and schema will most likely be getting rapid changes and should be based on scripts that generate the database (we could look into following this model). This should have unit tests associated with it to make sure that we don't break anything. Releases will generate .sql files for supported databases.

The project that contains sample projects should only reference release version .sql files and create the database or should have the pre-generated database file in the app_data folder. This will allow the developers to update the sample applications only when the changes to the database have been approved an accepted. This way we can also build sample applications with the stock northwind database until we have time to start updating / changing / extending it.

Thoughts? Suggestions?

Read the full discussion online.

To add a post to this discussion, reply to this email (NorthwindCommunity@discussions.codeplex.com)

To start a new discussion for this project, email NorthwindCommunity@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com

Sep 19, 2009 at 11:05 PM

@AaronL: 

That sounds great!

We could put the database in its own "secured" environment with all it's tests associated.

Having another project containing the logic and samples to access that particular database.

Very are getting there! ;-)

Mar 29, 2012 at 6:21 PM

It looks like this project has been abandoned, but I still think there could be something to building a database that'd take the place of northwind/adventureworks.  What if the efforts were made to build a database for something like NerdDinner, but that could be used for charity events?  There's a lot of different types of data that would be stored and with the Db we could do something good for the community as well as providing good samples for devs.

Mar 29, 2012 at 6:32 PM
Yes, no one really rallied around this project. Happy for any help.
--
Scott Hanselman

On Mar 29, 2012, at 10:21 AM, "nlinus" <notifications@codeplex.com> wrote:

From: nlinus

It looks like this project has been abandoned, but I still think there could be something to building a database that'd take the place of northwind/adventureworks. What if the efforts were made to build a database for something like NerdDinner, but that could be used for charity events? There's a lot of different types of data that would be stored and with the Db we could do something good for the community as well as providing good samples for devs.