It seems you have good understand of how manufacturing works.
The idea in manufacturing is to build something that solves a need, but NOT
have to change the design for each copy.
The same concepts and rules apply to creating software. While software is
called "soft" due to it not having physical properties, the same concepts
and ideas in manufacturing also apply to software.
The problem with a software machine is that when you write code, and design
the product, it is VERY costly to change the data designs.
It is of little, or no consequence to add 5 records, or 15 records to a well
deigned system. However, to modify the design of the tables is like trying
to modify the design of engine AFTER it has been built, and put in the car.
It is just not practical to modify the table structures, since then the code
and the designs of the forms and designs of the reports all must now be
updated. So, you have to think of the software designs part like a machine,
and you have to purpose build the machine to solve the problem, and having
to change the design of the machine is VERY costly. Thus, to continue this
metaphor, you can easily add to the machine, such adding custom headlight to
a car, but trying to change the actual designs of the motor is out of the
question.
So, we don't have dynamic motor designs, and in fact we don't have such a
thing as dynamic tables in the software industry. The reason whey we don't
have dynamic tables is that software is a machine that needs to eat and
consume STRUCTURED data, and if that data structure changes, then so must
the software that consumes the data.
Thus, the skill, or how this problem is solved is called data modeling. Just
lick a electrician can take standard set of parts and make a radio, or make
a microphone, the parts he uses don't change.
So, we are stuck with tables that should NOT have their designs changed once
the application is in use. Hence, like the knowledge the electrician uses to
take transistors and parts and comes out with a radio, or a microphone, the
resulting "software machine" you make needs to function in such a way that
the table designs do NOT change.
The solution is called data modeling, or normalizing. This enables
developers to build a accounting system with job costing, and yet once
built, that job cost system can be used by many different companies, and yet
the table designs don't change!! And, many of those accounting systems have
complex inventory cost system that allow assemblies of all types to be
entered into the system. So, once company might be watch maker, and the next
company might be Boeing, but they both can use the inventory system because
the designers normalized the table designs used. One might be costing the
part by labor, and feet of wire, the other company might be costing the part
by weight and materials cost, yet they both can use the system table
designs!
So, likely, in your case, you don't need dynamic tables, but you do need to
start learning how to model data structures in tables so that the resulting
software application can use the non changing data structures.
I am building widgets and these are of different types. For each widget I
record a serial number and the type
SerialNum ProductType Product Name Units
123 Fruit Apple
Weight
455 Rocks Granite
Weight
789 Rope Cotten cable Length
.. Now for each type I want to record
different attributes so say type A has attributes M & N and type B has
attribute X, Y & Z.
Type AtrrbiuteType
A M
A N
B X
B Y
B Z
Anyway, you will have to do some reading on this subject, but we have
dynamic tables, and if you did, the software would not work when you change
the designs....
ACC2002: Database Normalization Basics
http://support.microsoft.com/?id=283878
Database Normalization Tips by Luke Chung
http://www.fmsinc.com/tpapers/genaccess/databasenorm.html
Data Normalization Fundamentals by Luke Chung
http://www.fmsinc.com/tpapers/datanorm/index.html
324613 - Support WebCast: Database Normalization Basics
http://support.microsoft.com/?id=324613