Mike Mattys
mmattys at rochester.rr.com
Thu Mar 12 10:06:23 CDT 2009
Yes - but I have a question. Are there more hours in the day over there? <Grumble> - Michael R Mattys MapPoint and Database Dev www.mattysconsulting.com - ----- Original Message ----- From: "Salakhetdinov Shamil" <mcp2004 at mail.ru> To: "Discussion concerning Visual Basic and related programming issues." <dba-vb at databaseadvisors.com> Sent: Thursday, March 12, 2009 10:58 AM Subject: Re: [dba-VB]Scrum & C# - VS versions we have > > 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 >> >> >> >> _______________________________________________ >> dba-VB mailing list >> dba-VB at databaseadvisors.com >> http://databaseadvisors.com/mailman/listinfo/dba-vb >> http://www.databaseadvisors.com >> > > _______________________________________________ > dba-VB mailing list > dba-VB at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/dba-vb > http://www.databaseadvisors.com >