Open joeblew99 opened 7 years ago
I noticed that support for composite keys and many to many relationships is requested in the issues list.
I want to point out that materialised views can be used to replace the need for many to many relationships. This is because materialised views gives alot of flexibility without breaking classic dB relational constraints.
I would be happy to help on the code for this but i am super curious if it's supported & appreciated first.
I'm not sure I understand what you are asking for. May you please clarify what you want to achieve and what should be done?
sorry. Here goes again
This is a much better summary. http://milinda.pathirage.org/kappa-architecture.com/
So with SQL dbs you need to joins between tables to build larger views that use FK's between tables. But there is another way, and it involves building materialised views. Then you dont need to do joins. You can still use a relational DB and do queries on the Materialised views.
For example say you have: Person Table
Books Table
PersonsBook Table
Well instead of managing the joins, you can generate triggers to do the same things. Basically you want to maintain a List of Books a Person has. Person Table
Books Table
PersonsBook Table (Materialised Table View)
Why ?
Would it be possible to support this in a non dialect specific way.
The reason i ask this is that i often need to produce tables of data triggered from cha he's in rows in other tables.
This can be done without specific dB system dependencies by using hooks in the golang data access layer.
For example when an i settings or delete it update occurs on structs t type X, publish an event that holds the event type and structure. Other tables can then subscribe to the event type and update their table.
This needs to allow a transaction context too.
The pattern des ribed above allows lots of interesting use cases: Cqrs style architectures. Nosql database structure tire using a SQL database. Emergent design patterns