Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase 1234»»»

Guest Editorial: Improving Northwind Expand / Collapse
Author
Message
Posted Tuesday, March 10, 2009 11:08 PM


Mr or Mrs. 500

Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500

Group: General Forum Members
Last Login: Today @ 12:38 PM
Points: 587, Visits: 2,550
Comments posted to this topic are about the item Guest Editorial: Improving Northwind


Best wishes,

Phil Factor
Simple Talk
Post #672990
Posted Wednesday, March 11, 2009 2:53 AM
SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Tuesday, October 6, 2009 8:24 AM
Points: 284, Visits: 70
I used to be a software trainer specialising in Access from beginner to VBA, so I have a great fondness for Northwind - Nancy Davolio, Alfreds Futterkiste, Laughing Lumberjack Lager.....

I especially liked the version that shipped with Access 95, where the photo of Nancy had been replaced but they had left her date of birth the same, so it appeared that the attractive young blonde lady was in her 50s.

As you say, it is an excellent way to learn about databases and part of it's strength is it's simplicity. I vote for leaving it as it is.
Post #673057
Posted Wednesday, March 11, 2009 4:39 AM
Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: Friday, October 17, 2014 2:01 AM
Points: 1,155, Visits: 1,049
A generation of learners, since 1997


Longer than that, surely. I think it was available in Access 2.0 ( around 1993 ?), maybe earlier.

I wonder where Nancy Davolio is now ?

Post #673088
Posted Wednesday, March 11, 2009 4:55 AM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Monday, August 18, 2014 4:04 AM
Points: 176, Visits: 567
you should have seen the visual foxpro version of it. it was quite a complex OOP example, which i could take off a few pieces at a time to use.

i am quite proud to have my db lineage start from DBaseIII+ and VFP. later on, i didn't have much problem about taking care of indexes, relational keys and the need for normalization of tables to reduce disk usage.

even at this time when there are affordable, 400GB servers, a well-normalized database still provides better speed. before anyone debates on normalization, i agree to all your points provided performance is better.
Post #673090
Posted Wednesday, March 11, 2009 6:34 AM
Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: Thursday, August 21, 2014 11:43 AM
Points: 1,171, Visits: 139
Let's have fun and try to improve it.

Count me in.
Post #673177
Posted Wednesday, March 11, 2009 6:58 AM


Old Hand

Old HandOld HandOld HandOld HandOld HandOld HandOld HandOld Hand

Group: General Forum Members
Last Login: Monday, May 7, 2012 9:23 AM
Points: 304, Visits: 716
Geospatial data? Taxonomic data? Temporal data? Geez Phil, isn't the Northwind database supposed to be a learning database used to bring people interested in becoming SQL Gurus up through the ranks? When you ask the question; "Can't we as a community, do better?" - are you asking this only for the Obi Wan Kenobis of SQL Server? Or does the "community" also include the people who just getting wet behind the ears with SQL? Does it include the people just tracking your average mundane business data? After all, thats the greater part of the SQL population - not everyone NEEDS a geospatial record of the widgets their business keeps track of.

In the late 90's I worked for a small company where almost everyone knew a little SQL - enough to run a query and get the answers they needed. Seems over the last 10 years as SQL has become more and more complex, with new often confusing features to newbies, SQL expertise is harder to define and we seem to be approaching a place where only the "few Wizards" will be "in the know". Is this really a good thing?

Maybe what we need are two databases - one with good 'basics' use, like Northwind, and then another with the kind of data that Phil, you are talking about. As an old-timer, at this game for decades, I am of course impressed with SQL these days - but I am also aware that fewer and fewer people are interested in it because of its complexity. Again I ask, is this a good thing?

Well, to be topical... The financial industry just collapsed on the back of complexity and it's confusion that even the people selling the instruments could not decipher. In fact today, we don't even know how big a mess we're in because it will take years to figure out these complex financial inventions that only a very few people even understand. Is THAT a good thing? Nope - and maybe we should all take that as a warning.

KISS - Keep it simple, stupid - its not all that bad an idea, and before anyone starts producing some new demo data, I sure would like them to consider the BIG picture for a change - not just the "boy thats cool" picture. After all, though some companies are doing very cool stuff, most are just trying to keep track of things and do business. We should not lose site of that. Its not a dishonorable thing.


