@Stephen I guess you dont realize that using a View is like creating another Table of information. Albeit, it only includes the fields that you want its still an added Table. Only time i use Views is when i dont have a 1:1 or 1:many relationship and there is a many:many relationship. There are far and few situations where i have a many:many relationship.
Based on the bland/generic information provided by Dani, a View is not what he wants to use with the dynamic addition of Fields to one or both of the tables. It would be easier to have a SProc return a data-set that can be dynamically expanded/contracted based on the existance of fields in one or both of the databases. Also, i have been developing against databases since Access 97, managing Databases since MSSQL version 2000 (cant remember the build information), and administrating SQL Servers since SQL 2000. It is always easier to draft a database design from conceptual information for the application and then develop the "Helper" classes to access the information and then develop the interface to the data in the application. If you try and do it the other way around, you will spend well over double the amount of time in design and development due to minor/major changes to organization, design, and relationships. Secondly, i do this for a living for the past 4 years, i have a key knowledge of programming design and implementation (VB/C#) and database adminsitration/installation/development (SQL 2005+) so i have a full knowledge of information (minus Network & Server Admin) of the SDLC. Lastly, Dani needs to provide a hell of alot more information in regards to his need cause adding Triggers to his tables to add/subtract fields from a table/view would be a nightmare situation to support for anyone coming in after him/her. On Wednesday, March 14, 2012 9:30:07 AM UTC-5, srussell705 wrote: > > On Wed, Mar 14, 2012 at 6:17 AM, Goldie <john.w...@woodsoft.us> wrote: > > A) Don't Use VIEWS pointing to other DBs. Use SProc's to return > Data-Sets > > that are joined from multi-databases. > -------------- > > I disagree. Views are great for just this situation. > > View rock for ORM environments as well. > > > > B) No need to do this. > > > > Suggestions: > > - Design your database > > - Design the back-end of your application > > - Design the front-end of your application. > > > > Never start in reverse, cause then your database will, almost assuredly, > be > > unsupportable. > -------------------------------- > > Design is an easy thing to say but hard to do well. > > Design is the vehicle to determine if things work together. Does my > physical building structure fulfill what I need? Can users use the > device I just invented. Is my data accessible to my application and > others that might need it. > > You first identify the requirements that generate your first draft of > data repository structures. You next generate the data objects that > will be populated to contain that data. You now cross reference your > schema to validate everything is contained. > > Are you a third normal or a fourth normal data designer? Could your > developers ever figure out fourth normal? Does this get in the way of > reporting later on? > > So I still say design is not that easy. > > -- > Stephen Russell > > 901.246-0159 cell > > On Wednesday, March 14, 2012 9:30:07 AM UTC-5, srussell705 wrote: > > On Wed, Mar 14, 2012 at 6:17 AM, Goldie <john.w...@woodsoft.us> wrote: > > A) Don't Use VIEWS pointing to other DBs. Use SProc's to return > Data-Sets > > that are joined from multi-databases. > -------------- > > I disagree. Views are great for just this situation. > > View rock for ORM environments as well. > > > > B) No need to do this. > > > > Suggestions: > > - Design your database > > - Design the back-end of your application > > - Design the front-end of your application. > > > > Never start in reverse, cause then your database will, almost assuredly, > be > > unsupportable. > -------------------------------- > > Design is an easy thing to say but hard to do well. > > Design is the vehicle to determine if things work together. Does my > physical building structure fulfill what I need? Can users use the > device I just invented. Is my data accessible to my application and > others that might need it. > > You first identify the requirements that generate your first draft of > data repository structures. You next generate the data objects that > will be populated to contain that data. You now cross reference your > schema to validate everything is contained. > > Are you a third normal or a fourth normal data designer? Could your > developers ever figure out fourth normal? Does this get in the way of > reporting later on? > > So I still say design is not that easy. > > -- > Stephen Russell > > 901.246-0159 cell > > -- You received this message because you are subscribed to the Google Groups "DotNetDevelopment, VB.NET, C# .NET, ADO.NET, ASP.NET, XML, XML Web Services,.NET Remoting" group. To post to this group, send email to dotnetdevelopment@googlegroups.com To unsubscribe from this group, send email to dotnetdevelopment+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/dotnetdevelopment?hl=en?hl=en or visit the group website at http://megasolutions.net
