The Northwind 2 Project

[GPGeorge]

Microsoft is sponsoring a community project to modernize Northwind. A small team of people, including Access MVP's Tom Van Stiphout and Crystal Long, along with George Young and myself have gone through the first phase, developing a set of specs for "Northwind 2". Tom and George Y made the project public at the Denver Area Access User Group meeting on Thursday, the 21st.

Basically, there will be two versions of Northwind, a Starter version to introduce new Access developers to the main features of Access built around a simplified Data Model, and a Developer version with more advanced features and built around a more fully developed Data Model. Neither model is intended to be implemented as a solution for any existing or planned business. One of the things that became clear in early days of planning was that no data model can be expected to work for all possible businesses, and even at a less ambitious level, there are too many variations to make "one data model to rule them all" feasible. However, we did try to develop a generic data model that reflects good practices.

Tom's presentation to the DAAUG covers all of the details so far, so I won't go into depth here. However, I will repeat the request for testing and feedback from volunteers as we get into development phase. You can contact me here via PM if you are interested.

Thanks

George Hepworth

 

[Mike Krailo]

That is going to a very welcome asset to the community once completed. I hope there is no spaces in the names in the developer version. I can see why they might want to put examples of spaces in the names to demonstrate that it can be done, but why demo a bad practice? Anyways, looking forward to this one.

 

[GPGeorge]

That is going to a very welcome asset to the community once completed. I hope there is no spaces in the names in the developer version. I can see why they might want to put examples of spaces in the names to demonstrate that it can be done, but why demo a bad practice? Anyways, looking forward to this one.

No spaces, no special characters. That was, iirc, decided on day one of planning, even before I joined the team.

However, we did tumble onto a naming convention which I think makes sense, and wouldn't have necessarily thought of otherwise.

We're using the old reliable Naming Convention of "FirstName", "LastName", as would be expected. However, we ran across some fields in an address table that seemed to call for a different approach. Consider, for example:

StreetAddress
ZIPCode_PostalZone

In the first instance, the two words are AdjectiveNoun. What kind of Address? A street address. They fit together in a meaningful way.

In the second case, though, we realized that the two parts are really alternate names, not an adjective noun pair.

In the U.S. the value this field would hold is a ZIP Code. In Canada (and possibly elsewhere) it would hold a Postal Zone.

Hence, we agreed that _ can replace the "or" in Zip Code or Postal Zone, and avoid the awkward "ZIPCodePostalZone" that makes one cringe.

I think it makes sense, although it didn't occur to me until Tom brought it up for discussion.

 

[Mike Krailo]

That sounds like a good naming convention to me. I'm working my way through that DAAUG video now to check out the project highlights.

 

[CJ_London]

For the UK, that would be PostCode

But think most people understand what it is, if I see zip code, I know for the UK it would be post code.

The rule I use is that any field name must be unique to the entire application - the only exception being the FK field name in child tables. So in an app with customers, suppliers and employees, each with their recorded address in separate tables, I would prefix with cust/supp/emp or similar. Or alternatively use a single table of entities with an attendant address table. Really depends on the requirements of the app.

 

[GPGeorge]

For the UK, that would be PostCode

But think most people understand what it is, if I see zip code, I know for the UK it would be post code.

The rule I use is that any field name must be unique to the entire application - the only exception being the FK field name in child tables. So in an app with customers, suppliers and employees, each with their recorded address in separate tables, I would prefix with cust/supp/emp or similar. Or alternatively use a single table of entities with an attendant address table. Really depends on the requirements of the app.

Thanks. You've hit upon one of the reasons this project is so important AND so difficult. I'm going to become obnoxious, I'm afraid, repeating this phrase, "one size doesn't fit all". We have to settle on rules, or specifications, for one mythical organization called "Northwind". That means it's designed, not to suit a client of mine, nor yours, nor any "ideal client"; it's the client, Northwind, defined in our specifications. It has to be valid of course, but it can never be universal. What I'm saying is the choices of terms may or may not satisfy everyone every time. We'll do our best to reflect good practices in any case.

On the other hand, I pulled that example out the air. It's actually "ZIPPostalCode" in a recent draft I have saved and the suggestion of the underscored version came from not being comfortable with that. I think it will become something closer to the underscore I posted, though, in the final draft. But even then, "PostCode" vs "PostalCode"? Could go either way, right?

 

[CJ_London]

I understand that - you say tomaaato, I say tomayto . My point is the number of fields for an address can also vary - in the UK I think there are 39 potential field names for different parts of an address - but most will settle for 4 or 5 when developing an app, often combining several of the potential fields into one. Although technically the post office only needs a house name/number plus postcode. It will be different in other countries of course.

