Data design for .NET apps

cousin_borat

Hows it going,

Recently I've been looking at designing a data model for a company. Initially I was following a traditional data modelling lifecycle. Identified the entities in the domain, build a logical model and abstracted down to a physical model where I added things like FK's, Triggers, etc, etc.

This has always worked well for me designing and building Oracle applications and J2EE apps.

However one of the applications to use the DB (MSSQL 2005) is going to be A RIA built in Visual Studio. Seemingly C# has some cool types like radio button list, drop down list and check box list that all inherit from some super type.

This means that you could have a table containing artifacts that are displayed on a form. As you add/remove artifacts from the table they are dynamically added to/removed from the form.

So...

My question is, does this change how data models are developed fundamentaly since
A) You create the data model based on how your forms are going to turn out
You stick to the traditional way of modelling the domain and using your ORM tools to write/to from your application to the relational database tables. Taking into account CRUD operation performance, etc, etc
C) What about new tools like WebGrid, what implications does this have for data modeling?

I hope this isn't too convoluted!!

FindingNemo

cousin_borat wrote: »

Hows it going,

Recently I've been looking at designing a data model for a company. Initially I was following a traditional data modelling lifecycle. Identified the entities in the domain, build a logical model and abstracted down to a physical model where I added things like FK's, Triggers, etc, etc.

This has always worked well for me designing and building Oracle applications and J2EE apps.

However one of the applications to use the DB (MSSQL 2005) is going to be A RIA built in Visual Studio. Seemingly C# has some cool types like radio button list, drop down list and check box list that all inherit from some super type.

This means that you could have a table containing artifacts that are displayed on a form. As you add/remove artifacts from the table they are dynamically added to/removed from the form.

So...

My question is, does this change how data models are developed fundamentaly since
A) You create the data model based on how your forms are going to turn out
You stick to the traditional way of modelling the domain and using your ORM tools to write/to from your application to the relational database tables. Taking into account CRUD operation performance, etc, etc
C) What about new tools like WebGrid, what implications does this have for data modeling?

I hope this isn't too convoluted!!

Hi there,

One thing is for sure,
You should NEVER alter you data model/design based on your GUI tool or interface. This is for sure a no no.
You work around your data model. If your data model changes to suit a particular style of progamming you may find yourself running into huge problems later on regarding possible performance issues, reporting issues etc. etc.

stevenmu

But at the same time your data model should be based around the functionality and tasks which will need to be carried out by your users, which may be influenced by the UI design possibilities

FindingNemo

stevenmu wrote: »

But at the same time your data model should be based around the functionality and tasks which will need to be carried out by your users, which may be influenced by the UI design possibilities

Sure, the data model should be based around functionality and tasks, but this certainly shouldn't be influenced by UI design.
There are so many features and possibilites now for interface design that I find an example extremely difficult to come by where one would have to alter there db design in order to accomodate not been able to do something in the UI.

cousin_borat

Surely ORM tools which decouple the database from the application to a certain extent should mean that a data modeler should concentrate on modelling the domain in question with scalibility in mind and the app developer uses ORM tools to make it easier and quicker to hook up to the db in the first place and implement changes in the UI secondly.

cousin_borat

According to anyone I have asked they have all warned away from using the automatically add database fields options to forms. Seemingly the performance hit due to a poorly structured database outweighs any potential ease of coding aspects.