Salakhetdinov Shamil
mcp2004 at mail.ru
Thu Mar 12 10:25:21 CDT 2009
Thank you, Mike, No, there is no such a luxury here - but there should be somebody to bulldoze (break down large pieces) of this project to have it going... Hope you will have this privilegy to bulldoze current project's follow-up projects somewhere in not that far future :) Well, in fact your purchase of VS2008 Prof. is a kind of such a "bulldozing" :) Returning credits now :) Thank you. -- Shamil P.S. In fact I'm having some troubles with parallel work for money because of only 24 hours long days here... -----Original Message----- From: "Mike Mattys" <mmattys at rochester.rr.com> To: "Salakhetdinov Shamil" <mcp2004 at mail.ru>,"Discussion concerning Visual Basic and related programming issues." <dba-vb at databaseadvisors.com> Date: Thu, 12 Mar 2009 11:06:23 -0400 Subject: Re: [dba-VB]Scrum & C# - VS versions we have > 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 > > >