Thread: Invoicing database design in microsoft.public.access.tablesdbdesign

  On 4 Nov, 14:21, "Klatuu" <dahar...@verizon.net> wrote: > "What would be wrong with that?" > Almost everything. > The common design of a header and transactions in separate but related > tables is always the correct way to accomplish this. > > If you had one table to hold it all, how many individual transactions could > such a table...

  "What would be wrong with that?" Almost everything. The common design of a header and transactions in separate but related tables is always the correct way to accomplish this. If you had one table to hold it all, how many individual transactions could such a table hold? Well, with a limit of 256 fields in a table, you will run out very quickly. And if you are saying to repeat the header info for each transaction,...

  Had I been asked I would have recommended against adding the last sentence to the previous posting, but the other points are valid. My understanding of your proposed structure is different from Klatuu's, but in either case there are literally no arguments in favor of your approach in a relational database. It would make sense only in a flat database such as Excel. When a flat database is called for Excel is generally the...