[dba-VB] Scrum & C# - VS versions we have

Salakhetdinov Shamil mcp2004 at mail.ru
Thu Mar 12 13:45:12 CDT 2009


Hi Gustav,

>   someDataTable.Id
>   someDataTable.CustomerId
> 
> there is no doubt. Id is the PK and CustomerId is some FK.

In the naming convention I'm currently using in NorthwindNet db it would be like that:

>   Customer.CustomerId
>   Order.CustomerId

and it's clear where it's a primary key and where it's a foreign key.

But let's go renaming with your proposed named conventions

Customer.Id
Order.CustomerId

Thank you.

--
Shamil



-----Original Message-----
From: "Gustav Brock" <Gustav at cactus.dk>
To: <mcp2004 at mail.ru>
Date: Thu, 12 Mar 2009 17:58:07 +0100
Subject: Re: [dba-VB] Scrum & C# - VS versions we have

> Hi Shamil
> 
> When I state "hysterical" it is for new projects and databases I'm in control of. Of course, for legal setups you often would leave it as is, and I think Northwind is such a case.
> 
> As for which naming convention we should use, I'm quite flexible if we just try to stick to one. But it is difficult - I can see that some have one for WinForms and another for WebForms, oh well.
> I could even live with OrderId for the primary key of table Order. However, in code you'll see:
> 
>   someDataTable.OrderId
>   someDataTable.CustomerId
> 
> Now which is - if any - the PK of someDataTable? If you have:
> 
>   someDataTable.Id
>   someDataTable.CustomerId
> 
> there is no doubt. Id is the PK and CustomerId is some FK.
> But this is just my preference, nothing more, nothing less.
> 
> For tables given names equal to reserved word I believe you can just bracket these like: [Order], at least in Access and SQL Server.
> 
> /gustav
> 
> 
> >>> Salakhetdinov Shamil <mcp2004 at mail.ru> 12-03-2009 15:58:47 >>>
> 
> Hi Gustav and SCRUM team members,
> 
> I'm for proposed renaming.
> Can you do it?
> The current db backup is uploaded here:
> 
> https://cid-000971dc34dc18c0.groups.skydrive.live.com/browse.aspx/.Documents/NorthWind.NET/Database?uc=1&isFromRichUpload=1 
> 
> Note:
> 
> - comparing to MS Access db this database does have already Identity fields introduced in all the tables, and all the relationships set using them.
> 
> I do follow similar to proposed database fields naming conventions with one exception - I do name identity fields using table name prefix: CategoryId, ProductId, ShipperId. I use this naming convention because of technical reasons, which seems to me obsolete/conservative now (and therefore I'd beter not mention them here at all) - and I'd try to get my old habit abandoned while working on this project...
> 
> While renaming fields please do not try to be perfect e.g. for the case of Supplier, Customer, Shipper table, which all have CompanyName field I'd not see any problems to leave this field name as it's, if you'll rename it as Name - that's OK with me also etc.
> 
> One more example: there is a table named [Order] in our database: we all know that 'Order' is a keyword in SQL, and because of that it would be useful to have the table named somehow differently but I'd propose to levae it as it's - if we will try to be perfect with such little details then we will have trouble/headache working with real life apps (conversion), which are usually rather imperfect in many areas....
> 
> I mean that would be a major problem if we will go circles discussinbg proprietary naming conventions instead of working to deliver real software product - test conversion Northwind application... 
> 
> For naming conventions in .NET there is somewhere recommended by MS document, which I'd propose to follow (when we will find it :)) - with one exception: I have found that many .NET developers still use Hungary Notation (three-four letter prefix) to name controls - I'd use it like that - but if our SCRUM team members will prefer to use control name suffix (as recommended by MS) - I can use it like that also...
> 
> Gustav, please wait for Mike, Doug and John to appear here today with their opinion on the proposed DB namimng convention - and when they will say "Yes" then do this rehaming.
> 
> What to do if not all of them will participate in this discussion today? I'd go with renaming - we have to act quickly - and having db datamodel ready before we start programming is an important step for everybody to have what to do on the first day, and not go circles renaming "Done" stuff on later steps...
> 
> I must note that my current "intervention" with my opinion of naming conventions is not SCRUMMaster responsibility at all but in our case I'd probably have to play SCRUMMaster/Team member role because of limited resources we have.
> 
> By my current "intervention" I also wanted to show an example how to "abandon old habits" when working in a SCRUM team (I mean my habit to use table name prefix for ID fields)...
> 
> I will try to minimize such "interventions" in the future - in fact there is a notion of "pigs" and "chickens" in a SCRUM team: "pigs" participate in discussions and evaluations, and "chickens" don't. I'd try to stay "chicken" most of the time. Everybody of the SCRUM team members can temporarily (for a short time) take the role of "chicken" because of some reasons they could make others informed about or not...
> 
> As for datasets as the source of forms's data - I have not seen problems with them in VS2008 while preparing samples - please if you get such problems write how to reproduce them using published samples.
> 
> .NET datasets (as in the currently published samples) could be not perfect or even satisfactory in large scale interprise applications but for the first project (and assuming we are making just simple desktop app within this project) - the datasets could be all we need as they allow to concentrate main activity on forms/reports design work, and get work "done" and project released as quick as possible...
> 
> Thank you.
> 
> --
> Shamil
> 
> -----Original Message-----
> From: "Gustav Brock" <Gustav at cactus.dk>
> To: <dba-vb at databaseadvisors.com>
> Date: Thu, 12 Mar 2009 14:29:19 +0100
> Subject: Re: [dba-VB] Scrum & C# - VS versions we have
> 
> > Hi SCRUM team
> > 
> > Yes, maybe the relational model of this db can cause us some headache - I remember many years ago JC ranting about this.
> > 
> > As for the model, I've found too, that it is preferable to make changes in the database first. However, the model in VS - the DataTables - don't get updated automatically but it is quite easy to make the same adjustments in the DataTable(Adapter)s afterwards
> > 
> > One tricky issue I've seen is, that for fields of AutoNumber, the properties of these sometimes are not read correctly. This means that the db can have a seed of 1 while the model in VS has a seed of 0. This, of course, creates strange errors as soon as you start adding records via the DataTable.
> > Also, sometimes, the property "Allow Null values" for fields are read incorrectly. But, again, this is quite easy and fast to check and correct.
> > 
> > That said, I haven't worked with the DataTables for any other tables than such having an Id of AutoNumber as the primary key. In fact, I've turned quite "hysterical" about this because the advantage of _always_ having this Id key is so big in general and indeed when you work with the model that there is no excuse to not do so.
> > 
> > In my latest app I had full control over the table schema so no problem, but for a given schema like Northwind, you have the option to name the fields in model otherwise than the related fields in the database, should you feel so. 
> > 
> > This is a topic for discussion.
> > 
> > The naming I use is extremely simple and not invented by me:
> > 
> > Customer
> >   Id
> >   Name
> >   etc.
> > 
> > Order
> >   Id
> >   CustomerId
> >   etc.
> > 
> > OrderLine
> >   Id
> >   OrderId
> >   etc.
> > 
> > The trick is, I've learned, that you _always_ know that Id is the primary key of the table and any other xxxxId is a foreign key, while - of course - xxxx is _always_ referring to the primary key of table xxxx and this field is named Id. Any other field must not be named to contain "Id", use anything else like Num, No, Key, Code or the like. No rocket science, I know, but I've seen some fancy naming conventions hard to remember and/or to grasp ... this method is so simple that you can't fail.
> > 
> > /gustav
> > 
> > 
> > >>> Salakhetdinov Shamil <mcp2004 at mail.ru> 12-03-2009 09:01:31 >>>
> > 
> > Hi SCRUM team at all,
> > 
> > Just added to simple sample application:
> > 
> > https://cid-000971dc34dc18c0.groups.skydrive.live.com/self.aspx/.Documents/NorthWind.NET/Samples/SimpleWinForm/NorthWindWinFormSample%7C_3.zip 
> > 
> > - NorthWindDataModelDataSet - dataset having the whole datamodel;
> > - ShipperOrdersForm - Parent/Child;
> > - CategoryProductsForm - Parent/Child, Database Image Binding.
> > 
> > Please note the above sample *does* intentionally/occasionally have got some issues/inconsistencies, which should be talked through/fixed in the real conversion project. For example:
> > 
> > 1. Shipper table has ShipperId id field and Order table has ShipVia foreign key field - the latter should be better named ShipperID; 
> > 
> > 2. Relationships in MS SQL 2005 database are not renamed manually after upsizing - thus when designing datasets relations get Order_FK1 name etc. - relations should be better renamed on the database level to have them consistently named in datasets and referred in winforms' binding...
> > 
> > etc.
> > 
> > The above issues are not critical of course but desirable(?) to be fixed...
> > 
> > There could be other non-critical/critical issues - please note them and propose the way(s) to solve/workaround them...
> > 
> > Thank you.
> > 
> > --
> > Shamil
> 




More information about the dba-VB mailing list