Best Way to handle documents positions in accounting system

What is a position in your application domain? Are you able to share some code to help visualise your problem

Maybe position isn't the best term. I took about rows (items) exist on document (normally as row of table). Important part of (for example) invoice.

Milk - 1 pcs. 5$ 7$ Tomato - 2kg 4$ 6,5$ ...

and I have about 7 types of documents which have the same types of positions/items/rows (each position's structure is the same).

For this case polimorphic relation with only one positions-table is good idea ? ... or maybe stay with approach consisting of related pair of tables: invoices + invoice_positions

Thanks for msg!

A Polymorphic Relation is a third table related to said tables that have common fields (rows). Not the tables in question.

Re-read Polymorphic Relations carefully:

https://laravel.com/docs/5.7/eloquent-relationships#polymorphic-relations

From docs:

posts
    id - integer
    title - string
    body - text

videos
    id - integer
    title - string
    url - string   // different from above

comments     // these fields common
    id - integer
    body - text
    commentable_id - integer
    commentable_type - string

A user can comment on a post or a video, i.e.,

• hey good post dude
• bad video

Edit:

You can however have a related table (if you wish) under all said tables if there is extra related data to store. It would be a Polymorphic Relation of sorts. I guess a Positions table. It would be child to several parents, but not seeing all the setup, it's hard to tell.

Sorry another edit.

Me, I would not, yes it looks all good and fine, but later coding it for display in blade might be an issue, maybe not.

I try to code where the most I ever need is a one to many. And I have written logistics software with only one to many.

I did have main load with picks and drops thus a parent with two children, however each on their own was still a one to many.

But that's just me.