Rules for each will be different because they follow a different structure (at least re zip and postcode, don't know about postal code).

However an address is an address and as you say this is more about naming convention and good practice rather than having a one size fits all.

 

[arnelgp]

to modernize Northwind

i hope to see something "new" rather than just a reinvention.
or just upgraded the ui but same engine on the hood.

 

[sonic8]

However, I will repeat the request for testing and feedback from volunteers as we get into development phase. You can contact me here via PM if you are interested.

Did you think about making your spec and design decisions a public process e.g., on GitHub?

Keeping this in a closed group, as it appears you plan to do, is replicating the Microsoft Access Team's approach: The community shoves all feedback into a black hole and eventually something vaguely related to that comes out. No one ever officially explains why apparently good suggestions were ignored and apparently bad solutions were implemented. - Very frustrating and discouraging for a large part of the people providing feedback.

If the process of adopting and discarding certain feedback would be public, it would probably a much more satisfying and rewarding experience, even for those people whose contributions/suggestions were discarded.

 

[GPGeorge]

Did you think about making your spec and design decisions a public process e.g., on GitHub?

Keeping this in a closed group, as it appears you plan to do, is replicating the Microsoft Access Team's approach: The community shoves all feedback into a black hole and eventually something vaguely related to that comes out. No one ever officially explains why apparently good suggestions were ignored and apparently bad solutions were implemented. - Very frustrating and discouraging for a large part of the people providing feedback.

If the process of adopting and discarding certain feedback would be public, it would probably a much more satisfying and rewarding experience, even for those people whose contributions/suggestions were discarded.

That's a great idea. I'll make sure Tom and Michael see it. Now that the project is public, it's appropriate to share. On the other hand, we have a timeline (see the posted video on YouTube).

 

[GPGeorge]

i hope to see something "new" rather than just a reinvention.
or just upgraded the ui but same engine on the hood.

What specific things would you want under the "new" category?

 

[Mike Krailo]

Looking at the Dev Data Model of NW2, it's much easier to look at now. I like the use of the self joins as that is an important technique to utilize and understand. The table names all make sense and that MRU list is a great idea. I always incorporate extra fields in each important table for gathering update and addition dates for just such a purpose, but never thought to use a special table dedicated to that function in a generic way. Maybe add DateUpdated to that table.

 

[Mike Krailo]

Quick question, what is the purpose of the 'z' prefix on some of the table names?

 

[GPGeorge]

Quick question, what is the purpose of the 'z' prefix on some of the table names?

View attachment 100111

It's an old safety habit some of us use when remodeling an existing table schema. If a field will probably be dropped or modified, rather than physically delete it and swear at yourself later when you change your mind, you rename it that way. Once the final design is settled, "z____" stuff can be safely deleted. It also helps expose places in forms, queries, etc. where that field might have been used. They break immediately so, again, you can decide whether you really can drop or change the field, and where else you have to make changes.

I know there are also tools to analyze accdbs to find such usages. In this case, it's primarily the first reason.

 

[Mike Krailo]

Thanks George, that makes sense now.

 

[Pat Hartman]

In the US, most apps go with something like Addr1, Addr2 (to control how snail mail is printed), City, State, Zip. However, if your business is direct mail or even if you just do a lot of snail mail, you pay more attention to details and break the fields into smaller parts to ensure uniformity and avoid duplicates and take advantage of bulk rate discounts you qualify for if you do some of the pre-sorting work for the PO.

 

[GPGeorge]

In the US, most apps go with something like Addr1, Addr2 (to control how snail mail is printed), City, State, Zip. However, if your business is direct mail or even if you just do a lot of snail mail, you pay more attention to details and break the fields into smaller parts to ensure uniformity and avoid duplicates and take advantage of bulk rate discounts you qualify for if you do some of the pre-sorting work for the PO.

One of the advantages of creating specs before building out the data model is that one knows what needs to be in the data model before the tables get built. As you point out, if Northwind were a direct mail marketing organization, the specs would call for a different approach to addresses.

 

[Pat Hartman]

Specs, you wrote specs!!!!!!!!!!!! How old school

Old habits die hard for me. Specs are critical for any team effort but even when I am the only developer, I write at least minimal specs. It helps the client to understand what he is getting and ensures we are on the same wavelength.

I hope your manager will seriously consider using us (you can post here if you want) to do sanity checks for you.

 

[GPGeorge]

Specs, you wrote specs!!!!!!!!!!!! How old school

Tom was adamant on that point.

 

[NauticalGent]

I would be interested about how you handle version control...