Records vs Fields
From: Ivo PECILE <pecile_at_mail.nauta.it>
Date: 10 Jan 2003 03:52:14 -0800
Message-ID: <630c6755.0301100352.78fda962_at_posting.google.com>
I'm going to develop with MS SQL Server 2000 a database application whose data are coming from an Access 97 application. Data consist of a series of MDB designed with a large number of fields and tables (MDBs of 250-300 fields divided into 50-60 tables). All data refer and are related to a main table. Data essentially contain several specifications of a main photographic object (author, date, photographer, copyright, format, analitic description and so on). All fields are text or memo.
I tried to make some normalization to the data but but in every solution the number of fields and tables remained unacceptable in terms of number and maintainance.
So I changed the perspective into a "vertical" solution with simply four tables (necessary to maintain many to many relations) and fields "transformed" into records.
Is this solution the best in my problem ? What are the "pro" and "contro" of such design ? I suppose this model has been already developed and explained in other case studies over the internet. Can you point me to some practical samples or links ??
Date: 10 Jan 2003 03:52:14 -0800
Message-ID: <630c6755.0301100352.78fda962_at_posting.google.com>
I'm going to develop with MS SQL Server 2000 a database application whose data are coming from an Access 97 application. Data consist of a series of MDB designed with a large number of fields and tables (MDBs of 250-300 fields divided into 50-60 tables). All data refer and are related to a main table. Data essentially contain several specifications of a main photographic object (author, date, photographer, copyright, format, analitic description and so on). All fields are text or memo.
I tried to make some normalization to the data but but in every solution the number of fields and tables remained unacceptable in terms of number and maintainance.
So I changed the perspective into a "vertical" solution with simply four tables (necessary to maintain many to many relations) and fields "transformed" into records.
Is this solution the best in my problem ? What are the "pro" and "contro" of such design ? I suppose this model has been already developed and explained in other case studies over the internet. Can you point me to some practical samples or links ??
Thanks a lot for any help Received on Fri Jan 10 2003 - 12:52:14 CET