Hello Ivan, I am glad to have this suspicion confirmed. With a bit of luck the storage overhead will be small if Null values are stored efficiently, but who knows. I will create a ticket if none exists. Thanks a lot!
Kind regards, Stéphane Thibaud 2019年5月9日(木) 19:58 Ivan Pavlukhina <vololo...@gmail.com>: > Hi Stéphane, > > Yes it sounds that extra non primary key column is a straightforward > solution. > > I believe that the limitation is caused by peculiarities of Ignite SQL. > But storage overhead should be calculated in order to measure how critical > is it. Also it worth to search Ignite Jira for relevant ticket and create > one if none exsts. > > On a bright side it could be a case that an additional column can have > some business meaning in practice. > > On a bright > > Sent from my iPhone > > On 5 May 2019, at 17:34, Stéphane Thibaud <snthib...@gmail.com> wrote: > > After some more thought about this: I really think that the constraint of > having one 'non primary key' column is a severe limitation. In combination > with the fact that it is also not possible to create a table without > primary key, it means that a column that wastes space *has* to be created > for a many-to-many relationship. Am I missing something? > > > Kind regards, > > Stéphane Thibaud > > 2019年5月4日(土) 22:46 Stéphane Thibaud <snthib...@gmail.com>: > >> Hello Apache Ignite users, >> >> I was wondering what would be the best way to model a many to many >> relationship. Since uniqueness constraints do not exist in ignite, I >> thought of setting a primary key constraint on the two columns in my >> linking table. However, Ignite complains that at least one non primary key >> column needs to exist in this case. I could come up maybe come up with a >> column like 'created date', but it seems like a waste of space if not truly >> necessary. Otherwise I might have to accept duplicates and filter on >> selection. >> What approach would you suggest? >> >> >> Kind regards, >> >> Stéphane Thibaud >> >