There's no such thing as dumb questions, only poorly thought-out answers...
Post #673203
Posted Wednesday, March 11, 2009 7:05 AM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Thursday, April 23, 2009 9:32 AM
Points: 109, Visits: 70
I think that there is plenty of room in NorthWind for both simple and complex tables. A well designed database should include simple tables as well as complex relationships, data types, etc. When you are learning basic table structure, you don't need to know about stored procedures - but they can still be in the database, waiting patiently for you to get around to them. Viva complexity! - as long as we keep the simple stuff. I would love to have samples available for some of the medium to heavy-duty concepts that SS supports!
Post #673214
Posted Wednesday, March 11, 2009 7:24 AM


SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Friday, March 27, 2009 7:26 AM
Points: 105, Visits: 323
Why not still keep it simple with multiple training databases. So, keep Northwind as a general database. Then you can have one simple database that shows how to use analysis services - and it would be built with just SSAS in mind. Then have another one for spatial data, etc. They could still be small, simple and concise - and used for specific training purposes. Why does it have to be one huge database that covers everything?

Mia

I have come to the conclusion that the top man has one principle responsibility: to provide an atmosphere in which creative mavericks can do useful work.
-- David M. Ogilvy
Post #673229
Posted Wednesday, March 11, 2009 7:25 AM


SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Friday, October 17, 2014 2:10 PM
Points: 153, Visits: 570
Improving Northwind is a good idea. However, let's remember that databases are used in a lot of diverse ways. So, let's not make the mistake of thinking that there can be one database that best demonstrates all of the recent developments in db technology and theory. For example, we may need a database for "Voyager Transportation" to show the power of geospatial data.

Having said that, I recall a number of debates on this forum with topics like "why bother with CLR?" (stated in more polite terms) and "why bother with XML in a database" (I think the editorial writer for that one was a little more blatent in his dislike for XML). If Microsoft is going to put the resources into adding features like these and more to SQL Server, perhaps it would behoove them to come up with some examples of how these technologies can shine in a proper setting?

If it's possible to put multiple developments into one database, then great. Let's just be careful as Database "experts" to avoid the mistakes that we always criticize others for doing, such as creating a swiss army knife database that contains a lot of technology, but which doesn't really make any sense in the real world.


___________________________________________________
“Politicians are like diapers. They both need changing regularly and for the same reason.”
Post #673232
Posted Wednesday, March 11, 2009 7:44 AM


SSChampion

SSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampion

Group: General Forum Members
Last Login: Friday, June 27, 2014 12:43 PM
Points: 13,872, Visits: 9,596
I like the idea of a database that gradually increases in complexity as you progress through various training exercises in it.

Start out with a table of customers, a table of salespeople, a table of products, and a table of orders, and perhaps a many-to-many join between orders and products. Very simple structure, just enough to get an idea of what a relation (table) is, what normal forms mean, and how simple foreign keys work. Something a real business could use as a starting place for replacing a file cabinet of paper order forms. Start out with contact data in the customers table, to illustrate the weaknesses of that violation of normal form, but still make the database human-understandable.

Then, with a script that encompasses the necessary DDL and insert tasks, add in inventory and a running totals problem, maybe add in employee hierarchies, and perhaps a more complex way to track customer contact data, such as a table of addresses with customer ID and address type, separation of address and phone and e-mail, and so on. Lesson covers running totals, adjacency hierarchies, and higher normal forms.

Another script with necessary DDL and DML, and you morph the database to include billing data including encrypted credit card numbers, more employee data including encrypted SSNs (or whatever), more complex database security access including logins and groups. Lesson is on security and encryption.

And so on, one script per set of lessons, with the database getting more and more complex each time. It would be easy enough to build that way, and would progressively increase SQL skill and knowledge. Would be slightly more complex to make sure that no script was dependent on any other script having already been run, unless it is a more advanced lesson specifically building on the prior lesson. E.g.: Security 2 could be dependent on Security 1, but independent of Normal Forms 1.

Does that sound like a good compromise between starting out simple and still being able to get the most complex and advanced subjects in there?


- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread

"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
Post #673248
« Prev Topic | Next Topic »

Add to briefcase 1234»»»

Permissions Expand / Collapse