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

Hi SCRUM team at all,

I have made sample database tables' columns renaming according to Gustav proposals - new version of db backup is here:

https://cid-000971dc34dc18c0.groups.skydrive.live.com/self.aspx/.Documents/NorthWind.NET/Database/NorthWindNET%7C_DB%7C_BackUp%7C_20090314.zip

Thank you.

--
Shamil


-----Original Message-----
From: "Gustav Brock" <Gustav at cactus.dk>
To: <dba-vb at databaseadvisors.com>
Date: Thu, 12 Mar 2009 18:37:34 +0100
Subject: Re: [dba-VB] Scrum & C# - VS versions we have

> Hi Shamil
> 
> That may be true for renaming (haven't tried) but I don't think field properties are written back.
> 
> /gustav
> 
> 
> >>> Salakhetdinov Shamil <mcp2004 at mail.ru> 12-03-2009 16:52:02 >>>
> Hi Gustav,
> 
> You're very probably aware - if not here is a hint on how to do renaming quickly:
> 
> - open MS SQL 2005 NorthwindNet 'Main' datamodel diagram and do all renaming directly in it with saving current edits (CTLS+S) once in a while as you're doing renaming...
> 
> 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
> 
> 
> 
> _______________________________________________
> dba-VB mailing list
> dba-VB at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/dba-vb
> http://www.databaseadvisors.com
>