Re: Design table with many columns
From: richard goulet <rjgoulet_at_comcast.net>
Date: Fri, 5 Jul 2024 12:28:28 -0400
Message-ID: <a9e6d6ec-b9bc-49bb-b3ca-94416fc51749_at_comcast.net>
This is a pretty old issue that has been around for many a decade, even before DBMS's appeared. The solution from back then is to assign each transaction some type of ID that can then have a header table as well as a multi row spec table where each distinct and variable attribute can be stored without making a mess of the RDBMS. Let me go back to a VERY OLD configuration I worked on and with:
Date: Fri, 5 Jul 2024 12:28:28 -0400
Message-ID: <a9e6d6ec-b9bc-49bb-b3ca-94416fc51749_at_comcast.net>
This is a pretty old issue that has been around for many a decade, even before DBMS's appeared. The solution from back then is to assign each transaction some type of ID that can then have a header table as well as a multi row spec table where each distinct and variable attribute can be stored without making a mess of the RDBMS. Let me go back to a VERY OLD configuration I worked on and with:
We had a header table with a NSN, NOUN, and other associated columns and a SPECS table that has the associated NSN column, a SPEC_NAME and a VALUE columns as well as others that held the variable data.
Some NSN's had 10 specs rows while some has several hundred depending on what you were describing. The NSN was the primary key in the first table and a foreign key in the second.
Did something similar in civilian life afterwards for electronic modules in a manufacturing environment and that ported nicely between databases as well so we could have Oracle internally and Postgres on the external web site. Same queries worked on both sides.
-- http://www.freelists.org/webpage/oracle-lReceived on Fri Jul 05 2024 - 18:28:28 CEST