On Sat, 2017-09-16 at 19:18 +0200, Rafal Pietrak wrote: > Dear robjsargent@xxxxxxxxx, > > > I do have 17 "process tables" ... they are "class-B" tables, they > DONT > need any hierarchy. One of them contain payment details and has FK do > a > document (in one of the 12 tables of "class-A", which are in 6 levels > of > hierachy) which this payment covers. They get multiplicated ONLY > because > PK in those 12 "class-A" tables must be accessed separately. And > those I > have. It goes like this: > > Hello Rafal, I've been trying to follow this discussion but now I'm totally confused. (Some people might say that this is my normal state.) However, what do you mean by the following:- 17 "process tables"? multiplicated -- does this mean replicated? any of the 12 leaf tables I'm using -- what is a "leaf" table? collapse some of the hierarchy at the expense of some columns getting NULL for certain rows -- does this mean if you have two input fields (field A and field B) that if field A is not null and field B is null the data is inserted into one table and if it's the inverse you insert into an entirely different table? IMHO, you need an UML diagram that not only sets out your workflow but will also provide the basis for your schema. Keep in mind that a hierarchy can be 'n' tables deep. The foreign keys point back upwards until you finally reach the parent. You mention payments being made. Users make mistakes. They can post a payment to the wrong account and later it has to be reversed. These things can be modelled via your UML diagram. Cheers, Rob -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
